Web应用中的RSA+AES加解密调节

      RSA+AES加解密原理介绍

RSA+AES客户端加密过程概括：服务端产生RSA密钥对，RSA私钥在服务端保存，RSA公钥分发给各客户端，客户端生成AES密钥作为会话密钥。发送请求时，客户端使用RSA公钥加密AES密钥生成密文1，使用AES密钥加密传输的数据生成密文2，密文1和密文2同时发送给服务端。

RSA+AES服务端解密过程概括：服务端接收客户端发送的密文1和密文2，先使用RSA私钥解密密文1得到AES密钥（即会话密钥），再使用解密得到的会话密钥解密密文2，得到传输的数据的明文。

根据密钥分发方式可以分为几种实现方式，常见以下几种：

实现方式1：客户端向服务端请求RSA公钥，客户端生成AES密钥，过程示意图如下图

实现方式2：RSA公钥硬编码在前端JS文件中，客户端生成AES密钥

在一次渗透测试中，某Web应用使用了RSA+AES的加密方式对参数进行了加密，由于担心开发人员使用参数加密而忽略了输入参数的验证，导致存在SQL注入、越权等问题，所以需要通过调试解密整个加密的过程，从而可以修改请求包中的参数进行深入的测试。

测试过程中发现，登录时的请求包的参数经过了加密，如下图：

凭借经验分享及查看js文件，得知其加密算法采用的是RSA和AES的组合的方式。于是想到通过调试获取AES密钥来解密被加密的参数，进行参数修改，进一步深入测试。具体过程如下：

寻找Web应用的加密过程，主要是找到Web应用的JS中的加解密的部分代码。一般JS代码经过混淆，看起来很复杂，但其实可以通过一些特殊的字段（比如：AES、RSA、KEY、encrypt、decrypt、publickey等等）寻找到加解密的部分代码。如图(1)：

图(1)中的代码简单解释为：

（1）getKey方法用来获取16位的随机AES的key；

（2）encrypt方式用于加密数据,从代码中可以分析出，AES的加密模式是CBC+zeroPadding，并且其中IV的数值直接取用KEY的数值；

（3） decrypt方法用于解密数据。

1、找到加密方式后，在加密处打上断点，如图(2)

2、打断点后，要想办法让代码执行到断点处，一般有三种情况：

（1）一般AES密钥可能会在打开网站的时候加载js文件生成备用，所以一般可以刷新网页即可；

（2）如果刷新没有反应，可以在登录处输入任意用户名和密码，点击登录，一般也会触发加密过程，代码会执行到encrypt；

（3）寻找其他调用加解密函数的

3、第二步顺利的话，会得到加密过程使用的AES-key参数，如图(3)的结果

4、进一步继续下一步继续跟踪函数，可以看到后续的加密过程（RSA公钥加密AES密钥及AES密钥加密数据），如图(4)

图(4)中参数解释，js的参数经过混淆，但不难发现其原本的意义：

e参数代表RSA的公钥，这里是直接硬编码在js文件中；

n参数代表使用RSA公钥加密AES密钥得到的密文；

a参数代表使用AES密钥加密数据得到的密文；

5、断点的代码可以全部执行完成，此时BP上抓包为登录的数据包,主要关注数据包中的两个参数，一个是请求头中的appSecret（即图(4)中的参数n，也就是使用RSA公钥加密的AES密钥的密文），另一个是请求体的data参数（即图(4)中的参数a,也就是使用AES密钥加密的数据的密文），如图(5)：

6、至此，也就完成了整个断点调试过程，已经获取到了RSA的公钥（公用的）和AES的密钥(只是自己的会话的AES密钥)，经过验证，js调试获取的AES密钥可以成功解密data参数，如图(6)

7、后续过程可以使用替换appSecret和重新加密的data（先解密data，修改后再加密data）进行参数的篡改

（Tips：HTTPS只是保证数据包在传输过程中是加密的，在端点处解密后，数据包内的参数都是明文的），但是无法保证参数被请求者自己篡改，所以参数加密仅仅只是增加了一点点攻击者的分析工作，无法提供任何参数输入验证的防护问题（例如SQL注入、越权（通过修改参数越权）、短信轰炸（修改手机号）等等问题）。

最后，不要误以为经过调试可以解密得到参数值就意味着加密方式存在问题，这种说法是错误的！！！因为以上所有过程均在本地调试，所有请求包都是自身请求的，所以本地调试获取的密钥也都适用于本地会话，而无法使用在其他会话中（其他会话会产生其他的会话密钥）。因此参数加密仍然可以较好的保证数据的机密性。