X
Tech

PCI Compliance gets clarified and neutered (further)

At one point, I thought that PCI certification was a great thing.  Now I realize that it's not really about security at all...
Written by Nathan McFeters, Contributor

At one point, I thought that PCI certification was a great thing.  Now I realize that it's not really about security at all... it's about money and responsibility and transferring ownership of risk.

The PCI certification just got a clarification:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

  • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
  • Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement. "

I originally saw this clarification on Ivan Ristic's blog, where he comments on the impact of this for Web Application Firewall companies and Web Application Security Scanning tool companies.  I want to make a point that I feel like the committee is completely missing... they state that their goal is to ensure that all web facing applications are "protected against known attacks"; however, this approach DOES NOT ACCOMPLISH THIS!!!!

Web Application Firewalls are designed to catch signature based attacks, which is outstanding as a lot of the attacks are signature like.  WAFs are capable of detecting attacks like SQL Injection and Cross-Site Scripting, which is fortunate as those are two of the most prominent "known attacks"; however, they currently struggle at this.  There's so many different ways of accomplishing these attacks and WAFs suffer when conditions exist like DOM-based cross-site scripting attacks.

Further, and most importantly, WAFs actually provide NO PROTECTION AT ALL against certain types of "known attacks"!  Consider the following:

  1. Authentication and Authorization Issues - There's no way that a WAF can protect a web application from flawed authentication and authorization models, which is definitely something a deep source code review of a web application would uncover.  Think about the Google Docs flaws that Billy recently pulled off.  That's a SERIOUS attack vector, but there's no way a WAF could protect you from this.
  2. Flawed Business Logic - Take this generic example, which I've actually seen in a live application... you've got a web application that allows you to purchase products from the site; however, when you go to make your purchase of a TV, you notice that the POST request actually includes a "price" parameter that is set to $10,000.00.  You decide that's just way to much to pay for a TV, and so you change it to $1.00.  The TV gets shipped, you are charged $1.00 and no one is the wiser.  Now you get gready and purchase another TV at -$10,000.00 and not only get another TV, but get a nice credit back on your credit card for the purchased TV.
  3. Vertical and Horizontal Privilege Escalation - Imagine you are using a lending site and request a loan for $100,000.00 eventhough you have terrible credit.  Now, imagine performing a vertical privilege escalation to the user role of a loan approver on the site and you decide to go ahead and approve your own loan.  Imagine another situation where you manage your 401K and you can horizontally privilege escalate to gain the rights to view/modify the data for another user of the site.  What's a WAF going to do to protect you from that???
  4. How about native code calls in languages like Java?  You think your WAF is going to be able to detect a buffer overflow attack?   How about a format string flaw?  Heck, having a WAF probably opens up the possibility to get hit with one of these attacks even more.
  5. Cross-Site Request Forgery - I could be wrong here, but I see no way at all that a WAF could prevent you from cross-site request forgery.  Jeromiah Grossman has had a huge amount of interesting discussions about this attack, so go check his stuff out.
  6. Taking Ownership of Content - When you allow a user to upload arbitrary files to your server (think gmail, hotmail, Yahoo, YouTube, MySpace, etc.) you put yourself at all kinds of risk (see my future BH Vegas talk (hopefully) with Billy Rios, Rob Carter, and John Heasman).  See some of Rios's latest stuff.
  7. Web Services - I'm not sure how effective a WAF can be at protecting a Web Service, or if they even have current provisions for that.
  8. AJAX - Again, I don't see how it could be easy for a WAF to prevent these types of attacks (think DOM based XSS like I mentioned before).
  9. Encraption - Home grown encryption and obfuscation can become an issue, what's your WAF going to do about that?
  10. etc.

Am I completely off base, or has the PCI group just neutered its standard?  I mean, I have tons of certifications, like my CISSP.  That doesn't make me a bad ass.  Does having a PCI certification mean you are secure???  I think not.

-Nate

Editorial standards