场景

在金融银行类安全测试中，经常见到数据包加密、签名保护，这种业务不能直接进行有效的安全测试，修改数据包参数会重放失败，爬虫见到密文也是懵逼

测试套路

对于这种业务，不管是手工还是借助工具，需要先还原加密算法（或者签名保护算法）。知道了加密逻辑后，就可以开发burp插件完成明文状态下的安全测试，最后借助密文数据天然过waf的优势结合Xray等漏扫工具完成半自动的安全测试（逻辑漏洞还得需要手工测）。 笔者通过几个案例介绍这类业务的通用测试流程：常见加密算法分析流程、burp插件开发、联动Xray半自动化挖洞。
所以案例只是案例，读者不要纠结于这些案例中的加密算法，因为加密有很多组合形式。主要是通过本文介绍这类业务的通用测试方法，降低安全测试的人力成本

案例

常见签名的生成算法：sign = MD5( sort( 业务参数+时间戳+其他参数) )，拼接业务参数+时间戳+其他参数，对字符串排序，计算字符串MD5作为sign。客户端和服务端使用相同的算法生成sign，服务端接收到请求后，先计算一次sign，如果业务参数、时间戳、其他参数中有一个被修改过，得到的sign就与客户端发送过来sign不一致，签名校验就会失败，不再处理请求

签名校验

1、不修改数据包，重放请求，此时可以正常响应

2、然后修改参数icon_type的值为11，再次重放，此时会提示"message":"sign invalid"，请求中的api_sign是签名的值，需要知道api_sign是怎么计算出来的

3、用url参数作为关键字搜索，在js中定位api_sign，设置断点

4、刷新网页，停在了断点位置，单步步入进入函数内部,可以看到加入了两个参数app_key、app_pwd，然后单步往下走，参数c的值此时为device_id=069c8db0-af49-11ed-9a08-3b99f11ff116×tamp=1676725825997&session_token=G2de7f3ab78910b46ad8c07d6e25c627&app_key=f6aefd6691f04573bdf9e044137372bc，也就是所有url参数

5、继续单步走，进行了一次排序，c的值为app_key=f6aefd6691f04573bdf9e044137372bc&device_id=069c8db0-af49-11ed-9a08-3b99f11ff116&session_token=G2de7f3ab78910b46ad8c07d6e25c627×tamp=1676725825997

6、之后就是拼接字符串，app_key+"Oic"+app_pwd+"QeeeS99u3d"+c+app_key+app_pwd

7、得到的字符串为：
f6aefd6691f04573bdf9e044137372bcOic72e78efefe6b4577a1f7afbca56b6e28993c06ea4bb84cde8dd70e582dbc76cbQeeeS99u3dapp_key=f6aefd6691f04573bdf9e044137372bc&device_id=069c8db0-af49-11ed-9a08-3b99f11ff116&session_token=G2de7f3ab78910b46ad8c07d6e25c627×tamp=1676725825997f6aefd6691f04573bdf9e044137372bc72e78efefe6b4577a1f7afbca56b6e28993c06ea4bb84cde8dd70e582dbc76cb

8、最后获取这个字符串的MD5，就是签名api_sign的值

9、还原了api_sign的计算方式，就可以开发burp插件自动更新签名校验的参数api_sign

用burp插件自动更新签名

burp插件的接口开发知识不再单独介绍了，否则篇幅会太冗长，在文中数据包加解密和签名保护绕过这块，没有涉及到太多复杂的开发知识。插件的学习可以参考官方文档和官方的代码demo，代码量不算多https://portswigger.net/burp/extender/api/index.html

首先在processHttpMessage中，检查uri参数，移除原来参数api_sign

根据修改后的uri参数，使用已还原的api_sign生成算法得到新的api_sign

此时修改参数，重放请求后，插件会自动更新url中api_sign的值（ps：下面这两个截图是笔者随意找的测试站点，url参数也是自己加的，读者根据上下文理解意思即可）

在控制台查看更新的api_sign，此时修改请求参数做安全测试就不再受签名保护限制了

数据包分段加密

一个H5应用，在微信可以正常访问，放到浏览器访问限制

修改一下User-Agent，修改为安卓或ios手机的UserAgent，再刷新页面后能正常访问

