What makes a Cart PCI Compliant?

[nicu]

There is a lot of hype regarding "PCI Compliant Carts" - but what exactly makes a cart PCI compliant? This topic was brushed upon in another thread, but I feel it's worthy of its own thread.

As far as I am aware (from my own research and the insight of others), for a cart to be "PCI Compliant" it..

1) Would ensure secure connections between server-customer and server-gateway
2) Scrub data to prevent XSS/SQL injection attacks
3) Enforce password integrity/expiration for admins
4) Force the session to time-out after a period of time

Is that all? Those all seem obvious, common-sense issues that any developer would incorporate anyway. Is there any more to being "PCI Compliant" (as far as the cart is concerned)? Or is that phrase just a marketing/selling point that some companies throw around? If so, I would think that any cart worth their salt is already compliant, whether or not they advertise so.

[rocknbil]

When Security Metrics runs a scan, there are a variety of things they test for, and each item found presents a risk factor of 1-5. Exceeding a risk factor of 4 pushes you into non compliance.

You have most of them for a cart; a couple others are login forms that accept/transmit input type="password" in clear text, allowing sensitive data (such as a pass) to be submitted over non-https, and also appropriate headers for some responses. In this aspect, S.M. scans don't appear to be completely perfect, but they are better than just flying by luck.

A standing rule that will fix a large percentage of S.M. scan issues: if input data is echoed back to the page unfiltered after submit, your site is not properly cleansing data. So if you get an alert "123" from this string,

http://www.example.com/yourscript.php?email=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22

You will get an XSS vulnerability score for every page with a form.

One blind mySQL example is I have a client who's search, when nothing is entered, displays all results. This is a similar effect to the mysql injection string "and 1=1" - since 1=1 will always return all rows, the output is exactly the same for the legitimate results and the mysql injection string, so the Security Metrics scan reported "possible blind mySQL injection vulnerability" even though "and 1=1" is stripped from input. The fix was to simply output a 403 forbidden header in this condition and it passed that part of the scan.

Like the W3C validator, some of these risks are cascading; that is, fixing one problem may eliminate many of them. In one case I took a site from an 88 score to a 12 by simply cleansing all data and filtering input.

The remaining 12 - and the ones that are most difficult at times, and have little to do with a cart's "PCI compliance" - are server issues. Accepting FTP in clear text, old vulnerable PHP versions, support of SSL 2.0, and a variety of other items in a server's software and configuration will add to this risk score. Get it under 4 and you pass.

[nicu]

Most developers are aware of/take precautions against XSS/SQL attacks, not just in carts but in web apps in general, so those issues shouldn't arise from a homegrown cart, assuming your developer isn't an amateur. In your client's example, was a vulnerability reported simply because the blank query returned all results? Or was it because the query of "and 1=1" returned all results as well? I assume the latter.. so wouldn't a better fix be to encode the query, so that the actual search would be for "and 1=1" (which would likely return 0 results) without needing to strip it from the input in the first place? Or just use stored procedures?

What do you mean by "appropriate headers for some responses"?

And on a side note, I dislike when sites require you to login through unencrypted pages, even when there is no financial data at risk.. this site being an example. I would think a site like this could afford the $30/year for a certificate. I generally assume that any network/site I'm on is unsecure without SSL, but maybe I'm just more paranoid than most.