You’ve also just accused the authors of Apache itself of being unaware of security issues and unaware of what .* does, because they use it in exactly the same way that you rant against.
Whether there’s a security issue is not a matter of personal opinion. If a security issue exists, then you should be able to demonstrate it.
You once again insinuated that the authors of Apache itself have been doing it incorrectly. Seems to me that the burden of proof is on you to show that Apache has been doing it wrong all this time.
I won’t proceed with the opinionated arguments further anymore, I’ll just agree that we won’t see eye to eye on this, however, I will point out (.*) will not work in this scenario for any URL that ends in a /
test/
testing/
my-page/
Will all report a 404 as it tries to load test/.php, etc.
Mine would (with a small change)… as that directory doesn’t exist and I won’t match the / (forgot I put the $ on it … doh!)
RewriteEngine on
# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([a-z0-9-]+) $1.php
[edit]Or
RewriteEngine on
# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([a-z0-9-]+)/?$ $1.php
If your htaccess is in a sub-directory, yes, it can produce a directory traversal attack on your web accessible files (you could load a file that is outside of a directory the user may be keeping you in). If it is in the root, it is unlikely (I won’t say it can’t just because my local environment didn’t permit it) and you may end up with a 500 Internal Server Error
Just to make sure we’re clear, were you able to access a file outside the document root? Or could you only access a URL path that was already publicly accessible?
Sorry, that wasn’t as clear as I should have been, here is what I was able to accomplish
Web setup:
/ - root
/blog/ - subdirectory
I had a file outside of root named bad.php that was not “web” accessible, I was unable on my local setup to access that (it produced a 500 Internal Server error) just with the rewriterule we produced in this thread regardless of which directory the .htaccess file was in.
RewriteEngine on
# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# take the url and append .php to it
RewriteRule ^(.*)$ $1.php
I also had bad.php in the root directory, and when the .htaccess file is in the /blog/ directory, I could access bad.php in the root directory (but I kind of expected that).
I then made blog a subdomain and accessed it via the subdomain trying to access bad.php one level up (it also produced a 500 Internal Server error for my setup). So in this case, the bad.php is “web” accessible, but not to the subdomain.
So my conclusion is, the only thing the catch all allows you to do (which is doable anyway – so don’t take offense!) is it does allow …/ in your URL to traverse to a directory you already have access to via the web.
YMMV so I highly recommend others to do their own tests too, but it looks to be “safe” for this scenario
One other slight “weirdness” (is that a word?) that I can’t quite explain is the following:
Reviewing the rewrite logs, the /blog/…/bad doesn’t invoke the rewrite rule, so the browser or apache must be intercepting the …/ before the rewrite rule takes place…
The access.log for these instances only shows a request for /bad, does not show /blog/…/bad
