Skipfish - Google's automated web security scanner - A use case
Posted by Matt Rajkowski on March 23, 2010 5:15 PM.
Google recently released Skipfish, a command-line tool for testing the security of web applications. I decided to download the source code, compile it, and then test it on one of our beta instances of ConcourseConnect. ConcourseConnect was previously tested by a 3rd party security company so I was eager to find out how things would go this time around.
Skipfish is easy to compile and use on Mac OSX. You must have Apple's Xcode installed first. Here's the steps I took to run Skipfish:
- Download the skipfish source from the Skipfish Google Code Project
- Download the required library libidn, I grabbed the latest version 1.18
- Install libidn by extracting the libidn contents, then typing (in a terminal):
- sudo make install
- In the Skipfish directory, use Terminal to compile skipfish by typing: make
- Copy the file called dictionaries/minimal.wl to skipfish.wl
If all goes well, then you can test your web application.
Using a web browser, navigate to a test instance of ConcourseConnect (or any app you want to test). Make sure it is a test instance because Skipfish will be navigating to every link that it sees on the website. It's possible that it can add data, delete, and modify so never run on a production instance. You can optionally login to the test instance with a username and password. If you do this, Skipfish will test even more links and act as a logged in user.
Once the browser is showing your site, go to the browser's preferences and show the cookies for the site. For the test site, copy the contents of the JSESSIONID. This is the server session that Skipfish will use for testing. (Safari doesn't let you copy the cookie contents so I opted for Google Chrome). Obtain a session id each time before you test as the session may have expired. You can also use a command-line tool to create and obtain the session id for automated testing.
I used the following parameters to test ConcourseConnect:
-C JSESSIONID=A2D311CE14F6B6A437812CCBFB1D8F07 \
-o site_results \
-X /connect/logout \
-X /logout \
These parameters told Skipfish to use the JSESSIONID cookie, to output the results into a directory called site_results, to avoid the logout command (which tells the server to invalidate the session id), and to test the site which is running on my local computer.
The results were interesting... and really only a few items were relevant.
Skipfish reported 32 warnings: Integer overflow vector, Format string vector, SQL injection vector, Shell injection vector, and Server-side XML injection vector. I reviewed the instances and didn't find any evidence of a real problem. Skipfish also reported some semi-important warnings: Directory traversal possible, Conflicting MIME / charset info, Incorrect or missing MIME type, External content embedded on a page, and XSS vector in document body. I also reviewed these and confirmed two issues that we were able to correct.
Overall the results were certainly helpful. I figured if someone out there is going to use this tool to do harm, then we must use it ourselves as part of the code release process. Regardless of the results, this is a great way for someone to gain some personal insight into web security and to incorporate the findings into all of your web apps.