Home / server / Questions / 1037108
In Process
MrCarrot
Asked: 2020-10-10 08:33:46 +0800 CST

mod_security 403 forbidden response is returning homepage content with WordPress mod_rewrite

  • 772

I'm using mod_security on various websites, some WordPress and some not.

I notice that on a non WordPress website the following:

https://test-site.com/?exec=/bin/bash

returns a 403 forbidden error code, along with the Apache "forbidden" error page. The mod_security error is written to the log.

However, on a WordPress install, bizzarely, the following:

https://wordpress-test-site.com/?exec=/bin/bash

returns a 403 forbidden error code and writes the error to the log, however it dispays the contents of the homepage, rather than the Apache "forbidden" error page.

I note that it behaves correctly on any other page, other than the homepage:

https://wordpress-test-site.com/some-page/?exec=/bin/bash

The above works as expected, and returns the Apache error page.

I can only assume this is some conflict with WordPress's mod_rewrite rule which is as follows:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Is there something I'm missing here? I don't want to display the homepage content when a mod_security rule is matched via the homepage.

wordpress mod-rewrite apache-2.4 mod-security

2 Answers

  1. I can only assume this is some conflict with WordPress's mod_rewrite rule

    It actually looks like the opposite is happening. Only when you request https://wordpress-test-site.com/<something> do the mod_rewrite directives actually do anything. When you request the document root, then the mod_rewrite directives simply don't match and instead the request is rewritten to index.php by mod_dir as an internal subrequest (the DirectoryIndex document).

    However, I would expect the same behaviour from the non-WordPress test site as well, assuming you have a DirectoryIndex document present?!

    Having said that, I would have expected the mod_security rule to have taken priority here?

    To test this theory, you could try changing your WordPress .htaccess to the following: (I assume you are using .htaccess since the mod_rewrite directives as posted are intended to be used in a directory context.)

    DirectoryIndex disabled

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ /index.php [L]
</IfModule>

    UPDATE: Note the 2 changes from the original directives. The RewriteRule pattern is now ^, not . and the RewriteCond directive that checks whether the request maps to a directory is commented out.

    This forces requests for the document root to also be processed by the mod_rewrite directives (marginally less efficient). Since we have commented out the directory filesystem check it means that directories will not be accessible (although that is rarely a requirement).

    • 1

  2. Thanks to @MrWhite in the comments, on Centos I discovered a file called /etc/httpd/conf.d/welcome.conf which contains:

    <LocationMatch "^/+$">
    Options -Indexes
    ErrorDocument 403 /.noindex.html
</LocationMatch>

    Since there is no file called .noindex.html the 403 error document itself was triggering an internal 404 error.

    Commenting out the lines above fixed the issue.

    • 1