Re-Thinking PCI

9:00 AM -- Should cross-site scripting (XSS) holes cause companies to fail PCI audits?

Over the last few months I have been engaged in a lot of interesting conversations around the relative bad things you can do with XSS holes. After a year and a half of beating people over the head with it, and proving you can do port scanning, history theft, phishing, hacking routers, and more, I think we've at least proven that XSS should be considered a real threat. But how bad is it really? Is it really worth failing a Payment Card Industry (PCI) audit over?

To answer that question I have to talk a little bit about the three kinds of XSS: DOM-based, reflected, and persistent. Some argue that DOM and reflected are really the same in many ways, and for the purposes of this discussion let's just consider them the same. Reflected XSS is bad, but it's not that bad. For it to be useful to an attacker, he must somehow get someone to click on a link somewhere. That link will take the user to the XSS hole to perform the attack. Ultimately though, the attacker must somehow social engineer the user into clicking the link, or must be in control of another page the user visits on another site that can automatically redirect that user to the XSS hole. This often happens with phishing emails or other social engineering tricks.

Persistent XSS, on the other hand, has no such limitations. Persistent XSS is often untargeted and needs only to lie in wait for a victim to click on it. Such exploits can lie dormant for hours, days, months, or years, without causing any suspicion. It would appear that persistent XSS is far worse, and should raise more alarm bells. It's nasty. But how nasty?

The PCI standard was a way for the payment industry to know that card member data is secure. From the PCI data security standard: "[The PCI] requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted." Anyone who takes a credit card, or uses it in any way is supposed to be a trusted party. The industry puts its faith in the merchant to hold that information in good faith and with security in mind. More importantly, the consumer also must be able to trust that the merchant is free from vulnerabilities and that their information is safe when entered.

When a Website suffers from XSS holes, it breaches consumers' trust in the site. They can no longer trust that what they are seeing is valid. So is there a difference between persistent and reflected XSS? There definitely is from a technology perspective, but from a consumer perspective, it makes no difference at all. All they know is that they are on a site that looks and acts like the official site. If in any way the user can be duped by the hole into disclosing information, jeopardizing their credentials for use in other forms of fraud, or otherwise cause them financial harm, then there's a big problem.

Taken in that vein, the PCI standard would imply that all XSS holes should be considered a grave threat to the card holder's security. Recently some PCI scanning vendors agreed with that idea and raised the severity threat level of XSS holes. But let's not lose site of what this is all about: protecting the consumer.

Companies that handle financial transactions have a responsibility to their consumers to protect them. It's not always about the corporation's security. The PCI data security standard is a way for the payment industry to hold companies accountable for their security, and from this consumer's perspective, I'm glad it's finally here.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading