不乱于心,不困于情。
不畏将来,不念过往。如此,安好。

前端加密加签之sqlmap自动化测试

前言

前阵子遇到某项目,在渗透测试过程,本想使用sqlmap测试一下站点有没有sql注入,无奈发现站点对携带的所有请求参数,做了前端加密并且对加密证书做MD5,一旦改包服务器就提示数据被篡改。于是我想到mitmproxy,可以让sqlmap将明文参数代理到mitmproxy然后使用手写的python脚本加密后发到服务器,从而实现自动化测试。

前置知识

AES 加密模式介绍

AES 加密的模式主要有五种:ECB (电子密码本模式)、CBC(密码分组连接模式)、CTR(计算器模式)、CFB(密码反馈模式)、OFB (输出反馈模式)。这五种工作模式主要是在加密器的使用上有所区别。在这里主要介绍下 ECB 和 CBC 这两种开发者最常用的两种加密方式。

ECB 模式

其使用方式是一个明文分组加密成一个密文分组,相同的明文分组永远被加密成相同的密文分组。直接利用加密算法分别对每个 64 位明文分组使用相同的 64 位密钥进行加密。每个明文分组的处理是相互独立的。

优点:

简单;

有利于并行计算。

缺点:

相同的明文块会加密成相同的密文块,安全性低。

CBC 模式

引入一个初始向量 IV,它的作用跟 MD5 加盐有些类似,可以防止相同的明文块加密成同样的密文块。IV 是初始向量,参与第一个明文块的异或,后续的每一个明文块,都与它前一个密文块相异或。这样就能保证相同的明文块不会被加密为相同的密文块。

优点:能隐蔽明文的数据模式,在某种程度上能防止数据篡改 , 诸如明文组的重放 , 嵌入和删除等,安全性高。

缺点:无法并行计算,性能相对 ECB 低,会出现错误传播 (errorpropagation)。

MitmProxy介绍

顾名思义,[mitmproxy](https://mitmproxy.org/) 就是用于 MITM 的 proxy,MITM 即中间人攻击(Man-in-the-middle attack)。用于中间人攻击的代理首先会向正常的代理一样转发请求,保障服务端与客户端的通信,其次,会适时的查、记录其截获的数据,或篡改数据,引发服务端或客户端特定的行为。

不同于 fiddler 或 wireshark 等抓包工具,mitmproxy 不仅可以截获请求帮助开发者查看、分析,更可以通过自定义脚本进行二次开发。举例来说,利用 fiddler 可以过滤出浏览器对某个特定 url 的请求,并查看、分析其数据,但实现不了高度定制化的需求,类似于:“截获对浏览器对该 url 的请求,将返回内容置空,并将真实的返回内容存到某个数据库,出现异常时发出邮件通知”。而对于 mitmproxy,这样的需求可以通过载入自定义 python 脚本轻松实现。

案例

在一次漏洞挖掘过程中,发现请求参数加密,并对加密参数做了MD5校验。我们该如何利用mitmproxy配置代理给sqlmap,并自动化将参数加密转发到服务器,让sqlmap正常工作。

发现加密

点击查询功能,使用burp抓包发现,请求参数做了加密。

逆向加密算法

右键查看登陆网页源代码寻找加密方法。

设置功能断点,点击查询发现使用的是AES加密。

获取aes加密的key和iv。

站点还对密文和ID等做了MD5赋值给UVD参数。

这时候我们有了加密的大致思路。

明文 -> AES加密  -> 密文

密文 + _cssstyleuser + _formPageGuid  -> MD5

将密文和MD5同时传入服务器。

编写自动化脚本

写一个mitmproxy代理脚本实现对参数加密和加签。

最后,启用mitmproxy代理并加载脚本。

mitmdump.exe -p 8080 -s [python脚本]

启动sqlmap并设置mitmproxy的代理(注意需要将res.txt的密文参数替换成明文)。

python sqlmap.py -r res.txt --proxy=http://127.0.0.1:8080

成功跑出了注入漏洞。

总结

站点有时会通过加密或加sign等方式使自动化工具无法使用,当我们遇到加密参数时我们可以分析前端JS文件,逆向加密过程和加密方式。了解自动化工具的工作原理前提下,再借助可编程的WEB代理等工具,可以使自动化工具依旧可以用

赞(0)
未经允许不得转载:seo优化_前端开发_渗透技术 » 前端加密加签之sqlmap自动化测试