Deny access to any URL containing certain word(s) - .htaccess

Something is continually hammering my website adding PLACEIMPMACROHERE to the end of URLs. I am not sure what it is, but it doesn't look good. So I'd like to thwart it if possible.
'Place IMP Macro Here' as if it's some bot/flooding script and it hasn't been configured yet.
How could I block any URL ending in PLACEIMPMACROHERE, it appears as if it's a folder. It hits like this:
www.website.com/directory/another-directory/PLACEIMPMACROHERE
Or anywhere, not always the same location, sometimes:
www.website.com/directory/PLACEIMPMACROHERE
I tried this but with no success
RewriteCond %{THE_REQUEST} PLACEIMPMACROHERE [NC]
RewriteRule .* - [F]
Does anyone see where that's going wrong or is it entirely wrong?

I agree with Jon Lin, your mod_rewriting should work, though it could be simplified:
RewriteRule PLACEIMPMACROHERE - [F]
That said, I'd suggest you use the FilesMatch directive:
<FilesMatch "PLACEIMPMACROHERE$">
order allow,deny
deny from all
</FilesMatch>
I believe it's less resource-intensive, and also less complex.

The rule that you have should work, it simply checks for that phrase anywhere in the request, and not just at the end. You can do that by adding another character as a check, also make sure that rule is before any other ones you have and is in the htaccess file in your document root:
RewriteCond %{THE_REQUEST} PLACEIMPMACROHERE($|\ |\?) [NC]
RewriteRule .* - [F]
Oh, also make sure you turned on the rewrite engine:
RewriteEngine
somewhere near the top of your htaccess file.

Related

How to edit .htaccess for mydomain.com/tag/iphone/iphone-manual to mydomain.com/iphone/iphone-manual

I need to edit my .htaccess to do something like this:
from URL example.com/tag/iphone/iphone-manual to URL:
example.com/iphone/iphone-manual
I just want to remove the tag from its permalink. I don't know whether this could be achieve only by changing htaccess or it had to edit using PHP too.
Here is my current htaccess:
RewriteEngine On
RewriteRule ^tag/.* /tag.php [QSA]
RewriteRule ^([^/]+)/$ a-search.php?q=$1
I assume you want to replace the previous "tag rule" inside your .htaccess file? Because it conflicts with what you ask in this question. I'd say all you need to do is this:
RewriteEngine On
RewriteRule ^tag/(.*)$ $1 [QSA,L]
RewriteRule ^([^/]+)/$ a-search.php?q=$1 [L]
If instead you want to add a specific rule, so an exception, then this probably is what you are looking for:
RewriteEngine On
RewriteRule ^tag/iphone/(.*)$ iphone/$1 [QSA,L]
RewriteRule ^tag/.* /tag.php [QSA,L]
RewriteRule ^([^/]+)/$ a-search.php?q=$1 [L]
A general remark: .htaccess style files are notoriously error prone, they make things complex, are hard to debug and really do slow down the server. They they should only be used in two situations:
if you do not have access to the real host configuration (otherwise palce the rules in there!)
if you require dynamic changes to the rule set by some web application (though think twice about the security implications)
In all other cases it makes much more sense to use the real host configuration instead of .htaccess style files.

Changed part of path and need to redirect old to new

I have updated country code in the base path and I am attempting the redirect users that end up going to:
www.example.com/uk/etc1/etc2/etc..
www.example.com/gb/etc1/etc2/etc..
But also sometimes also www.example.com/uk#etc
I thought this would be fairly trivial in mod_rewrite I cant get anything to work.
The closest I feel I have come is the following rule, but nothing happens when I land on uk.
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine on
RewriteRule .* index.php [L] #this is active already on the page
RewriteRule ^/uk(.*) /gb(.*) [R]
</IfModule>
Edit:
This seems closer but I am getting stuck in an endless loop:
RewriteRule ^uk(.*) /gb$1 [R]
Edit 2 / (3) Answer:
This seems to redirect correctly(is correct):
RewriteRule ^uk(.*)$ /gb$1 [R=302,L]
RewriteRule .* index.php [L]
But the formatting is broken on the page, looks like some loop problem.
But the formatting is incorrect, If I swap the two RewriteRules the formatting is correct but the uk => gb conversion doesn't seem to get called at all.
Answer
Be careful of Rewriteconditions, I failed to notice the significance of them and I removed them for the original index.php rewrite which meant it could not locate any media.
I failed to take notice of the rewrite conditions which applied for the original index.php
This should do the trick:
Options +FollowSymLinks
DirectoryIndex index.php
RewriteEngine on
RewriteRule ^/uk(.*) /gb$1 [R=301,L]

