介绍
Internet上遍布Web表单。即使是通常不允许普通用户登录的网站，也可能会有一个管理区域。在运行和部署站点时，确保用于访问敏感控件和管理面板的密码尽可能安全是很重要的。
攻击Web应用程序的方式有很多，但是本指南将介绍如何使用Hydra对登录表单执行暴力攻击。选择的目标平台是WordPress。它很容易成为世界上最流行的CMS平台，并且因管理不善而臭名昭著。
记得，本指南旨在帮助您保护WordPress或其他网站。在您不拥有或没有书面测试许可的网站上使用是非法。
设定
在做任何事情之前，您将需要一个WordPress网站来定位。本指南还假定您在自己的计算机上托管WordPress网站。如果您需要有关在计算机上设置LAMP的帮助，请查看我们的Debian灯和Ubuntu LAMP指南。
您可以在常规Linux安装或Kali Linux安装上执行此操作。如果您使用的是Kali，请按照来自源代码的Debian LAMP指南。只需确保在所选的任何系统上都安装了Hydra和cURL。它们在大多数存储库中都可用。
如果您真的不想使用常规安装，则可以肯定地使用另一台计算机，只需将目标计算机的IP地址替换为localhost，并确保可以从受攻击的计算机访问目标计算机。
收集信息
一旦WordPress启动并运行，就可以找到有关目标安装的尽可能多的信息。这意味着了解登录表单的构建方式，提交表单时发生的情况以及成功登录后可能发生的情况。
HTML来源
通过导航到登录页面开始。你可以在找到它localhost/wp-login.php。使用浏览器的功能检查源代码。您可以右键单击页面上的某个位置，然后选择”View Source”或“检查元素”。无论哪种方式，您都可以通过不同的方式查看源。
在代码中间搜索。您正在寻找标签。那是实际的登录表格。该表格内有一些您需要的信息。
在收集信息之前，请检查表单是否发送GET或POST请求。在表单的第一行中，应该有一个如下所示的方法选项：method="post"。对于WordPress，它是POST。
首先，找到用户名输入。它看起来应该像下面的行。
<input type="text" name="log" id="user_login" class="input" value="" size="20" />您需要的部分是name。在这种情况下log。
接下来，找到密码输入。它看起来应该相似。
<input type="password" name="pwd" id="user_pass" class="input" value="" size="20" />再次，找到name这是pwd。
您还需要标识提交按钮，以便Hydra可以提交表单。
<input type="submit" name="wp-submit" id="wp-submit" class="button button-primary button-large" value="Log In" />记录两个name和value。
最后一件。如果您没有注意到，则在表单底部有两个隐藏字段。一个告诉WordPress在提交表单时进行重定向，另一个告诉WordPress在提交表单时将查找的cookie。您需要Cookie。
<input type="hidden" name="testcookie" value="1" />同样，记下name和value。
curl
尽管通过查看HTML源代码可以获得很多信息，但是在释放Hydra之前，您还需要了解更多信息。但是，在大多数情况下，您仅可以使用收集到的信息来执行测试。您只需尝试使用不正确的凭据登录，记录错误消息，然后将该消息用作Hydra中的失败测试条件。
但是，WordPress的设计有所不同，实际上没有很好的方法来测试登录失败的尝试。因此，您需要测试登录是否成功。因为您可以维护自己的WordPress安装并登录。它，如果您要为客户端测试系统，那不会有什么不同。您在本地找到的条件应该是WordPress通用的。
这里也有另一个皱纹。您还记得表单中的隐藏重定向字段吗？好吧，这种重定向可以防止您也使用单词”Dashboard,”之类的条件来测试成功。您将不得不看一下请求本身，为此，有cURL。
为了进行比较，您首先需要查看带有cURL的原始登录页面。
$ curl -v http://localhost/wp-login.php
大多数信息与您在浏览器中查看的源代码相同。不过，最顶部是有关HTTP请求的信息。注意此信息。您需要将其与成功登录进行比较。
您需要做的下一件事是使用cURL成功登录。为了做到这一点，您将需要上一个请求中的cookie。看一下HTTP数据，然后找到与下面类似的一行。
You're going to need the wordpress_test_cookie=WP+Cookie+check part.
Alright, now you're going to need the information that you gathered from the HTML along with that cookie to make the request. This is what it should look like.
curl -v --data 'log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1' --cookie 'wordpress_test_cookie=WP+Cookie+check' http://localhost/wp-login.php
So, you have the same basic request as before, but this time, you are using the --data flag and the --cookie flag to pass cURL which form data you want to interact with and that cookie, so the form will actually submit.
That data string, log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1 corresponds directly to the information that you gathered in from the HTML. It is saying to plug the value "username" into the input called log and the value "realpassword" into the input called pwd. Make sure to use the actual username and password to log in. Then, use the submit with the name wp-submit and a value of Log In to submit the data. At the end is testcookie with a value of 1. That's just telling cURL to submit that along with the rest of the form data.
When cURL completes the request, you really won't see any HTML, just a lot of request information. Remember that redirect that made testing with "Dashboard" not work as a test condition? Well, now the redirect itself will be the test condition. Take a look at the line below.
That line wasn't in the previous request. It also doesn't contain any specific information related to that user or login. That means that it will always be present during a successful WordPress login, making it the perfect success condition to test with.
Testing With Hydra
Finally, you have everything that you need to test your passwords with Hydra. The point of this guide isn't so much to cover Hydra syntax, but it will break down the command used. If you want to learn more about Hydra, check out the SSH guide that goes into much more detail.
There is really only one command that you need for Hydra to run through possible usernames and passwords to test the security of your WordPress site. The easiest thing to do is take a look at the command and break it down.
$ hydra -L lists/usrname.txt -P lists/pass.txt localhost -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'
Okay, so this is obviously a lot to take in at once. The -L flag tells Hydra to use a wordlist of usernames at lists/usrname.txt. Similarly, the -P flag tells Hydra to use a wordlist of passwords at lists/pass.txt. localhost tells Hydra to target localhost, and -V tells it to log every test in the console output.
The rest of the command deals with the HTTP request itself. http-form-post activates the Hydra module for handling HTTP forms with a POST method. Remember from before that the WordPress login form is in face a POST from. The string that follows contains all of the parameters that Hydra will use. You should notice that it is very similar to the one used to log in through cURL.
The string consists of different sections separated by :. The first part is the exact address that is being tested, /wp-login.php. The next part is almost exactly like the one used by cURL. It passes values into the form and submits it, including the cookie. Instead of passing literal values, Hydra is actually using variables. Notice in log=^USER^ and pwd=^PASS^. Those are variables separated out with the carrot character that take the values from the wordlists and pass them along in the request for each test that Hydra runs.
The very last piece of the string is the test condition. S signifies that it is testing for success. If you wanted to test for failure, you'd use F. You set that equal to the word or phrase that it is testing for. Think if it almost like grep.
When you run this, you should get a positive result, provided the correct username and password are in the wordlists that you provided Hydra.
Closing Thoughts
First off, congratulations on making it through all of that. If you've made it through, you now have a solid method for testing the password strength of your WordPress user accounts.
This guide was tailored towards WordPress, but you can easily follow the same steps to test out other web forms. If you run a web application with multiple users, it is definitely a good idea to make sure that they are using strong passwords. This can help inform your password policy. Again, make sure that you are always only testing with permission.