The guidance for this requirement introduces the notion that a CSRF is as powerful as the web application it attacks. I don’t like the language in the guidance. It implies that CSRF is constrained in a way that is difficult to quantify. The text in PCI DSS may have its origin in the A5 entry for CSRF in the WASP 2007 Top Ten. The A5 entry says, “CSRF can be as powerful as the web application that it attacks”. This is not in the OWASP 2010 Top Ten description on CSRF. But I digress.

CSRF is an example of the Confused Deputy problem. The Confused Deputy problem involves a computer program that is innocently fooled by some other party into misusing its authority. In CSRF, the browser is the Confused Deputy.

Since PCI DSS has explicit requirements and guidance for preventing CSRF it seems natural to look at how PCI DSS addresses the Confused Deputy problem in general. Part of the answer lies in Requirement 6.3 and Requirement 6.3.7.

Requirement 6.3 talks in general terms about a Software Development Life Cycle (SDLC) based upon industry best practices and incorporating information security throughout the SDLC. Requirement 6.3.7 provides guidelines for dealing with custom applications and public facing web applications. It requires a review of custom applications prior to release. It suggests (but does not require) having individuals knowledgable in code review techniques and secure coding practices to review these custom applications. In the case of web applications it provides a reference to OWASP.

Aside from the browser the responsibility for preventing other Confused Deputies is delegated to unnamed industry standards, information security, code reviews and secure coding techniques embedded within a SDLC. Is CSRF singled out because there are well understood ways to prevent this attack or because PCI DSS takes a prioritized approach to addressing security vulnerabilities?

In The Prioritized Approach To Pursue PCI DSS Compliance, Requirements 6.3 and 6.3.7 are allocated to Milestone 3. Milestone 1 removes unneeded authentication data and limits data retention. Milestone 2 controls the points of access used for most compromises.

If the data doesn’t exist it isn’t at risk, so placing Milestone 1 before 3 is the right way to go. Placing Milestone 2 before Milestone 3 limits access to the system, thereby increasing the protection provided to the internal and perimeter networks. This leaves the relative priority of a browser and another Confused Deputy up for debate. The requirements for addressing these are in Milestone 3 and the standard doesn’t define relative priority for requirements within a milestone.

The relative priority of protecting against a Confused Deputy comes down to a risk assessment of the likelihood of the Confused Deputy being discovered and exploited. OWASP provides a method for developing a risk assessment. Using this risk assessment method, a browser has a greater likelihood of being exploited than a custom application whose existence may not be known, all other risk factors considered equal. If the application is not custom then a risk assessment is still appropriate.