0x01 API接口泄露

Web端

Web应用很多都是后端Springboot+前端Webpack的组合，在后端Springboot安全的时候，那么可以通过Webpack获取到目标系统的API接口信息。

打开一个网站，在首页源码中包含：app.*.js、index.*.js、chunk-*.js、mainfest.*.js等文件，如下图所示

要想从webpack打包的站点中提取接口信息，首先就要保证能尽可能的获取到目标站点的所有JS文件，这样才能保证不会遗漏。然而通常经过webpack打包之后站点的JS代码都是随机文件名。例如：0.955195e5b3c33331d902.js、3.021da225f1fcd1f9db3d.js等，通过常规爆破几乎不可能。但是这些文件能加载出来说明肯定是放在前端代码里面的。不妨来看一下webpack的概念。

如webpack概念所述，我们引用的静态资源都相当于是一个或者若干个模块，若访问的路径是https://www.example.com/#/login，在HTTP协议中#后面的内容称之为锚点，在webpack中称之为前端路由，webpack根据前端路由来加载各种模块，这些前端路由与模块（JS文件）绑定，我们需要做的就是在经过webpack混淆的代码中找到这些JS文件。

Google浏览器打开站点，在开发者工具中Ctrl+Shift+F进行全局搜索，搜索关键字path:"/即可查找到所有前端路由信息，然后访问对应的前端路由即可加载对应的JS文件进入到对应的功能页面，当然与后端路由一样，前端路由大多有权限校验，需要登录后才可以访问。

如上图所示，访问的前端路由是/login，webpack根据前端路由加载了login.1d3ce473.js文件。全局搜索关键字1d3ce473就可以找到这些文件名在代码中存放的地方。如下图所示，在这里存在着其他所有相关的JS某块信息，根据规则拼接即可获取JS文件名。

获取到所有的JS文件路径后，可以使用burpsuite的Intruder模块配合HaE（https://github.com/gh0stkey/HaE）插件即可快速获取到文件中的敏感信息、API接口等等，使用burpsuite intruder批量获取JS文件内容配合HaE效果如下，这种模式方便我们对不同业务功能的API接口进行一个全面的测试。

也可以根据其JS代码风格写出正则，然后用Python脚本爬取所有接口

小程序端

小程序端相对来说方法比较单一，只需要反编译小程序获取其源码，然后再提取JS接口即可，反编译小程序的教程网上很多在这里就不赘述了。反编译之后使用VScode打开目录，找到接口信息。

根据其代码风格写出正则，再使用vscode的Ctrl+Shift+L选中功能即可一键提取出所有API接口

APP端

在谈论到APP渗透测试时，总是避免不了说到脱壳。但现在二代壳、三代壳加固让脱壳变得越来越困难，今天讲几个APP不用脱壳获取API接口几个TIPS。有一些APP使用了Webview加载网页。所以在抓包时请求头中包含Referer信息，通过Referer可以定位到该功能的网页。

访问Referer的链接即可，使用与Web端相同的方法就可以获取该业务所有相关的API接口信息

还有一种APP有自己的小程序框架，所以在APP安装目录中可以找到对应的JS文件。进入APP安装目录使用find命令查找。这样操作相比于解包APP查找静态资源文件的优势是可以发现远程加载的JS文件。

使用vscode打开对应的文件夹，通过关键字批量提取即可

接口文档

大部分SpringBoot都集成了Swagger，程序员在开发应用时使用简单注解即可生成swagger的API文档。这不仅方便了程序员，也方便了我们这群“黑客”，能利用API接口文档发现越权、未授权等漏洞。swagger的默认路径有/v2/api-docs、swagger-ui.html、swagger-resources等等。

第一步我们确认Web应用的API网关，然后请求/swagger-resources即可获取swagger文档接口地址。

使用swagger-resources访问可以获取group名称

携带group参数即可获取接口文档

使用https://editor.swagger.io/可视化接口信息

巧用Springboot的特性---路径参数，这可以帮助我们绕过许多限制。

