Jump to content

Archived

This topic is now archived and is closed to further replies.

rule

PCI Compliance

Recommended Posts

Stock orders database table contains 4 cc_ fields intended for data that may not actually be stored as per PCI DSS. Is it safe to remove those so that our card payment module couldn't write there?

Recent PCI scan flagged osCsid as a cookie missing the "secure" flag. Our PCI vendor states that an exception request may only be granted if we attest that the cookie is not a session cookie. Since we know that it is, what could be done about this?

Share this post


Link to post
Share on other sites

That's an interesting point on the secure flaf for the cookie.  Oddly enough, the cookie test is secure and HttpOnly is true also.  I'm playing around with some ideas on my test site, but so far, I haven't been able to get it to set secure.  Hopefully, someone else can chime in on this. 

One point is your site has to be fully secure to set secure = true.  Mine is and it still doesn't set.


I'm not really a dog.

Share this post


Link to post
Share on other sites

In reading on Stack Overflow, it seems that the cookie can't be set secure unless it expires in the future.  I tried some different settings but the cookie for the session would not set secure or httponly.  Since it expires when the browser closes, maybe it doesn't matter???????? 


I'm not really a dog.

Share this post


Link to post
Share on other sites

@John W How do you (and any other U.S. merchants) deal with card data storage? Have you removed those 4 entries from the orders table and maybe something else as well?

Share this post


Link to post
Share on other sites

If the fields are there, but you are using them, it shouldn't be a problem.   But, you can remove them as long as no files are using them.  There was a very old module that used those.


I'm not really a dog.

Share this post


Link to post
Share on other sites
On 8/15/2018 at 5:30 PM, rulegacy said:

Stock orders database table contains 4 cc_ fields intended for data that may not actually be stored as per PCI DSS. Is it safe to remove those so that our card payment module couldn't write there?

Your payment module cannot write to these fields unless it is specifically coded to do so.


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest Responsive osCommerce CE (community edition) here

Share this post


Link to post
Share on other sites

We use this. Perhaps it does write to the database (those 4 fields are still present in Frozen, by the way). We did consider switching to Sage Pay but all apps seem to be dated. Is anyone here using these?

As for the cookie, is it possible to set the secure tag permanently? This issue affects everyone accepting cards in the U.S. and should be given as much attention as GDPR for those serving EU customers.

Share this post


Link to post
Share on other sites

If a database field is not referred to by code that you use, I can't see any reason that you couldn't go into phpMyAdmin and remove that field, if verifiers are simply looking for a field name (doesn't sound very thorough to me).

Share this post


Link to post
Share on other sites

Okay, so it kind of bugged me as to why htttpOnly and secure flag wasn't set.  I tried altering the code to make it work, but it wouldn't.  Did some more research and this is a solution that will make it set secure.  Put this at the top of application_top

  ini_set('session.cookie_httponly',1);
  ini_set('session.cookie_secure',1);

 


I'm not really a dog.

Share this post


Link to post
Share on other sites

@John W This allows to pass the scan. Thank you so much.

Could someone please see what code tells the payment module for USAePay to store certain card data? We would prefer to remove those calls.

Share this post


Link to post
Share on other sites

×