Aiming request data is encrypted and API sign protection, the burpplug is used to automatically decrypt the request ciphertext and automatically bypass the signature of the API.
Finally, making use of the characteristic that the request ciphertext does not trigger WAF, combined with the scanning tool to complete the semi-automatic vulnerability search of App protected by WAF.
- PS：项目中的插件并不是通用的，因为不同厂商针对自己业务的数据包加密算法、签名保护算法各种各样，需要先还原加密算法（或者签名保护算法），再对应的修改插件的加密算法（或者签名保护算法），笔者通过几个案例介绍这类业务的通用测试流程：常见加密算法分析流程、burp插件开发、联动Xray半自动化挖洞，主要是通过介绍这类业务的通用测试方法，降低安全测试的人力成本
- 案例：https://xz.aliyun.com/t/12295
- 项目中的两个插件源码即案例中介绍的自动加解密数据包密文、自动绕过签名保护的插件源码
在金融银行类安全测试中，经常见到数据包加密、签名保护，这种业务不能直接进行有效的安全测试，修改数据包参数会重放失败，爬虫见到密文也是懵逼
- 整体加密
- 分段加密
- 接口签名保护
对于这种业务，不管是手工还是借助工具，需要先还原加密算法（或者签名保护算法）。知道了加密逻辑后，就可以开发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插件的接口开发可以参考官方文档和官方的代码demo，https://portswigger.net/burp/extender/api/index.html
使用maven获取burp开发的接口依赖文件，插件开发规范：包名为burp，类名为BurpExtender
首先在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等动态变化的值
body中密文部分存放在encryptData参数
最后需要把返回包的密文也处理掉，由于在burp插件开发中返回包没有参数的概念，只能通过偏移获取body，解密后，用明文替换密文，再用IMessageEditorTab展示解密后的数据包
此时原始响应还是密文，因为客户端需要解密这个密文，IMessageEditorTab中明文只是展示作用，辅助安全测试，不会返回给客户端
encryptData中的密文被替换为明文展示，之后的安全测试就完全是明文了
这也是数据包加密给安全测试人员的彩蛋吧，数据包加密有一个好处：天然对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
如果直接扫描原始请求，会触发WAF拦截
9、burpB收到Xray的明文请求，加密请求中明文中包含payload的body再发给服务端，扫描器能正常工
10、查看控制台打印的密文body：
11、burpB解密响应的密文body后返回给Xray，从状态码和返回包可以看到未触发WAF拦截，Xray再根据明文响应包内容判断是否存在漏洞
