PHP virus settings.php

[Taipo]

I tried the below but it won;t let me access. Is there any issue with the 2 directives in the same htaccess. Should I only be using this for the admin folder?

 

That would make sense, that you cannot have two deny from all in one htaccess file. The limitexcept would do better in the main shop directory htaccess, and your order deny code you originally had is fine in the admin directory htaccess.

 

I would suggest you add HEAD to the list as well.

 

<LimitExcept GET POST HEAD> 
       Deny from all 
</LimitExcept>

 

Some legit search engines still use HEAD, so best not ban them.

 

Is this a normal oscommerce file?

File could be a potentional threat: /home6c/sub002/sc11883-LGVN/mysite.co.uk/cart/cookie_usage.php (Known filename threat)

 

Cookie_usage is a normal file, in fact there are two of them. But since they have been targetted by attackers by them appending code into these two files, I assume that the makers of SiteMon have listed that file as a threat.

 

Of course, it doesnt really mean a thing really, what matters is, have you compared the contents of cookie_usage.php to the original to see if any code has been added to it, rather than using SiteMon as your 'test' method.

[qwertyjjj]

That would make sense, that you cannot have two deny from all in one htaccess file. The limitexcept would do better in the main shop directory htaccess, and your order deny code you originally had is fine in the admin directory htaccess.

 

I would suggest you add HEAD to the list as well.

 

<LimitExcept GET POST HEAD> 
       Deny from all 
</LimitExcept>

 

Some legit search engines still use HEAD, so best not ban them.

 

 

 

Cookie_usage is a normal file, in fact there are two of them. But since they have been targetted by attackers by them appending code into these two files, I assume that the makers of SiteMon have listed that file as a threat.

 

Of course, it doesnt really mean a thing really, what matters is, have you compared the contents of cookie_usage.php to the original to see if any code has been added to it, rather than using SiteMon as your 'test' method.

 

Just trying to find a decent file comparison program and go through everything listed first...

 

OOI, if hackers are using an exploit to POST through the admin login page, then how does using <Limit GET POST PUT> still allows them to POST anyway doesn't it?

Is that how the exploit works, something redirects them to the admin login page in the background so even if htaccess was blocking their IP, they get through that way?

[qwertyjjj]

Err...where can I get the default oscommerce files from? The downloads page only has 2.3.1 and higher...

[Taipo]

OOI, if hackers are using an exploit to POST through the admin login page, then how does using <Limit GET POST PUT> still allows them to POST anyway doesn't it?

 

Well that is more associated with denying access. Its best not to use those I think if you can get away with just having the order deny code without the LIMIT directive.

 

Is that how the exploit works, something redirects them to the admin login page in the background so even if htaccess was blocking their IP, they get through that way?

 

We are talking about two different security holes. The admin bypass is merely appending login.php to every admin filename in order to get admin level access. This is patched in 2.3.1 and in osc_sec.php (and Ultimate URLs SEO 5). How is osc_sec working out anyways?

 

Bypassing the LIMIT directive is just as trivial but a different exploit. The way to protect yourself from that exploit is to use the LimitExcept directive higher up in the directory hierachy or just do not use the LIMIT directive at all.

[qwertyjjj]

Well that is more associated with denying access. Its best not to use those I think if you can get away with just having the order deny code without the LIMIT directive.

 

 

 

We are talking about two different security holes. The admin bypass is merely appending login.php to every admin filename in order to get admin level access. This is patched in 2.3.1 and in osc_sec.php (and Ultimate URLs SEO 5). How is osc_sec working out anyways?

 

Bypassing the LIMIT directive is just as trivial but a different exploit. The way to protect yourself from that exploit is to use the LimitExcept directive higher up in the directory hierachy or just do not use the LIMIT directive at all.

 

Seems ok so far. I can recommend a very good file comparison software on Linux called Meld diff viewer.

I still cannot get the original 2.2 RC1 files - any ideas where they might be? Oscommerce don't list them anymore.

 

Re: LIMIT if the way hackers upload files is through POST then shouln't I only be using LIMIT GET in the htaccess?

[germ]

Some older versions here

[Taipo]

Re: LIMIT if the way hackers upload files is through POST then shouln't I only be using LIMIT GET in the htaccess?

 

There are a number of legitimate POST request functions in Oscommerce, including logging in. The issue with attackers uploading files via the file manager I suspect, was misdiagnosed as a problem with file manager when the issue was that the entire admin permissions could be bypassed by appending login.php to the end of a file. This issue was fixed in 2.3.1 and also has been addressed in Osc_Sec.php and Ultimate SEO URLS 5.

 

So the htaccess issues we are dealing with here are not associated with that particular security hole. What you are wanting to do is limit which IPs can have free access to your admin directory.

 

So if you use the <LIMIT GET POST> to deny every IP except yours, you then run into problems when an attacker sends a request to your server that apache misinterprets as a GET request. Its a known security bug in apache that the wonderful developers have not addressed yet. The way around this is to use this directive in your main shop directory htaccess right at the top:

 

<LimitExcept GET POST HEAD> 
       Deny from all 
</LimitExcept> 

 

Which tells the server to accept only GET, POST and HEAD requests, and deny all others.

 

Then in the admin directory htaccess use:

 

<Limit GET POST> 
order allow,deny 
deny from all 
allow from [your_external_ip_address] 
</Limit>

 

Which will limit any GET and POST request to have to be from those specific IP addresses.

 

That is the most common method, however, the most secure method to deny IP accesss while only allowing for individual IP addresses is to just use:

 

order allow,deny 
deny from all 
allow from [your_external_ip_address]

 

Which basically states that no matter what the request type is, deny it unless it is from this specific IP address.

 

That is the best way to use that method of restricting access. The best method overall though is to use the htaccess htpasswd authorization which you should find in the control panel supplied by your webhost (often called folder protection or similar). In that instance all access is barred to the directory in question unless the correct user and password is provided.

See: http://www.javascriptkit.com/howto/htaccess3.shtml for more.

[qwertyjjj]

I have found this in the index and am not sure where it comes from, is this a default oscommerce thing:

<meta name="verify-v1" content="TohvsgzhkdU5HZ14DRCMu/ns2UoEcp8x7LPTI/iYZ9A=" />

[Taipo]

Isn't that associated with Google Webmaster Tools?