As a follow up to the last post on sites vulnerable to XSS that are certified McAfee Hacker Safe, there is more to this story.
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?
del.icio.us | digg
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Subscribe to:
Post Comments (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
4 comments:
Upon receiving ScanAlert’s report, I immediately saw that almost all of vulnerabilities reported by ScanAlert were cross site scripting (XSS) vulnerabilities. Now, I’m not particularly knowledgeable about XSS attacks, but I really didn’t need to be to see what ScanAlert was doing and figure out how to strategize around it(!). Basically, ScanAlert was sending various GET and POST requests to the system remotely and scanning the response to see if they had successfully injected what could be malicious code in the response.
The administrator who contacted me assumed I would sift through the code and fix each error individually on a per case basis, which given the large number of vulnerabilities as well as the size and complexity of the osCommerce code base, would probably not get done in the 72 hour window. Even if I focused on updating just the core functions and classes in osCommerce, I am not sure I could have plugged every hole in time. Furthermore, such changes would introduce a tremendous maintenance burden whenever the site was upgraded to a new version of osCommerce, especially as the administrator had no real knowledge of PHP. And, given various constraints, that included the administrator’s reluctance to contribute any code he has paid for to open source projects, it didn’t appear practical to try to update the core osCommerce code and submit changes back to the project.
So, just to be clear, my goal really wasn’t to “fix” this aspect of osCommerce or even to make the site more secure necessarily, it was to achieve “Hacker Safe” approval in a given amount of time and do so in a way that could be maintained by the system administrator.
Fortunately, this fork of osCommerce had theme/templating capabilities, and the site was already using a customized template , which meant that I could inject the code into the main template script, and it would execute before any output was sent to the browser and “sanitize” any user input at that point. Because I would be injecting the code into a customized template that was already being maintained and accounted for in upgrades, I could add this code without adding to the administrator’s responsibilities.
Wow...I'm just not sure where to begin with that comment. Assuming even the slightest legitimacy, I'll say thanks for proving my point: the vast majority of McAfee Secure / Hacker Safe subscribers don't give a damn about security, just conversions. Ever think of global code remediation as opposed to single parameter quick fixes? Oh wait, you're using osCommerce. How's that working for you? Here's a link to the FIFTY (50) vulnerabilities posted for osCommerce in BugTraq. I repeat...wow.
Now... Russ... let's be fair.
[sarcasm]
osCommerce has only had 6 *disclosed* vulnerabilities this year, which means it's doing much better
[/sarcasm]
I think that once I read this person's reply a fourth or fifth time something struck me. I thought - maybe this isn't their fault... then I read it again and I felt a touch better. Work with me here... This person is [hopefully] acknowledging that there are ridiculous amounts of XSS througout osCommerce [as evidenced by your link to the vuln. database]. Given that, I agree it would be semi-silly to try and fix osCommerce flaws when you're simply a customer of theirs. Now, this is where reality takes a bite. Given that this person's administrator (I'm assuming that this means this person is just the developer, or 3rd party developer?) has absolutely *no interest* in making their site more secure [which is honestly what really bugs me here] they're just going to go for HackerSafe approval and get on with life. Not really more secure, just "HackerSafe".
Here's my analysis...
- First off... Shame on osCommerce!
- This scenario, although terrible, is likely the way things go in lots of places out here in the "Wild West" of the Interweb
- This person apparently found the 'signature' that McAfee's HackerSafe program used to scan for XSS and will be filtering that pattern out (blacklisting) - this will fail
- This site's administrator is either a moron, or lazy; neither of which should allow him/her to keep their job
- "HackerSafe"? Maybe. Secure? Unlikely. Better off?... sadly, probably.
And now I'm even more convinced we're [you, me, and others in security] are talking to ourselves most of the time.
Post a Comment