甲方安全建设系列之 HTTP 资产清洗

01

写在前面

这里的讨论的资产特指在黑盒视角下被动采集到的数据，比如来自waf、网关、被动代理等http请求日志所对应的资产，并不是主动扫描所发现的domain/ip + port + urlpath这种资产，清洗的结果也主要用于被动扫描，而非主动扫描。

21年的时候在博客简单分享过粗略的思路，本文是对前文的补充。

02

资产定义

不同于白盒的可以直接解析代码获取路由，灰盒中的注入 AbstractHandlerMethodMapping 里面拿完整的接口类的思路，黑盒视角来看，我认为只要后端的处理逻辑不同，哪怕是在同一个方法中，也是不同的资产，每个逻辑都应该覆盖扫描到。举个例子，下图代码中虽然在一个方法中，但代码根据 action 参数值的不同指向了不同的处理逻辑，黑盒中我认为是三条不同的资产。

但是 ?id=1&action=read 和 ?action=read&id=1 对于后端来说，是一致的，所以我理解的黑盒视角下资产结构如下所示：

请求方法:协议:域名:端口:URL路径:参数名称排序合集

除此类情况外，通过多层网关进行转发的请求也易出现不同参数指向不同后端的场景。

03

资产清洗

请求方法：

同一个路由，不同方法的时候对应的后端逻辑很好理解，比如常见的用请求方法来区分读写行为:

`GET /file HTTP/1.1``Host: oss.aliyun.com``   ``PUT /file HTTP/1.1``Host: oss.aliyun.com`

中间部分 协议:域名:端口 与常见的资产概念相同，不做赘述, 像 Weblogic 那种做端口复用，同端口不同协议的在业务中比较少见。

URL 路径：

主要处理 路径变量、伪静态 这类情况，举个例子：

`/api/news/1``/api/news/2`

后端可能如下图代码所示，这两路由显然属于同一个逻辑，做清洗的时候需要识别出 id 这个路径变量，做归一处理。

参数排序集合：

为什么需要排序在上文中以及提到过，值得一提的是，取参数时应该解析完整的 query、body、formdata、json 。比如 JSON 应该遍历出所有的 JSON key 参与排序。

基础了解了，下面让我们实践清洗一下资产：

`GET /api/news/1d8544e3-c8a3-96ad-468a-346b638205d7 HTTP/1.1``Host: test.com``   ``GET /api/news/f75cfe2a-3f41-2769-3f0d-66b8ca995e46 HTTP/1.1``Host: test.com``   ``GET /api/author/P10086 HTTP/1.1``Host: test.com``   ``GET /api/author/WB10010 HTTP/1.1``Host: test.com``   ``GET /api/taskname/shM8VNcx HTTP/1.1``Host: test.com``   ``GET /api/taskname/djkoD8Rw HTTP/1.1``Host: test.com``   ``GET /html/preview?c81e728d9d4c2f636f067f89cc14862c=f4f59e822581d785ba910fbf3f268eca79db8204&id=2 HTTP/1.1``Host: test.com``   ``GET /html/preview?665f644e43731ff9db3d341da5c827e1=df2cd7104536553afde9f7d66133d578eccb4606&id=1 HTTP/1.1``Host: test.com`

肉眼望过去，上述请求清洗下来就是5条资产，但后两条显然是同一个资产，这个例子一般用于防缓存，实践中研发有非常多奇奇怪怪的写法会导致一堆脏数据。

加一点清洗处理细节

1. 路径处理时不同级路由之间用 / 切割开来做 int 、uuid、hash 类识别，并替换成占位符。此类字符结构固定，用正则处理即可。

2. 递归解析所有嵌套的参数名，同样做字符类型识别，然后再参与去重排序。

3. 将 URL路径:参数名称排序合集 字符切割交给随机字符识别模型进行处理，识别到的随机字符也替换成占位符。

4. 拼接 请求方法:协议:域名:端口 后放入缓存，后续已缓存的则视作重复资产，不再入库。

5. 重组并重放请求，识别响应是否为 404（主要针对 waf 类可能有脏数据，且无响应详情，业务又无脑响应状态码 200 的无法直接判断的情况）

值得一提的是这里提到的随机字符识别用不上大模型，本质上就是个文本分类问题（区分字符串是随机的，还是有意义的），有非常多成熟的算法和词库，自己训练一个成本很低，CPU 就能上。

04

写在后面

实践中在每天几千万访问的请求的业务环境下，Flink 清洗完在一两万条资产，比业务实际接口量多一些，还是挺稳的，很少出现脏数据，结合过往分享过的 fuzz 思路，作为在自动的安全测试流程中的一环，漏洞发现效果还是挺不错的；或者写几条sql查查容易存在漏洞的参数，也能挖到不少漏洞；再或者重放一下所有请求，做敏感信息识别；删掉 cookie 重放做未授权发现；统计一次访问频次，用来发现僵尸接口；怎么玩就看个人发挥了。

或者换个名词 -- API 安全，骗骗自己，唬唬甲方也不是不行