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.