OWASP 2008 and Fortify
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.















October 6th, 2008 at
Ron,
Glad we had a chance to meet and talk at OWASP. I received a link to your blog through two other intermediaries, one of which read your blog and forwarded it to our company. I’m glad that you were able to get a copy of Fortify SCA at your company (though I can’t remember which firm you’re with). Thank you for the positive write up on your blog of our static analysis product.
I’m not sure of the license that your company has with Fortify, but you may to check to see if you also have access to Fortify PTA (Program Trace Analyzer). You may recall from our discussion that this analyzer is a grey-box runtime (rather than static) analyzer that works against a running Java or .NET web application. The unique proposition that PTA provides is that it identifies security vulnerabilities in your application without the need for you to attack the application … all you need to do is run any type of standard quality test against it … anything from sanity testing to full blown automated regression testing … basically, the testing you need to do ANYWAY only with PTA you get Security Results in addition to the Quality Results.
Then the results can be exported into your defect tracking system and viewed/merged with the SCA results in Audit Workbench or your IDE. Taking it a step further, it can even be used to help reprioritize the SCA results that you have received since there is runtime evidence of the ability to exploit such vulnerabilities.
http://www.fortify.com/products/detect/in_testing.jsp
Best wishes,
Erik Klein
Software Security Consultant
(W) 732-936-0573
(M) 650-810-6102
(F) 650-358-4708 Fortify Software
Local: NY/NJ/CT/PA/DE Area
HQ: 2215 Bridgepointe Parkway, 4th Flr
San Mateo, CA 94404 USA
http://www.fortify.com
October 8th, 2008 at
Ron,
As always, good post on a timely topic.
I am not an applications guy, but in speaking with those who are experts in that area, one thing they caution is for people to put too much trust into the app scanning tools. One issue of many is that the tools often don’t catch code logic errors.
While they can easily identify the common family of application errors (for a good list, see http://www.ouncelabs.com/pdf/Redefining_Software_Security_Audit.pdf), what happens when the code is perfect, yet failures due to errors in the design, construction, or use of the system cause it to fail under particular combinations of conditions?
Really tough problem for which there are no simply answers or software tools to fix.
Ben