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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
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
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
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
CVE-2020-17452
PUBLISHED: 2020-08-09
flatCore before 1.5.7 allows upload and execution of a .php file by an admin.
CVE-2020-17451
PUBLISHED: 2020-08-09
flatCore before 1.5.7 allows XSS by an admin via the acp/acp.php?tn=pages&sub=edit&editpage=1 page_linkname, page_title, page_content, or page_extracontent parameter, or the acp/acp.php?tn=system&sub=sys_pref prefs_pagename, prefs_pagetitle, or prefs_pagesubtitle parameter.
CVE-2020-17447
PUBLISHED: 2020-08-09
MyBB before 1.8.24 allows XSS because the visual editor mishandles [align], [size], [quote], and [font] in MyCode.
CVE-2020-16248
PUBLISHED: 2020-08-09
** DISPUTED ** Prometheus Blackbox Exporter through 0.17.0 allows /probe?target= SSRF. NOTE: follow-on discussion suggests that this might plausibly be interpreted as both intended functionality and also a vulnerability.
CVE-2020-15820
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.