mod_rewrite doesn't actually... re-write the URL

Basically, I've been trying to make some friendly URL's via .htaccess using mod_rewrite - and I've managed to get it to work... but only with basic stuff like:
RewriteEngine On
RewriteBase /
RewriteRule ^profile.php http://www.google.co.uk [L]
So mod_rewrite works, and I can re-direct to other sites, other files/directories in my server, etc. - but it seems to not work when I use this:
RewriteEngine On
RewriteBase /
RewriteRule ^profile.php?user=$1 ^profile/user/([^/]*)/$ [L]
Any help on this would be great, as I pretty much suck at mod_rewrite, but it's something I need to learn.
Cheers!
Change your [L] to [R,L] to force an actual HTTP redirect. Otherwise it just does the rewriting internally (when possible), which only affects the mapping from the URI to the filesystem. (See the description of the [R] flag at http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteflags.)
Wrong.
## rewriting from to
RewriteRule ^profile.php?user=$1 ^profile/user/([^/]*)/$ [L]
Should be
## rewriting from to
RewriteRule ^profile/user/([^/]+)$ profile.php?user=$1 [L]
Your configuration currently is this:
RewriteEngine On
RewriteBase /
RewriteRule ^profile.php?user=$1 ^profile/user/([^/]*)/$ [L]
In the RewriteRule you swapped the from and to parameters.
Assuming that on your server there is a directory structure like this:
/var/www/htdocs/profile/user/albert
/var/www/htdocs/profile/user/bob
Then you can use the following rule:
RewriteCond ${QUERY_STRING} ^user=(\w+)$
RewriteRule ^profile\.php$ profile/user/%1 [L]
There are some points that you got wrong here:
The request to "/profile.php?user=bob" first gets split into the Request URI and the Query String. Only the Request URI will be used by mod_rewrite. Therefore you have to handle the query string separately.
I restricted the user name to only [A-Za-z0-9_]. If I had allowed all characters, an attacker could easily call /profile.php?user=../../config.php, which would be rewritten to profile/user/../../config.php, and you probably don't want to share that file with the world.
The arguments to the RewriteRule directive are completely different regarding their syntax.
The first argument (the from part) is a regular expression, which usually starts with a caret ^ and ends with a dollar $.
The second argument (the to part) is the replacement, which is almost only a simple string, with only some special features. This string usually doesn't start with a caret, but looks rather like a pathname.

How do I get the [L] flag of RewriteRule (.htaccess) really working?

