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.


01:00 AM

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


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-07
Prism is vulnerable to Cross-Site Scripting. The easing preview of the Previewers plugin has an XSS vulnerability that allows attackers to execute arbitrary code in Safari and Internet Explorer. This impacts all Safari and Internet Explorer users of Prism >=v1.1.0 that use the _Previewers_ plugin...
PUBLISHED: 2020-08-07
Apache HTTP Server versions 2.4.20 to 2.4.43. A specially crafted value for the 'Cache-Digest' header in a HTTP/2 request would result in a crash when the server actually tries to HTTP/2 PUSH a resource afterwards. Configuring the HTTP/2 feature via "H2Push off" will mitigate this vulnerab...
PUBLISHED: 2020-08-07
DKIM key management page vulnerability on Micro Focus Secure Messaging Gateway (SMG). Affecting all SMG Appliance running releases prior to July 2020. The vulnerability could allow a logged in user with rights to generate DKIM key information to inject system commands into the call to the DKIM syste...
PUBLISHED: 2020-08-07
Apache HTTP server 2.4.32 to 2.4.44 mod_proxy_uwsgi info disclosure and possible RCE
PUBLISHED: 2020-08-07
IP address spoofing when proxying using mod_remoteip and mod_rewrite For configurations using proxying with mod_remoteip and certain mod_rewrite rules, an attacker could spoof their IP address for logging and PHP scripts. Note this issue was fixed in Apache HTTP Server 2.4.24 but was retrospectively...