数据包签名校验的Web安全测试实践

01

测试场景

在金融类的Web安全测试中，经常可以见到Web请求和响应数据包加密和签名保护，由于参数不可见，不能重放请求包，这类应用通常不能直接进行有效的安全测试，爬虫也爬不到数据。

02

解决思路

对于这类应用，不管是手工测试还是借助工具，需要先还原加密算法（或者签名保护算法），了解加密逻辑后可以开发Burp插件完成明文状态下的安全测试，最后借助密文数据天然对WAF免疫的优势联动漏扫工具完成自动化的安全测试（但逻辑漏洞还得需要手工挖掘）。

本文笔者通过几个案例介绍这类应用的通用测试流程：

加密算法分析→Burp插件开发→联动漏扫。

03

案例说明

1

签名校验示例

许多应用的常见签名的生成算法是：

sign = MD5(sort(业务参数+时间戳+其他参数))

客户端和服务端使用相同的算法生成sign，服务端接收到请求后，先计算一次sign，如果业务参数、时间戳、其他参数中有一个被修改过，得到的sign与客户端发送的sign就会不一致，签名校验就会失败，服务端便不再处理请求。

以下是判断签名校验算法的示例步骤：

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

2、修改参数icon_type的值为11，再次重放，此时会提示"message":"sign invalid"，请求中的api_sign就是签名值，所以首先需要知道api_sign的计算逻辑。

3、用URL参数作为关键字搜索，在JS文件中定位api_sign，设置断点。

4、刷新网页，JS脚本执行停在断点位置，单步步入进入函数内部,可以看到app_key和app_pwd的两个参数，然后单步往下走，参数c的值此时为

device_id=069c8db0-af49-11ed-9a08-3b99f11ff116×tamp=1676725825997&session_token=G2de7f3ab78910b46ad8c07d6e25c627&app_key=f6aefd6691f04573bdf9e044137372bc

也就是请求头的参数值。

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、最终函数返回的字符串为：

f6aefd6691f04573bdf9e044137372bcOic72e78efefe6b4577a1f7afbca56b6e28993c06ea4bb84cde8dd70e58