1. 绕过401认证、WAF等

访问swagger-resources返回了/v2/api-docs说明swagger存在

访问/v2/api-docs返回404，说明极有可能是服务器在NGINX做了配置或者WAF写了规则

使用路径参数即可绕过/v2;/api-docs，也可以进行变形/v2;%0A/api-docs、/v2;%252Ftest/api-docs等等绕过WAF，401认证同理。

2. ..;/穿越到API网关

在一些Web应用中，使用NGINX代理到后端的Spring Boot应用时，设定了一个特定的前缀，这个前缀直接对应的是后端Springboot应用的一级目录，如下图所示。

由于大多数Swagger文档通常存在于Spring Boot应用的根目录下，但由于NGINX代理的问题，我们并不能直接访问到后端Springboot应用的根目录。在这种情况下，可以利用 Spring Boot 的路径参数特性。利用经典的..;/在Springboot中实现目录穿越。与此不同的是，NGINX 不支持这种方式。所以通过使用 /api/..;/ 这样的方式，可以直接穿越到 Spring Boot 的根目录，使我们的攻击面变大，成功获取到了swagger接口文档。

接口测试

1. 对所有API接口进行排序，观察接口规律Fuzz接口，亦可根据接口命名规律生成自己的API测试字典

2. Intruder批量Fuzz接口的鉴权，针对未授权接口进行具体测试。

3. Token共用问题，使用低权限Token Fuzz所有API接口，判断是否存在越权问题。

4. Fuzz权限绕过;.js、%0A、URL编码、/login/../、/;/、/login/..;/等

5. 根据接口的命名针对性测试横向越权、垂直越权，例如/getUserInfoById、/resetPwd等接口。

0x02 加密对抗

加密在API安全中扮演着至关重要的角色。随着渗透测试的不断进步，绝大多数网站、APP和小程序的API接口都采用了各种加密算法或签名算法，以确保用户的请求流量不会被监听或篡改。特别是对于金融行业与互联网厂商，如果不能成功绕过加密屏障，就几乎无法深入挖掘业务漏洞。

加密算法

加密算法包括了AES、DES、RSA、SM2、SM3和SM4等，通常是采用它们的单一算法或多种算法的组合。此外，一些站点还采用自家研发的编码方法。在测试加密数据时，最关键的步骤之一是确定加密方式，以及找到相应的加密和解密密钥，这样才能成功篡改数据包。AES、DES和SM4属于对称加密算法，只要获取到相应的密钥，就可以解密数据。而RSA和SM2则属于非对称加密算法。前端使用公钥对请求数据进行加密，后端则使用相应的私钥进行解密。因此，通常只能获取到公钥用于加密请求数据，而无法用于解密请求数据。

对称加密与非对称加密

对称加密的特点是使用相同秘钥对相同数据的加密结果相同，而非对称加密的结果则不同。

使用AES/ECB/Pkcs7加密（对称加密算法）

1. 使用相同的密钥对相同的数据加密两次，加密结果相同。

2. 在对称加密中如果原数据长度到达一定长度，原数据前缀相同，那么加密结果的前缀也相似。

使用RSA加密（非对称加密算法）

加密的公钥与数据都是相同的，得出来的加密结果是不同的。但加密结果的长度相同

综上所述，当我们在针对某一网站进行测试时，观察数据包，借用上述结论先判断是对称加密还是非对称加密。

定位秘钥

通过上一步我们得出了网站的是对称加密（AES、DES、SM4）或者是非对称加密（RSA、SM2）我们根据其代码特征全局搜索就可以找到密钥了。如果没有判断出来则可以搜索其他关键字或者搜索数据包的请求参数，定位到加密的代码片段，进一步分析。

AES、DES特征关键字utf8.parse、mode.ECB、mode.CBC，AES，DES等

RSA关键字setPublicKey、BEGIN PUBLIC KEY等

SM2、SM4关键字doEncrypt、doDecrypt等

