pikachu暴力破解--基于表单的暴力破解、验证码绕过、token防爆破
- 工具
Burp Suite、Fire fox、FoxyProxy
-
基础知识
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。 理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括： 1.是否要求用户设置复杂的密码； 2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp； 3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）； 4.是否采用了双因素认证； …等等。 千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的! 从来没有哪个时代的黑客像今天一样热衷于猜解密码 —奥斯特洛夫斯基
-
基于表单的暴力破解
随便输入用Burp Suite抓包后发送给Intruder—》集束炸弹-》添加负载-》选择字典爆破 得到账号密码 admin 12346
-
验证码绕过（server）
随便输入用Burp Suite抓包后发送给Intruder—》集束炸弹-》添加载荷-》选择字典爆破 验证码不要添加负载，保证验证码每次都相同。得到账号密码 admin 12346
-
验证码绕过（client）
随便输入用Burp Suite抓包后发送给Intruder—》集束炸弹-》添加载荷-》选择字典爆破 得到账号密码 admin 12346
-
token防爆破
随便输入用Burp Suite抓包后发送给Intruder—》集束炸弹-》添加载荷-》选择字典爆破
经测试发现每个数据包都加入了token验证机制，尝试使用pitchfork进行爆破：
pitchfork模式
在Grep Extract添加以下内容
找到密码123456
-
总结
验证码绕过（server）：
验证码不变的原因，在验证验证码之后并没有及时销毁，导致验证码被重复利用
$html=""; if(isset($_POST['submit'])) { if (empty($_POST['username'])) { $html .= "<p class='notice'>用户名不能为空</p>"; } else { if (empty($_POST['password'])) { $html .= "<p class='notice'>密码不能为空</p>"; } else { if (empty($_POST['vcode'])) { $html .= "<p class='notice'>验证码不能为空哦！</p>"; } else { // 验证验证码是否正确 if (strtolower($_POST['vcode']) != strtolower($_SESSION['vcode'])) { $html .= "<p class='notice'>验证码输入错误哦！</p>"; //应该在验证完成后,销毁该$_SESSION['vcode'] }else{ $username = $_POST['username']; $password = $_POST['password']; $vcode = $_POST['vcode']; $sql = "select * from users where username=? and password=md5(?)"; $line_pre = $link->prepare($sql); $line_pre->bind_param('ss',$username,$password); if($line_pre->execute()){ $line_pre->store_result(); //虽然前面做了为空判断,但最后,却没有验证验证码!!! if($line_pre->num_rows()==1){ $html.='<p> login success</p>'; }else{ $html.= '<p> username or password is not exists～</p>'; } }else{ $html.= '<p>执行错误:'.$line_pre->errno.'错误信息:'.$line_pre->error.'</p>'; } } } } } }
token：
当客户端请求页面时，服务器会生成一个随机数 Token，并且将 Token 放置到 session 当中，然后将 Token 发给客户端（一般通过构造 hidden 表单）。下次客户端提交请求时，Token 会随着表单一起提交到服务器端。然后，如果应用于“Anti CSRF攻击”，则服务器端会对 Token 值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将 session 中的 Token 值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的 Token 没变，但服务器端 session 中 Token 已经改变了。
同时当多页面多请求时，必须采用多 Token 同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用 cookie 存储验证信息的方法来代替 session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到 cookie 中，当第二次提交时，由于 cookie 已经有提交记录，因此第二次提交会失败。不过，cookie 存储有个致命弱点，如果 cookie 被劫持（XSS 攻击很容易得到用户 cookie），那么又一次 game over，黑客将直接实现 CSRF 攻击。
要避免“加 token 但不进行校验”的情况，在 session 中增加了 token，但服务端没有对 token 进行验证，这样根本起不到防范的作用。还需注意的是，对数据库有改动的增、删、改操作，需要加 token 验证，对于查询操作，一定不要加 token，防止攻击者通过查询操作获取 token 进行 CSRF攻击。但并不是这样攻击者就无法获得 token，只是增大攻击成本而已。
有什么不对的地方，欢迎大家指正！