To newcomers: While trying to comprehensively describe my problem and phrase my questions I produced huge ammount of text. If you don't want to read the whole thing, my observations about (read "proof of") [L] flag not working the misconception, from which it all sprung, is located in Additional observations section. Why I misunderstood apparent behaviour is described in my Answer as well as solution to given problem.
Setup
I have following code in my .htaccess file:
# disallow directory indexing
Options -Indexes
# turn mod_rewrite on
Options +FollowSymlinks
RewriteEngine on
# allow access to robots file
RewriteRule ^robots.txt$ robots.txt [NC,L]
# mangle core request handler address
RewriteRule ^core/(\?.+)?$ core/handleCoreRequest.php$1 [NC,L]
# mangle web file adresses (move them to application root folder)
# application root folder serves as application GUI address
RewriteRule ^$ web/index.html [L]
# allow access to images
RewriteRule ^(images/.+\.(ico|png|bmp|jpg|gif))$ web/$1 [NC,L]
# allow access to stylesheets
RewriteRule ^(css/.+\.css)$ web/$1 [NC,L]
# allow access to javascript
RewriteRule ^(js/.+\.js)$ web/$1 [NC,L]
# allow access to library scripts, styles and images
RewriteRule ^(lib/js/.+\.js)$ web/$1 [NC,L]
RewriteRule ^(lib/css/.+\.css)$ web/$1 [NC,L]
RewriteRule ^(lib/(.+/)?images/.+\.(ico|png|bmp|jpg|gif))$ web/$1 [NC,L]
# redirect all other requests to application address
# RewriteRule ^(.*)$ /foo/ [R]
My web application (and its .htaccess file) is located in foo subfolder of DOCUMENT_ROOT (accessed from browser as http://localhost/foo/). It has PHP core part located in foo/core and JavaScript GUI part located in foo/web. As can be seen from the code above, I want to allow access only to single core script that handles all requests from GUI and to 'safe' web files and redirect all other requests to base application address (last commented directive).
Problem
Behaviour
It works until I try the last part by uncommenting the last redirecting directive. If I comment some more lines, the appropriate page parts stop working, etc.
However, when I uncomment last line, which should be performed only when matching of all previous rules fails (at least that's what I understand), page goes into redirection cycle (Firefox throws error page with something like "This page isn't redirecting properly"), because it's redirecting to http://localhost/foo/ again and again and again, forever.
Questions
What I don't understand is this processing of this rule:
RewriteRule ^$ web/index.html [L],
specifically the [L] flag. The flag apparently doesn't work for me. When the last line is commented, it correctly redirects, but when I uncomment it, it is always processed, even though rewriting should stop on [L] flag. Anyone got any ideas?
Also, on a sidenote, I'd be thrilled to know why my following attempt at fixing it doesn't work either:
RewriteEngine on
RewriteRule ^core/(\?.+)?$ core/handleCoreRequest.php$1 [NC,L]
RewriteRule ^(.*)$ web/$1 [L]
RewriteRule ^.*$ /foo/ [L]
This actually doesn't work at all. Even if I remove the last line, it still doesn't redirect anything correctly. How does the redirecting work in the first example, if it doesn't work in the second?
It would also be of great benefit to me, if anybody knew any way to actually debug these directives. I spend hours on this without even the slightest clue what could possibly be wrong.
Additional observations
After trying the advice given by bbadour (not that I haven't tried it before, but now that I had a second opinion, I gave it another shot) and it didn't work, I've come up with the following observation. By rewriting last line to this:
RewriteRule ^(.*)$ /foo/?uri=$1 [R,L]
or this
RewriteRule ^(.*)$ /foo/?uri=%{REQUEST_URI} [R,L]
and using Firebug's Net panel, I found out more evidence, that the [L] flag is clearly not working as expected in the previously mentioned RewriteRule ^$ web/index.html [L] rule (let's call it THE RULE from now on). In first case I get [...]uri=web/index.html, in second case [...]uri=/foo/web/index.html. That means that THE RULE gets executed (rewrites ^$ to web/index.html), but the rewriting doesn't stop there. Any more ideas, please?
After hours of searching and testing, I finally found the real problem and solution. Hopefully this will help somebody else too, when they come across the same problem.
Cause of observed behavior
.htaccess file is processed after every redirect (even without [R] flag),
which means that after the RewriteRule ^$ web/index.html [L] is processed, mod_rewrite correctly stops rewriting, goes to the end of the file, redirects correctly to /foo/web/index.html, and then the server starts processing .htaccess file for the new location, which is the same file. Now only the last rewrite rule matches and redirects back to /foo/ (this time with [R], so the redirect can be observed in browser) ... and the .htaccess file is processed again, and again, and again...
Once more for clarity: Because only the hard redirects can be observed, it seems like the [L] flag is ignored, but it is not so. Instead, the .htaccess is processed two times redirecting back and forth between /foo/ and /foo/web/index.html.
Solution
Disallow direct access to subfolder
To virtually move subdirectory to application root directory, additional complex conditional rewrites must be used. Variable THE_REQUEST is useful for distinguishing between hard and soft redirects:
RewriteCond %{THE_REQUEST} ^GET\ /foo/web/
RewriteRule ^web/(.*) /foo/$1 [L,R]
For this rewrite rule to be matched, two conditions must apply. First, on second line, the "local URI" must start with web/ (which corresponds with absolute web URI /foo/web/). Second, on first line, the real request URI must start with /foo/web/ too. Together this means, that the rule only matches when the file inside the web/ subfolder is requested directly from the browser, in which case we want to do a hard redirect.
Redirect to allowed content from root to subfolder (soft)
RewriteCond $1 !^web/
RewriteCond $1 ^(.+\.(html|css|js|ico|png|bmp|jpg|gif))?$
RewriteRule ^(.*)$ web/$1 [L,NC]
We want to redirect to allowed content only if we haven't done it already, hence the first condition. Second condition specifies mask for allowed content. Anything matching this mask will be softly redirected, possibly returning 404 error if the content doesn't exist.
Hide all content not in subfolder or not allowed
RewriteRule !^web/ /foo/ [L,R]
This will do a hard redirect to application root for all URIs not beginning with web/ (and remember, only requests that can begin with web/ at this point are internal redirects for allowed content.
Real example
My code shown in my "question" after using solution tips mentioned above gradually transformed into the following:
# disallow directory indexing
Options -Indexes
# turn mod_rewrite on
Options +FollowSymlinks
RewriteEngine on
# allow access to robots file
RewriteRule ^robots.txt$ - [NC,L]
# mangle core request handler address
# disallow direct access to core request handler
RewriteCond %{THE_REQUEST} !^(GET|POST)\ /asm/core/handleCoreRequest.php
RewriteRule ^core/handleCoreRequest.php$ - [L]
# allow access to request handler under alias
RewriteRule ^core/$ core/handleCoreRequest.php [NC,QSA,L]
# mangle GUI files adressing (move to application root folder)
# disallow direct access to GUI subfolder
RewriteCond %{THE_REQUEST} ^GET\ /foo/web/
RewriteRule ^web/(.*) /foo/$1 [L,R]
# allow access only to correct filetypes in appropriate locations
RewriteCond $1 ^$ [OR]
RewriteCond $1 ^(images/.+\.(ico|png|bmp|jpg|gif))$ [OR]
RewriteCond $1 ^(css/.+\.css)$ [OR]
RewriteCond $1 ^(js/.+\.js)$ [OR]
RewriteCond $1 ^(lib/js/.+\.js)$ [OR]
RewriteCond $1 ^(lib/css/.+\.css)$ [OR]
RewriteCond $1 ^(lib/(.+/)?images/.+\.(ico|png|bmp|jpg|gif))$
RewriteRule ^(.*)$ web/$1 [L,NC]
# hide all files not in GUI subfolder that are not whitelisted above
RewriteRule !^web/ /foo/ [L,R]
What I don't like about this approach is that the application root folder must be hardcoded in .htaccess file (as far as I know), so the file must be generated on application install, not simply copied.
To debug, try simplifying your regex, and the url you ask for (a part of the full url you wanna match), and see if it's working, now step by step, add more bits to the regex adn the testing url, till you find where things are stopping to work properly.
Try using:
RewriteRule ^(.*)$ /foo/ [R,L]
If it still loops, put a RewriteCond in front of it to skip the rule if it is already /foo/

.htaccess mod_rewrite problem - shot myself in the foot?

I have a page called category.php5 that uses $_GET["category"] to fetch the right content from the database. I want to pretty it up so is looks like:
sinaesthesia.co.uk/category/psoriasis
which would equal:
sinaesthesia.co.uk/category.php5?category=psoriasis
I have successfully done this sort of rewriting before, but since I can't get it to work now, I'm worred that I might have rules in place that are somehow screwing me. Here is my entire .htaccess file - the last couple of lines are supposed to do the above rewrite:
RewriteEngine On
#remember to change this to aromaclear
RewriteCond %{HTTP_HOST} !^sinaesthesia\.co.uk$ [NC]
RewriteRule ^(.*)$ http://sinaesthesia.co.uk/$1 [R=301,L]
#Translate default page to root
RewriteCond %{THE_REQUEST} ^GET\ .*/index\.(php5|html)\ HTTP
RewriteRule ^(.*)index\.(php5|html)$ /$1 [R=301,L]
#translate any .html ending into .php5
RewriteRule ^(.*)\.html$ /$1\.php5
#change / for ?
RewriteRule ^(.*)\.html/(.*)$ /$1\.html?$2
#strip .html from search res page
RewriteRule ^(.*)search/(.*)$ /$1search_results\.html/search=$2
#translate product details link from search res page
RewriteRule ^products/(.*)/(.*)/(.*)$ /product_details.php5?category=$1&title=$2&id=$3 [L]
#Translate products/psorisis/chamomile-skin-cream-P[x] to productview.php5?id=1
RewriteRule ^products/.*-P([0-9]+) /productview.php5?id=$1 [L]
#Translate /category/psoriasis to /category.php5?category=$1
RewriteRule ^category/(.*) /category.php5?category=$1 [L]
When I manually enter category.php5/category=psoriasis, it works great. When I enter category.php5/category/psoriasis, it doesn't. I'm worried that my line that changes a html/ to html? is an error, however when I take that line out, it still doesn't work. Everything else works as expected.
As a general strategy, strip down your file by commenting everything out, then re-enable things piece by piece until you find the rule that causes it to break.
Bear in mind that browsers sometimes cache redirects, so starting a fresh browser instance is a good idea. A useful service is http://web-sniffer.net/ which will give you an uncached result.
In general, looking at your set of redirects, this seems a little convoluted to me because of the chaining/sieve -type system you seem to be using. Instead, I would recommend starting with URLs that can be identified specifically, e.g. starting with
RewriteRule ^category/(.*) /category.php5?category=$1 [L]
and then leaving the rather messy .html => .php conversion stuff towards the end, if you end up needing it at all. I've done a lot of sites using redirects and have never needed generic conversions like that, so they should be avoidable.
Also bear in mind that .* means matching anything or nothing, so you probably want to use .+ instead.
Ah: because I have a document called category.php5 and I'm trying to use category/psoriasis, the server tries to resolve that as category.php5/psoriasis, which fails. Fixed it now!

Resources