smiler99

germ, on 17 August 2011, 21:04, said:

Germ, thanks for trying, further information if this helps

when i try i retain OSCSID as a value in the url (this only happens when moving through secure pages) - not sure i this is the same for you

when my colleague tries they lose the oscsid

to also add i have set recreate session to false, i continue to work ok, but y colleague still loses his cart

my configure.php files are ok and checked against every other post regarding this issue, which seems to fx the issue for most people

i hate being beat!, i will continue to investigate, however as i am sure you are aware it is extremely difficult to fix a problem that i cant replicate..

chris.

hi Germ,

I am having a similar but slightly wierd problem

i can add an item to my cart, goto basket which shows the item,continue to checkout, login and continue to shipping etc. no problems (ie 8)

a colleague adds an item to cart, goes to checkout, logs in but cart then shows empty, if they go back to a non ssl page then the item shows back in cart ? they also use IE but not sure which version

the issue is that i dont know how many users can / cant get to checout and therefore dont know how many sales im losing, we do get visitors with baskets and no sale but that would happen anyway. Do you have any suggestions.

config is set to

define('HTTP_SERVER', 'http://www.fireplace2u.co.uk');
define('HTTPS_SERVER', 'https://www.fireplace2u.co.uk');
define('ENABLE_SSL', 'true');
define('HTTP_COOKIE_DOMAIN', '.fireplace2u.co.uk');
define('HTTPS_COOKIE_DOMAIN', '.fireplace2u.co.uk');
define('HTTP_COOKIE_PATH', '/');
define('HTTPS_COOKIE_PATH', '/');


session admin is set to

Session Directory /tmp/
Force Cookie Use False
Check SSL Session ID True
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
Session Lifetime 60

many thanks

Steve,

I am getting lots of vosits from users who have SIMBAR in their user agent, from what i have read it appears that these users have some sort of malware/adware on their system. Should i be concerned in any way, should i block any user with SIMBAR in their user agent.

Quote

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.

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!!