What does this .htaccess do?

Am I correct in thinking that all it does is prevent automatic brute force attacks?

So, to access the wp-login.php you have to manually type in the URL of the domain so that negates all the bots seeking out wp-login.php

Am I correct?

Here's the .htaccess rule:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^https://(.*)?my-domain.com [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteRule ^(.*)$ - [F]

It appears to prevent any POST requests to wp-login.php that aren't made from a page on my-domain.com.

When the browser sends a POST request, say after submitting a form, it will include a HTTP Referrer header telling the server where the request came from.

This theoretically prevents bots submitting POST requests directly to wp-login.php as part of a brute force attack, but the HTTP referrer is trivial to fake, so it's not actually all that helpful.


What this doesn't prevent: Brute Force

all it does is prevent automatic brute force attacks?

No. This does not prevent brute force attacks.

In a brute force attack, an attacker has control over all parameters of the HTTP request. This includes the referer. As the attacker can send arbitrary referers, this does not prevent brute force attacks. (Almost) all brute force tools will allow the setting of a referer, and setting the site itself as a referer is pretty standard.

Mechanisms that do protect against brute force would be banning or throttling on an IP or username basis, as well as captchas.

What this might be intended to prevent: CSRF

This code might have been indented to add a referer check to all POST requests to the admin area. If the referer is not valid, the request is rejected.

In a CSRF attack, an attacker forces a victim to perform a state-changing POST request. This can eg happen by posting HTML and Javascript code at attacker.com, which then automatically sends a request to victim.com once an authenticated victim visits the site.

Referer checks are one mechanism to protect against CSRF. As only victim.com is accepted as a valid referer, an attacker cannot force the victim to send a request from their own domain.

Of course, WordPress has its own CSRF protection (via anti-CSRF nonces). But it might not catch all cases, and the security of plugins depends very much on the plugin developer.

An additional referer-check can help prevent CSRF vulnerabilities in WP core, and especially in plugins, from being exploitable.

Of course, if this was the intention, the code is bugged. The $ in RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$ prevents the check for most requests.

The check can also easily be bypassed. The following referers would be accepted:

Referer: http://example.com.org
Referer: http://not-example.com
Referer: http://notexample.com
Referer: http://attacker.com/example.com

To add anything to the security of the site, these two issues would need to be fixed first. The code could also be further improved by not being restricted to POST requests (in poorly-written applications, GET requests may change server-state as well, or POST requests may be transformable into GET requests). As the check only applies to administrators, this should not restrict usability.


You Are Partly Correct

Your above code helps protects your WordPress site by only allowing login requests that come directly from your domain.

Most brute force attacks send POST requests directly to your wp-login.php script. So requiring a POST request to have your domain as the referrer helps stop these bots.

You could go one step further if you have a static IP by using the following code:

RewriteEngine on 
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR}!^111\.111\.111\.111$
RewriteRule ^(.*)$ - [R=403,L]

*Replace with your static IP address.

*Might not work if your site is behind a DNS service such as CloudFlare.

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.