其他关键字encrypt、decrypt、secretKey、数据包请求参数等

实例分析

Burpsuite抓包分析，发现请求数据由|分割成三段，且每次加密后的数据都不同，猜测可能是三段式加密，对称加密非对称加密+对称加密+摘要算法

因为是银行相关的项目，所以猜测大概率可能是国密算法，反编译小程序搜索doEncrypt、doDecrypt关键字定位到加密算法，定位到加密算法后，发现加密算法结构复合特征。

接下来分析加密流程，通过函数名定位到对应的代码段，找到入参部分

1. 调用加密函数，第一个参数为明文数据，第二个参数为随机生成的32位秘钥，用于encrypt_ecb（对称加密算法）加密
2. 使用encrypt_ecb加密明文数据
3. 获取公钥（publicKey）用于SM2（非对称加密算法）加密
4. 使用SM2加密随机生成的32位秘钥
5. 使用SM3HASH算法获取明文数据的HASH
6. 将加密结果使用|进行拼接，发送数据
7. 服务器使用私钥解密获取encrypt_ecb的秘钥
8. 服务器使用decrypt_ecb解密用户的加密数据
9. 服务器处理数据，并使用encrypt_ecb加密返回数据，将结果返回给客户端
10. 客户端使用decrypt_ecb解密服务器返回的加密数据

现在还没有搞清楚encrypt_ecb是什么对称加密算法，AES、DES、SM4都有可能，在小程序中搜索关键字定位到代码段

代码经过混淆，没有找到明显的关键字所以还是不能确定，在小程序中尝试直接搜索AES、DES、SM4关键字，最终发现引用了sm4相关模块，说明可能是SM4的ECB加密算法。

全部加密算法已经确定，接下来需要定位秘钥，这里我们要找到的秘钥就只有一个。因为encrypt_ecb的秘钥是随机生成的，我们自己构造一个固定的即可，所以找SM2的公钥就行。通过关键字定位到获取公钥的代码段，分析代码可以得知，query.getDensePublicKeyQry.do接口获取公钥

在Burpsuite查找历史数据包获取到公钥。这里有一点很奇怪，SM2的公钥基本上是以04开头。这里并不是，且整个加密流程分析下来，也没有对公钥进行填充处理。这点先存疑

使用sm-crypto加密库对公钥进行测试，果然报错了

在公钥前手动填充04再次测试，这次没有报错。仔细观察数据包发现自己构造的加密结果与小程序加密结果长度不相同，所以还是有问题

猜测可能是小程序使用的SM库与我的SM库不同。尝试使用加密代码比较有特征的关键字在github搜索，比如：doSm3Hash就很有特征

回溯到腾讯小程序官方SM库的0.2.0版本（https://github.com/wechat-miniprogram/sm-crypto）

nodejs下载对应库：npm install [email protected]

这次不填充04，也能成功加密，但长度还是不同

换个思路，查看本地SM库与小程序的SM库，SM2的实现代码。

即使小程序的代码经过混淆，但不难看出小程序代码的12675行与本地SM库代码的16行实现方法是不同的，其他代码大致相同

修改本地库代码，如下

重新加密，长度相同。说明加密应该没啥问题了

至此加密算法分析完毕

插件&&脚本

Burpsuite

BurpCrypto https://github.com/whwlsfb/BurpCrypto

支持AES、DES、RSA以及自定义的JS脚本

优点：Burpsuite插件，可以在Intruder中直接使用快速方便

缺点：缺少国密算法，不能面对复杂情况

NodeJS

AES、DES：crypto-js

RSA：node-jsencrypt

SM：gm-crypto、sm-crypto、miniprogram-sm-crypto

优点：本身加密组件完善，可以直接将对应的代码copy下来执行。npm包管理工具安装 各种包十分方便，支持http请求。能处理复杂加密情况

缺点：需要自己写代码

原文始发于微信公众号（格格巫和蓝精灵）：SRC测试指南：从APl接口泄露到数据加解密的深入分析