前端加密对抗-1

改包的防范#

    目前流行的防止改包方式主要是这么几个方面

1. 请求参数和路径的加密
   如果原始请求是GET请求，或防止访问者获取请求路径，通常会将用户实际的请求路径和GET请求参数封装都封装为POST请求的请求体，通过加解密网关再还原为原始GET请求传入后端分布式服务上。 在APP中比较常见。
   表现的形式通常为： 抓包后发现访问任何功能都是同一路径，并且请求全为密文

2. 请求体的加密
       这类在纯web中最常见， 通常仅仅加密接口请求的请求体内容，但有以下几类加密问题。

方法	含义
使用固定密钥	这种情况一般JS中会存储密钥， 属于最简单的一种。
使用动态密钥	JS中不存储，一般用户第一次请求后将密钥加密写入COOKIE或本地存储中， 这类加密追踪难度较大。
对称加密	加解密数据包内容同一套密钥。
非对称加密	加密一套解密一套。
算法	算法就不是特别固定了， 常见的诸如AES RSA等， 也经常遇到国密算法或一些冷门算法。

3. 签名
       签名的应用也十分广泛，app，小程序和现在许多web中均存在，签名的构成主要是以下几点：

构成部分	含义
RequestId	了防止重放攻击, 客户端生成随机RequestId 服务端接收后保存至Redis中, 如果再次接收到此RequestID, 则视为非法请求
时间戳	添加时间戳的超时时间, 一旦超时, 原始数据包失效
签名本身	通过 requestId + 原始请求体或请求参数 + 时间戳 + 盐值合并生成哈希值 从而保证以上参数的有效性和唯一性

参考

JS逆向#

    我在项目上很多都是直接浏览器 debug 来进行测试的，导致效率极低（主要是传入工具到现场也是巨麻烦的一件事情，并且现场环境问题也可以导致工具不可用），在靶场练习中学习使用工具联动 bp 进行测试。

    那么开始我们的加解密之旅。

    经典的一个开局登录框，随便输入点什么看看数据包的请求。

    可以很明显的发现请求数据被进行了加密，这时就无法就行修改数据来进行测试了，但是做为一个勇敢的安服，必须给他拿下。

    先打一个 XHR 断点来查看加密是怎么产生的。

    然后重新发送一个请求包，可以发现请求已经被断住了，然后往上翻一下就可以看见加密过程。一个 aes 加密，并且是写死在前端里的，这种情况基本上极少遇见到，我到现在就只遇到过一次是将密钥写死在前端，并且还是个小程序。可能开发也没想到怎么去调试小程序吧（遇到过开发只知道微信小程序开发程序能进行调试 ）。

    使用 bp 的 autoDecoder 来进行自动加解密。设置我们拿到的 key 和 iv ，然后保存配置，名称随意叫。 使用方法-1 使用方法-2

    在 http 历史里找到请求包，发送到重放模块中重放一次，就会出现 autodecoder ，点击到 autodecoder 中，右键发送到重放模块或者爆破模块中使用。日志中也可以看到我们重放的包已经进行加密处理了。