改包的防范
目前流行的防止改包方式主要是这么几个方面
-
请求参数和路径的加密
如果原始请求是GET请求，或防止访问者获取请求路径，通常会将用户实际的请求路径和GET请求参数封装都封装为POST请求的请求体，通过加解密网关再还原为原始GET请求传入后端分布式服务上。 在APP中比较常见。
表现的形式通常为： 抓包后发现访问任何功能都是同一路径，并且请求全为密文 -
请求体的加密
这类在纯web中最常见， 通常仅仅加密接口请求的请求体内容，但有以下几类加密问题。
| 方法 | 含义 |
|---|---|
| 使用固定密钥 | 这种情况一般JS中会存储密钥， 属于最简单的一种。 |
| 使用动态密钥 | JS中不存储，一般用户第一次请求后将密钥加密写入COOKIE或本地存储中， 这类加密追踪难度较大。 |
| 对称加密 | 加解密数据包内容同一套密钥。 |
| 非对称加密 | 加密一套解密一套。 |
| 算法 | 算法就不是特别固定了， 常见的诸如AES RSA等， 也经常遇到国密算法或一些冷门算法。 |
- 签名
签名的应用也十分广泛，app，小程序和现在许多web中均存在，签名的构成主要是以下几点：
| 构成部分 | 含义 |
|---|---|
| RequestId | 了防止重放攻击, 客户端生成随机RequestId 服务端接收后保存至Redis中, 如果再次接收到此RequestID, 则视为非法请求 |
| 时间戳 | 添加时间戳的超时时间, 一旦超时, 原始数据包失效 |
| 签名本身 | 通过 requestId + 原始请求体或请求参数 + 时间戳 + 盐值合并生成哈希值 从而保证以上参数的有效性和唯一性 |
JS逆向
我在项目上很多都是直接浏览器 debug 来进行测试的，导致效率极低（主要是传入工具到现场也是巨麻烦的一件事情，并且现场环境问题也可以导致工具不可用），在靶场练习中学习使用工具联动 bp 进行测试。
那么开始我们的加解密之旅。
经典的一个开局登录框，随便输入点什么看看数据包的请求。
可以很明显的发现请求数据被进行了加密，这时就无法就行修改数据来进行测试了，但是做为一个勇敢的安服，必须给他拿下。
先打一个 XHR 断点来查看加密是怎么产生的。
然后重新发送一个请求包，可以发现请求已经被断住了，然后往上翻一下就可以看见加密过程。一个 aes 加密，并且是写死在前端里的，这种情况基本上极少遇见到，我到现在就只遇到过一次是将密钥写死在前端，并且还是个小程序。可能开发也没想到怎么去调试小程序吧（遇到过开发只知道微信小程序开发程序能进行调试 ）。
使用 bp 的 autoDecoder 来进行自动加解密。设置我们拿到的 key 和 iv ，然后保存配置，名称随意叫。 使用方法-1 使用方法-2
在 http 历史里找到请求包，发送到重放模块中重放一次，就会出现 autodecoder ，点击到 autodecoder 中，右键发送到重放模块或者爆破模块中使用。日志中也可以看到我们重放的包已经进行加密处理了。
