Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/24/2007
01:00 AM
50%
50%

Re-Thinking PCI

The Payment Card Industry standard wasn't just designed for banks - it's also intended to protect consumers

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Lessons from the NSA: Know Your Assets
Robert Lemos, Contributing Writer,  12/12/2019
4 Tips to Run Fast in the Face of Digital Transformation
Shane Buckley, President & Chief Operating Officer, Gigamon,  12/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19807
PUBLISHED: 2019-12-15
In the Linux kernel before 5.3.11, sound/core/timer.c has a use-after-free caused by erroneous code refactoring, aka CID-e7af6307a8a5. This is related to snd_timer_open and snd_timer_close_locked. The timeri variable was originally intended to be for a newly created timer instance, but was used for ...
CVE-2014-8650
PUBLISHED: 2019-12-15
python-requests-Kerberos through 0.5 does not handle mutual authentication
CVE-2014-3536
PUBLISHED: 2019-12-15
CFME (CloudForms Management Engine) 5: RHN account information is logged to top_output.log during registration
CVE-2014-3643
PUBLISHED: 2019-12-15
jersey: XXE via parameter entities not disabled by the jersey SAX parser
CVE-2014-3652
PUBLISHED: 2019-12-15
JBoss KeyCloak: Open redirect vulnerability via failure to validate the redirect URL.