1

Since the bots send HTTP Post requests directly at the known target /wp-login.php to skip the Captcha, would it be possible to check for a custom Post Input such as the Captcha Input or my own custom input field, and then deny the request if not present?

So, using https://www.nginx.com/resources/wiki/modules/form_input/

I'm a NGINX newbie but I'm imagining something like:

location /wp-login.php {

  set_form_input $log; #input name for wp username
  set_form_input $pwd; #input name for wp password
  set_form_input $my_custom_field; #my custom input

    if (!$my_custom_field){ #my custom input field not set
      return 444;
    }
    #how to test if a variable in NGINX has been set?
}

Is something like this possible?

Thanks!

0

Generally, the approach to solve this sort of problem is to do the checks in the server-side application code - a missing or invalid captcha code both produce an authorization error. However, in this case you probably don't want to be modifying Wordpress directly.

You can check headers in Nginx, but I'm not seeing any documentation on how to check a form field - I think that's out of the scope of Nginx.

But even if it could, would that be secure? You could reject requests that don't have the captcha input, but how would you know in Nginx whether or not the captcha is correct? An attacker could send gibberish in the field and pass a simple if check. You need to be able to verify that the captcha is correct, which probably means running code in Wordpress, and any captcha-verification code should also check the presence of the field. If you're adding captchas via a plugin, I'd expect the plugin to handle this case.

  • Xiong, thanks for your reply. I want to avoid hitting the WP application to save resources. NGINX would not check the value of the POST vars, just the presence of them. No need to check Captcha. I don't believe the bots send the Captcha. I could also use Javascript to add my own custom field to the form that the bots would be unaware of. – i_a Nov 30 '17 at 1:58
  • If the bots are triggering the submit button on the page, I could disable the button until the Google reCaptcha callback is triggered. But I suspect that the bots are sending "blind" HTTP Requests to any WordPress install, without the use of the browser. So they would not know what type of Captcha is there or not. The issue is not that they might guess the log-in successfully, the issue is I want to stop their consistent attempts which consume resources. – i_a Nov 30 '17 at 2:03
  • @i_a In that case, you might want to look instead at fail2ban (there's a community-written filter for WordPress). It's not a complete security solution, but it does a great job of blocking those simple and common automated attacks before they even get to Nginx. It's a good idea to set it up for ssh, too. – Xiong Chiamiov Nov 30 '17 at 2:41
  • thanks again, the intent is to find a pre-application fix implemented in NGINX. I have run some tests with Postman simulating various Post combinations that a bot might send, and I get the same failed log-in notices from the Sucuri Plugin whether Catcha fields are included or not. – i_a Nov 30 '17 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.