运维安全2.2—暴力破解的绕过和防范(验证码&token)实验
- 2019 年 10 月 8 日
- 笔记
概述
- 暴力破解只不安全的验证码分享
- on client
- on server
- Token可以防暴力破解吗？
- 暴力破解常见的防范措施
验证码认证流程
验证码绕过实验
On client(client端)
场景展示：
请求分析：
POST /pikachu/vul/burteforce/bf_client.php HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 49 Connection: close Referer: http://127.0.0.1/pikachu/vul/burteforce/bf_client.php Cookie: PHPSESSID=pdlm34mt5smvnjc3jca054otl0 Upgrade-Insecure-Requests: 1 username=ad&password=add&vcode=1WTL0&submit=Login
检查请求页面的源码：右击——查看页面源码
即，在前端用javascript实现的验证码。
将请求发送到Burpsuite 的 repeater模块：
repeater模块能复现请求，修改vcode后发送请求：
分析response信息：
由上图发现，在没有输入验证码的时候，直接返回的是"username or password is not exists~"，说明提交的验证码并没有在后台做验证！
讲该请求发送到intruder模块，因为验证码并未进行校验，所以可以直接跳过验证码进行爆破，方法和2.1节一样，爆破结果如下：
不安全的验证码—On client常见问题
- 使用前端js实现验证码(纸老虎)；
- 将验证码在cookies中泄露，容易被获取；
- 将验证码在前段源码中泄露，容易被获取。
On server(server端)
场景展示：用正确的用户名和密码，错误的验证码登陆
然后用正确的验证码和错误的用户名密码登陆，进行请求分析：
POST /pikachu/vul/burteforce/bf_server.php HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 53 Connection: close Referer: http://127.0.0.1/pikachu/vul/burteforce/bf_server.php Cookie: PHPSESSID=pdlm34mt5smvnjc3jca054otl0 Upgrade-Insecure-Requests: 1 username=1111&password=2222&vcode=tkcgz7&submit=Login
将请求发送到repeater模块；
不提交验证码或输入错误验证码，看返回结果：
由此说明，后台对验证码做了校验；
检查验证码会不会过期，生成一个新的验证码，进行多次请求，看返回结果：
用同一个验证码请求多次，返回结果均为上图信息，说明验证码没有做过期处理，即验证码可以重复利用。
再次用2.1节中的方法进行破解，便可以爆破成功！
源码分析
未对验证码设置过期时间！
不安全的验证码—On server常见问题
- 验证码在后台不过期，导致可以长期被使用；
- 验证码校验不严格，逻辑出现问题；
- 验证码设计的太过简单和有规律，容易被猜测。
防范措施
- 设计安全的验证码(安全的流程+复杂而又可用的图形)；
- 风控规则：对认证错误的提交进行计数并给出限制，比如连续5次密码错误，锁定2小时；
- 必要的情况下，使用双因素认证。
Token对防暴力破解的意义
一个简单的token示例：
一般做法：
- 将token以"type= 'hidden'" 的形式输出在表单中
- 在提交认证的时候一起提交，并在后台对其进行校验
但是， 由于其token值输出在前端源码中，容易被获取，因此也就失去了防暴的意义。
一般Token在防止CSRF上会有比较好的功效。
(adsbygoogle = window.adsbygoogle || []).push({});