随便输入一个卡号后先抓个包看看

数据包都做了加密

任意修改一个密文字符，把第一个字符c改成1，服务端不能正常处理密文

直接发明文包不行，明文会被当成密文去解密

使用数据包的参数encryptData定位加密代码位置，展开js文件，搜索关键字；单击{}格式化js，方便阅读

单步步入调试进入pten函数，参数e是默认DES密钥

查看setMd5的入参，可以debug一行一行看

也可以将方法代码放到控制台查看

可以看到第一部分MD5的构造是原始参数json+DES密钥e，拼接后做MD5

setDES这部分是ECB模式，Pkcs7填充的DES加密，密钥是e

参数n是rsa加密DES密钥得到的密文，是一个固定值。最后返回MD5+splitStr+DES加密后参数+splitStr+rsa加密的DES密钥

splitStr是一个分割字符，用于将不同加密加密方式得到的密文分割开，服务端收到密文后，按splitStr分割密文，再逐段解密

拿到控制台看看是什么字符

也就是数据包中见到的\u001d

验证一下：解密中间部分的密文, 得到原始参数的json

ptde函数用于解密返回包的密文

单步步入getDESModeEBC函数，使用密钥e进行DES解密，没有其他处理

在线解密验证下

得到结论：
请求包的加密：MD5(原始参数+DES密钥)+”\u001d”+DES(原始参数) +”\u001d”+RSA(DES密钥)
返回包的解密：直接用DES密钥解密即可

分段解密

用正则获取两个\u001d中间的密文，

解密后在burp控制台打印，看看能不能正常解密

明文请求的body则加密后重新封包

这时候使用明文发包没问题了

使用IMessageEditorTab在burp中增加一个控件，用于获取解密后的完整请求包，在IMessageEditorTab中填入header和解密后的原始参数

先判断是否请求中包含参数encryptData

包含则说明是密文包，再启用控件，解密密文

点击“参数明文”控件，获取到了解密后的完整请求包，对明文参数进行安全测试，重放后插件会自动完成密文构造

对于变化的密钥，可以提供一个ui界面，在输入框设置密钥，rsa等动态变化的值

最后需要把返回包的密文也处理掉，由于在burp插件开发中返回包没有参数的概念，只能通过偏移获取body，解密后，用明文替换密文，再用IMessageEditorTab展示解密后的数据包

此时原始响应还是密文，因为客户端需要解密这个密文，IMessageEditorTab中明文只是展示作用，辅助安全测试，不会返回给客户端

encryptData中的密文被替换为明文展示，之后的安全测试就完全是明文了

自动BypassWAF 联动Xray

这也是数据包加密给安全测试人员的彩蛋吧，数据包加密有一个好处：天然对waf等态势感知设备免疫，自带绕过属性：
明文的payload会被waf识别

如果直接扫描原始请求，会触发WAF拦截

加密后waf没法再识别，如果还原了加密算法，也就间接的绕过了waf（但是，除了前置的waf，应用程序自身也会对参数做合法性校验）

控制台打印加密的payload

于是可以结合漏扫工具做半自动的安全测试（逻辑漏洞还是需要手工测试），示意图如下

1、burpA中联动Xray

2、开启联动Xray的开关

3、这个开关用于控制是否对明文请求包做加密，在联动Xray时，需要给Xray明文包，所以开启后从burpA重放的明文请求包不做加密，直接给Xray去做payload构造

4、设置Xray的代理

5、burpB作为Xray的代理

6、将插件代码拷贝一份，打包为另一个插件，作为联动Xray的专用插件。其他代码不用动，只修改BurpExtender.java中processHttpMessage方法代码：只处理经过Proxy的http流量，做两件事：加密请求body，解密响应body

7、启动Xray监听127.0.0.1:7777, 在burpA的Repeater中重放明文请求包

8、Xrays收到burpA的明文请求，在明文包构造payload，开始扫描，从Xray日志可以看到，未触发WAF

9、burpB收到Xray的明文请求，加密请求中明文中包含payload的body再发给服务端，扫描器能正常工

10、查看控制台打印的密文body：

11、burpB解密响应的密文body后返回给Xray，从状态码和返回包可以看到未触发WAF拦截，Xray再根据明文响应包内容判断是否存在漏洞