Get Your Kicks on Route 66 was a popular song and rhythm and blues standard from the 1940’s. For those in the application security space, their idea of kicks on 66 may be found in the PCI DSS requirement for code reviews and application firewalls, specifically DSS requirement 6.6. PCI 6.6 is significant in that it, combined with OWASP may be the biggest forces to advance application security in recent memory.

Application security is a big deal and that is why it is at the heart of the Payment Card Industry (PCI) security standards and requirements.

Requirement 6.6 became mandatory in June and requires the validated security of web-based applications. Requirement 6.6 requires organizations that process credit card transactions to address the security of web applications, either via manual or automated source code reviews or vulnerability scans, or via the installation of a web application firewall between a client and application. In the US alone, there are a huge amount of merchants that not must deal with application security, something many of them have never thought of until PCI made them wake up from their slumber.

There is a plethora of information available on the web regarding 6.6, so it is not necessary to fully repeat that here. But in a nutshell, the application code review requirement mandates organizations to meet this requirement 6.6 via an application code review or automated vulnerability scanning tool to identify application security issues.

The requirement to have a web application firewalls in front of web applications are to ensure that attacks can be blocked before credit card data is compromised. A web application firewall can also mitigate the risk of an insure application, in that it can detect and block attacks before an attack can occur.

Its been known for decades that the basis of nearly every software vulnerability is insecure or poorly written code. Yet for decades, application security has been ignored. PCI 6.6 is the long-awaited wake-up call for application security. Go get your kicks.

Ben Rothke is a security consultant and author of Computer Security: 20 Things Every Employee Should Know.

I was fortunate to attend this year’s OWASP  Web Application Security conference in New York city.   It was a fantastic experience where  I networked with some really interesting and nice people, participated in intriguing talks about application security and was introduced to some security vendors who captured my attention.  I chatted with Jeremiah Grossman from Whitehat security.  Jeremiah has contributed greatly to the world of web application security and is well known in the community.  You can visit his blog here.  OWASP, which stands for Open Web Application Security Projects, is an outstanding organization whose mission is to educate organizations and individuals around the world about Web application security through various means including articles, methodologies and tools.  OWASP set an industry standard with their OWASP Top 10 Web application security vulnerabilities.  In a previous post I talked about WebGoat which is created and maintained by OWASP.   In that post I discussed SQL injection, which is one the of the OWASP top ten “vulns” (vulnerabilities).

Fortify was one of the vendors I met.  I had a nice talk with Erik about Fortify and the solutions they offer companies.  As it turns out, unbeknown to me, my company has an enterprise site license from Fortify.  The suite of products is called Fortify 360 and one of the features allows organizations to conduct static analysis of an application’s source code.  Later in the conference I met someone from my organization who also mentioned that we have a site license and told me how to go about getting the Fortify source code analyzer installed on my machine at work.  He also gave me a demo of the product.  I really appreciate his involvement in assisting me with Fortify.  Getting my security fix at work is a big milestone for me.

I wanted to share my initial experience with Fortify’s audit workbench (code scanning product).  My first code scan using this product was WebGoat application.  What better way to prove that a code analyzer is up to snuff than to use it on a web application replete with known vulnerabilities.  It turns out WebGoat is a demo application included with the Fortify product.  I pointed the Audit Workbench to the directory where the WebGoat source code resided on my PC and it started it’s thing.   Below is a screen shot as the scan is taking place:

Ok , here is the summary of issues that Fortify found after the scan completed.

Notice how the issues are broken down by Hot, Warning and Info.  The Hot issues are known vulnerabilities that are considered critical and can be exploited.  You can see the different classes in the left upper corner; Command Injection, Cross-Site Scripting etc.  We discussed SQL injection in the WebGoat application on a previous post so I thought it would be cool to show you what Fortify found for this class of vulnerablity.  I  drilled down into the SQL Injection section and whala! take a look at this!!

Remember that I wrote, “SQL injection vulnerabilities are remedied by sanitizing the user supplied input. “  Fortify found that exact problem in the code; sanitizing user  input was not occurring.  Just in case you can’t read it in the Details section,  it says, “On line 166 of Login.java, the method login_BACKUP() invokes a SQL query build using unvalidated input. This call could allow an attacker to modify the statement’s meaning or to execute  arbitrary SQL commands”.  Exactly what we demonstrated in the SQL Injection post was possible!

Here is another “Hot” issue that Fortify uncovered that I want to share.  Take a look at the  screen shot below:

This is more stupidity than an explicit vulnerability.  In the highlighted  line of code there is a Database connection being made and the username/password is hardcoded.   The reason why this isn’t smart is that usernames/passwords can change often and each time changed would necessitate a programming modification.   I know from experience as a Developer that where, applicable, one should always put config values like these username/passwords in config files.

So far, my experience with the Fortify product has been very positive.  I plan in the future to use the analyzer against my own code to ascertain the vulnerabilities in the code that I write.  As a developer, it is a challenge to meet deadlines and write securely by thinking like an attacker.  Fortify is a good tool to make this possible.