PCI-DSS is requiring more web application security focus probably because most of the CC# heists we're reading about either have to do with a lost/stolen PCs or web application hacks. Whatever the reason, Approved Scanning Vendors (ASV's) and website merchants require guidance as to what vulnerabilities need to be tested for and protected against. So far this guidance has referenced the OWASP Top 10, which in the new 2007 draft, includes Cross-Site Request Forgery (CSRF). Though if someone isn’t thoughtful, this could mean that no website will be able to pass PCI-DSS scans if both documents (PCI and T10) are taken at face value.
Most experts will agree that CSRF is a serious issue and that on a global scale we’re talking about a HUGE number of vulnerabilities. Just about every "important" feature of every website, relatively speaking, is likely to be vulnerable to CSRF. The other problem is automated scanning for CSRF is hard, really hard. I'm not ready to say impossible, because is some occasions it isn’t, but the needle is still very near zero for everybody. (Anyone care to correct me?) To top it off, CSRF solutions aren’t exactly simple to implement, as opposed to XSS or SQL Injection. It’ll require more than a one-line input validation or output filtering regex to defeat. A fairly sophisticated piece of logic (session token / form keys/ nonce) needs to be placed the middle of each "important" business process.
As an ASP and VA vendor, we’re generally paid to identify "a plate of red" (vulnerabilities) in our customer’s websites, with the primary value being to help them get secure by recommending solutions. In the case of CSRF, if compelled by PCI-DSS to add it to our testing methodology, its may be we'd identify literally thousands of these vulnerabilities for each few hundred sites. Merchants seeking PCI compliance are not going to enjoy the results when they figure out how long its going to take them combined with everything else they have to do. Of course, the PCI Council could simply say not to follow the OWASP Top 10, because hey, even the document itself says not to use it as a standard.
"This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first!"
I guess its still an open option, but Andrew van der Stock (a main architect of the document) says the following:
"It’s unlikely that the PCI folks will pick up this Top 10 as is; they’re looking for “Top 10 things you should code well on when dealing with financial apps, particularly cc apps”."
Fair enough, so perhaps they'll cite the all encompassing WASC Threat Classification. Maybe, but this document will also be updated soon to include CSRF. So no getting away from it unless the PCI Council simply says to ignore CSRF entirely. Could happen I guess. Anyway, I thought I’d lay this out there and see what insight others had. I have no idea what’ll happen with PCI-DSS down the road. We’ll have to wait and see.
5 comments:
What if the vendors borrow from the "trusted computing base" concept and outsource the shopping cart and credit card handling. Move it all into a bullet-proof web site with a single-purpose web application. Seems like a great business opportunity for IBM or some other security and web savvy development house. Then you host it inside multiple SAS70 compliant data centers. Creating the Fort Knox of credit card processing and the ideal target of every hacker on the planet. But still better for the 10 million mom and pop web sites who can't possibly code a secure solution.
SAS70 is just about the most useless thing I've ever seen. It lets accountants (and in fact, ONLY accountants) to be webappsec subject matter experts, despite the obvious issue that they're not. An accountant doing what we do successfully is about as likely as me doing Bank of America's tax return successfully without giving all their money away.
The CSRF requirement is the only one where we "fudged". All the other nine issues are easily discoverable by automated means. I will be changing the CSRF action item in RC2 to be very specific: the control ONLY applies to value transactions, which for PCI compliance (although that is somewhat moot now) means you may only need to look manually at a couple of places in an average e-commerce application. That will reduce the cost of review to manageable proportions.
I'd love to open up the "what to do right" document creation process to WASC and websecurity@WASC folks.
Let's talk.
Andrew
hah, SAS70. good point andrew. it furthermore allows the audited entity to specify what the auditor is allowed to look at, which is just plain silly when compared with the PCI checklist approach that is meant to be comprehensive and non-negotiable in scope.
outsourcing also potentially makes it harder for a vendor as they might have to get their service provider certified rather than just dealing with internal compliance issues.
fwiw i just burned a day discussing the latest assessor guidelines with the "PCI Co" folks (as they like to call themselves now, perhaps because someone there prefers Pepsi?). anyway, CSRF was hardly the focus so it seems like there is still time to refine and clarify.
The current, Version 1.1 PCI technical requirements for achieving ASV accreditation (https://www.pcisecuritystandards.org/pdfs/pci_dss_technical_and_operational_requirements_for_approved_scanning_vendors_ASVs_v1-1.pdf)
don't actually reference OWASP.
This may change in the future, of course.
The PCI Audit process (for large transaction volume sites) do rquire OWASP considerations in the development process, however.
Lyal
@hey davi!
"anyway, CSRF was hardly the focus so it seems like there is still time to refine and clarify."
I guess so. It would be nice if they just told us ASV's what specifically we are supposed to be able to find.
@lyalc: Excellent point and exactly right. That's why many ASV's just reverted to that guidance for scanning as it seemed to make the most sense. I've actually complained about this a while back:
"ASV's are informed of just about everything, EXCEPT WHAT VULNERABILITIES WE NEED TO BE ABLE TO FIND! "
http://jeremiahgrossman.blogspot.com/2006/09/new-pci-data-security-standard.html
Post a Comment