Sorry about posting a link to [ad removed] in response to your suggestion I contact WP support for “help”. Sorry for spamming your thread bro.

~Out

I’m still not seeing what this actually does. So you are saying that these rules should only be put in place BEFORE you actually install wordpress?

The added lines state that if the request is for a file in the wordpress directory (which can/must be changed if the directory does not match your installation), and the referer is not the site (which can/must also be changed to match your installation), then the request is redirected to the root of the site (which can/must also be changed to match your preference and installation).

The remaining ruleset is the Wordpress default, which is the same in any Wordpress installation which manages .htaccess. Reading the ruleset, you can see that it lets each request through for handling by index.php, unless the request is for an actual directory or file. I suggest you read the Wordpress documentation on permalinks and read the parts of Wordpress that handle permalinks (i.e. index.php and referred functions) for a detailed explanation.

If you have issues with the default ruleset, I suggest you contact the Wordpress development team.

Ya interesting discussion. I would like for you to explain where I was incorrect in my assessment of the negative SEO aspect. Let me simplify my objections so you can better explain.

Basically, Googlebot finds a link to Hiding wordpress installation files in the comments section of the AskApache Password Protect plugin page, so then Googlebot, which has to act in accordance with the RFC HTTP client specifications just like any user-agent/browser, makes a GET request for this page with the referral header being set as the askapache.com plugin page.

If I understand, this code would then issue a 301 Permanent redirect to Googlebot instructing it to go to your blogs home page instead. When Googlebot or other search engine robots receive a 301 permanent redirect they usually take the redirecting URL OUT of their search index.

But once googlebot was on your homepage, any links to your site that it followed from there WOULD be allowed because googlebot would then set the referall header to your site.

When Googlebot receives a 301 redirect like this, it actually transfers some of the page-rank associated with the page issusing the redirect, to the page it is being redirected to. So this could actually boost the page-rank of your home-page, its a tricky thing.

p>

AskApache: Again, your claim that the “hiding” technique has negative effects on SEO are false. The article simply extends the Wordpress rewrite rules.

Other than that, your reasoning about the article is mostly correct.

Your reasoning about the security challenges with your own plugin, however, are faulty. If someone wants to bypass HTTP Basic authentication over an insecure transport, they will be able to do so. Without a secure transport, the authentication cannot be trusted.

AskApache Password Protect adds some serious password protection to your WordPress Blog’s admin directory. Imagine a HUGE brick wall protecting your frail .php scripts from the endless attacks of automated web robots and password-guessing exploi…

Yes that is the most common argument against it, though its really a non-issue for 99% of sites. For an attacker to bypass the HTTP authentication on a non-encrypted connection, they would literally have to have a physical connection to a network path between an authenticated user and the server. The only issue is that the password and username are passed in cleartext, but you would have to be able to sniff the data off the wire to bypass it. As you can imagine, most of the automated exploit tools and bots performing mass exploits against WordPress blogs and other online software do not have this capability, so they are stopped dead. For sites that I admin that require a bit more security, I completely agree with you that SSL is mandatory, which encryts the connection and thereby prevents an attacker with physical access who can sniff your connection from seeing the password pass in plaintext. That can be a very secure setup.

Your logic and solutions to this problem are completely accurate and insightful, as you say here:

If it is for a file or a directory, then Apache handles it (it falls through all the rewriting rules). This means that Apache will serve any file or directory as long as it can be read, which of course includes the WordPress installation files…. The desired situation is that people should only be able to read this files through “indirect” requests from your website, and not by accessing them directly.

The problem is accomplishing that by using the HTTP_REFERER header is simply impossible and ineffective. And of course the biggest problem for most blog admins would be the overwhelmingly negative effects on SEO.

Apache’s modrewrite module only has 1 variable that can achieve your solution effectively, which is what the AskApache Password Protect plugin utilizes. Basically, the special variable THEREQUEST contains the FULL HTTP request sent by the client, in fact, the internall operation of the server rely almost exclusively on this variable to determine the values of other variables, like the QUERYSTRING, PROTOCOL, REQUESTMETHOD, etc.. THE_REQUEST looks like this.

"GET /wordpress/wp-content/plugins/ HTTP/1.1"

The reason this plugin is so special is because this is the only time the request is unfiltered. Basically ONLY external requests like clicking on a link or typing a link in a browser will cause this value. Other than using the REDIRECT_STATUS variable for those using cgi, this is the only way to determine whether a request is direct or indirect.

To take it further, I’ve removed directory index generation and using the DirectoryIndex command to point to a static file we can make sure that directories can’t be browsed. I’ve also used the NS or nosubrequest flag to make sure internal uri requests by apache and other modules are able to pass through. I would encourage you to try accessing files at askapache.com if you would like a demonstration.

Options -Indexes DirectoryIndex /wordpress/index.php

ErrorDocument 403 /forbidden.html

RewriteEngine On RewriteBase / RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /wordpress/wp-(includes|admin|content)/?.* [NC] RewriteCond %{REQUEST_FILENAME} ^.+.php$ [NC] RewriteRule .* – [F, NS]

I just noticed you wrote this a couple years ago, which is before I heard of this technique. This is just to add to your excellent article, as its a great idea and one of the better and easier ways to really increase your security. Subscribed!

The spoofing of referrer headers you mention is true, and the post also discusses this issue.

The Wordpress installation files that the post refers to consists of all files installed when you install Wordpress, which includes both the wp-admin folder, and the other folders you mention.

I fail to see how your supplied .htaccess file works. As far as I can tell, this will deny any request for files below wp-includes and wp-content which are not PHP files. Please correct me if I’m wrong.

Your AskApache plugin solves a different problem, namely authenticating through HTTP Basic authentication, which itself is not a security measure, and relies on a secure connection, such as TLS, to achieve secure authentication (see Wikipedia for a basic introduction).