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.

Worked on an interesting assignment at work the other week. A little background first. TIBCO is a middle-ware solution used frequently in the financial industry. Tibco allows legacy applications to talk or communicate with each other. For example, a process in C++ can publish a TIBCO message that can be picked up and processed by a Java process and vise-versa. TIBCO is set up to run throughout the firm, across many different applications. TIBCO can be set to run in two modes; ‘reliable’ and ‘certified’ mode. Reliable messaging is not concerned with the receiving party actually receiving the message, it’s a publish and forget. If the recipient picks up the message that was sent, fine. If the recipient didn’t pick up, also fine. That is not the publishing process’ concern. Certified messaging, on the other hand, makes sure the receiving process or processes (multiple processes listening) actually get the message. If the receiver didn’t get the message because the process crashed, messages will be queued up so that when the process comes back up, the messages in the queue will be published out again.

The main process that runs on Unix talks to the Front-End (FE) trading system in reliable mode. The messages that are published to the FE are order acknowledgements, executions, tickets, amongst other types of messages. The FE processes these message in real-time. You can imagine all these messages being published out to 1000+ trading FE’s. So it’s possible that all these processes running might overload the network, especially in high volume trading times. We, therefore, needed a way to ease the amount of data sent over the wire to all these FE’s. I decided to try good old compression similar to ZIP and GZIP. I implemented a solution in JAVA that compressed the Java String message before it was published out over TIBCO to the FE. The FE needed coding modifications for this solution, as well, to handle the compressed messages and perform the decompression on the fly. I also made sure that this functionality can be turned off at run-time, just in case something unforeseen happened and we need to revert back to sending messages uncompressed.

Data compression reduces the size of data by using a compression scheme. There are many different types of compression algorithms that are used differently for certain types of files. The table below shows the compression rates of a few sample messages that were compressed using “on the fly” compression. Notice that the bigger the message, the better compression rate you will get. The reason is that “on the fly” compression uses a substitution scheme, so the more repetitive the text, the better compression rate you will get.