Joomla! Discussion Forums

This condition gives a 500 server internal error here:


Result:


Log:
[Sun Jul  9 00:13:18 2006] [alert] [client xxx] /home/xxxpublic_html/xxx/.htaccess: RewriteRule: invalid HTTP response code for flag 'R'

Trying changing it to [F,L] should produce the same effect.  Which version of Apache are you running?

F, L did the trick.

In the 2 cases, host and locally, Apache is 1.3.33

Suggestion:

if there is no drawback, it would be good to include this in the htaccess default installed file.

I have considered that but as I said before it is largely untested so far.  Additionally, it might impede on some functionality that I have not considered yet so it would need to be thoroughly tested before I made any kind of push to get this installed in the default .htaccess.  On the other hand, I think it would be a good idea if a set of rules like this were maintained to keep up with the most popular security vulnerabilities and possibly stop them before they become bigger threats.  I have basically been trying to do that myself which has been fairly easy so far because most of the logged attacks I have seen are pretty similar in form and the code they try.  I am just worried that these rewrite conditions might create some strange behavior like the people who were having issues with mod_security and 'psy' and 'properly'.  I have tried my best to keep it sane but only testing will prove if it works or not.

I will post the trick at the Greek Forum just now

Thank you

Alright, just make sure you post a big warning that it hasn't been tested very thoroughly!

I just posted the link to your post here, because i have some hacked sites reported by the forum mebers
http://forum.joomla.org/index.php/topic ... #msg388584
thank you

Alright, that is probably a good idea in case there are any more changes that need to be made to the script, I can just post them to this thread.  So, stay tuned J! users 

Patch applied succesfully with the modification [R=403,L] to [F,L]

Hello

We are hosted at http://www.godaddy.com. I just applied the .htaccess patch and did the [F,L]

It produces the 500 Internal server error.

Any ideas?

Here is the change (making sure I actually did it correctly)

# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [R=403,F,L]


We are running 1.0.10

Thanks

@vscribe

errot in your text
It is:

That was it! Thank you!

I'll start testing, but looks ok now.

Thank you again - vscribe

I have also applied this to my .htaccess file. Got the same internal server error that everybody is mentioning but then Changed

RewriteRule ^(.*)$ index.php [R=403,L] to

RewriteRule ^(.*)$ index.php [F,L]

Now everything is working fine at my site on http://www.khagolmandal.com

My site was also hacked on 30th June and I had to reload the whole thing. Earlier I was using 1.0.8 now I have installed 1.0.10, but as there were reports on this forum, about 1.0.10 haches also, I am using this .htaccess file.

Let see the result as I have reloaded the site since 8th July 2006.

I am curious, all the people that had to make the changes to the scripts last line the [F,L] part... Are you all on Apache 1.3.x?  I wrote the script on a server running 2.2.x so it might be a matter of newer syntax.

I am on

Linux Kernel version 2.4.20-43.7.legacy
Apache version 1.3.36 (Unix)
PHP version 4.4.2
MySQL version 4.1.19-standard

Apache/1.3.36
PHP 4.4.2

That is what I figured.  I edited the scripts last rule tags to [F,L] as that is compatible with more versions of Apache.  It works on 2.2.x also.

I just updated htaccess on 3 sites on 2 servers with (apparently) no ill effects. Anything that helps block these exploits must be a good thing and thanks to RobS for that.

Just a thought - my knowledge of what you can and can't do with htaccess is sketchy at best - if these additions do block any attacks we won't know about it. Is there any way for attempts to be logged?

It should log a 403 error for index.php in your log file.

Your .htaccess hack worked fine on my server, and it's got the latest of everything as I just upgraded all the server software plus all Apache attributes in the last month (boy was that fun).

Question for you - I've also seen some comments about changing Register Globals: ON to Register Globals: OFF, but isn't that a part of the php.ini file?  I do know that this does help deter some hacks, but if it's in the root php.ini file then that would affect any php files on the server.  Is there a way of doing this in the .htaccess file?  I'm sure there is but as others have mentioned, the .htaccess file and how it's set up is almost a mystery...

Oh and thanks for this tip!!!

As of Joomla! 1.0.4, you can change your "emulated" setting of register_globals in /globals.php. So if you don't have access to this setting in your sever config, you can at least emulate it for Joomla!

Ahhh did find it there. Have hesitiated to change my php.ini file as I'm not sure of the affect on all the other packages I have running. Afraid if I turn Register Globals off it'll have some affect other than what I want.  I guess I should try it just to see.

I did see this script in my globals.php file, thanks for the hint.

Try putting this code in your .htaccess I have not tested this though.  It might work it might not, it depends on how php is configured I imagine.

php_flag register_globals off

I'm working with IIS 5.1 (Windows XP) ....Can i use the .htaccess file you wrote...if not how can i solve the problem... I got hacked once already...i did all i can to tighten security on the IIS...

Thanx in advance

It should work.  Let me know how it goes if you decide to try it.

Hi Robert,
first off all, many thanks for taking the time to come up with this!

Some small suggestions:

As globals.php already deals with this, I think one could strip this from your .htaccess.


$_REQUEST is an array of user input anyway, so why should we want to make sure a user doesn't mess around with it?

Both remarks are not really important. The thing is, every regexp takes some time to execute, so I think we should try to do as little as possible. It's probably only a matter of microseconds (or even less), but still, that all sums up at some point...

Thanks again for your work on this!

I used it at one of my sites ith no success

the site was hacked last night.

I think thay used the vulnerability at extcalendar but i m not sure about this

http://forum.joomla.org/index.php/topic ... #msg389163

Honestly, I am not up to date on the function of globals.php.  I hadn't really looked at what it does/how it works.  I will have to read up on it.  As for the comment on the $_REQUEST array, I included it I guess as double protection against scripts like this:



And from what I understand you can access $_COOKIE through $_REQUEST which might be worth attempting to protect against to prevent some kind of session hijacking via hand crafted cookie values.

Albi, if you could look through your logs and find the exploit that they used I would be happy to attempt to address it via a rewrite rule.