Ratproxy is a passive web application security assessment tool released by Google. Basically you set it up as a proxy server between yourself and the target site, and then click around in the target site doing whatever it is you normally do, while ratproxy analyzes your activity in the background and looks for security holes.
I couldn’t figure out how to compile it on OS X - I kept getting a warning aobut the flare binary (love the bianry mis-spelling):
I read the flare-dist/README and downloaded the mac-specific binary, but i still kept getting the same error. After about an hour of trying various hacks I just gave up and decided to run it on a virtual Ubuntu install in Parallels. This was straight-forward with aptitude :
Once it was installed on Ubuntu, it was dead simple to get running (obviously replacing my-site.com with the site you want to test) :
1 2 3 4 5
The various options are explained in depth on the ratproxy wiki, so I won’t go into them here. Reading documentation is not my strongest point, so I sat around for a few minutes watching ratproxy do nothing before I started wondering if there was something else I was supposed to do. A quick trip back to the wiki was enlightening :
Aha! We need to set up firefox to connect via ratproxy. Open up Advanced -> Network -> Settings and add the proxy information as follows. The HTTP Proxy set here (beta) is the name I have set up in my /etc/hosts file as a shortcut to my virtual Ubuntu box - substitute the domain or IP address of the machine you’re running ratproxy on here. 8080 is the default port ratproxy runs on - you can change this if you want using the -p argument when you start it up.
It’s quite handy to add the FireFox QuickProxy plugin too - it adds a toggle button in the bottom right of your browser window so you can easily enable/disable the proxy :
When I first did this, I couldn’t connect via firefox, and noticed the ratproxy log said :
The fix for this was to add the -r option (included above), which allows connections from remote machines. Since I was running ratproxy on a virtual box, I couldn’t connect without this option. After adding -r we have more luck :
Once I had FireFox set up with the proxy, testing was a simple matter of clicking around the site watching the report.log file grow as ratproxy collected information. Once you’re satisfied that you’ve tested the major parts of your site, you can stop the proxy and move onto reading the report.
Reading the report.
This report.log file produced by ratproxy isn’t really human-readable, but luckily google has provided a script to convert it to HTML. ratproxy.googlecode.com/svn/trunk/ratproxy-report.sh, save it somewhere and make it executable :
Now that you have the converter script, you can generate the HTML report by running it on the report.log file we’ve produced :
Open the resulting report.html file and you can see the results of your test :
If you get a basically blank report with no errors, chances are the data wasn’t collected properly - if your report.log file is zero bytes then this is the case. If this happens, try removing the -d my-site.com parameter and run your test again and you may have more luck (although using the -d option is recommended).
Fixing some of the problems.
I had a couple of hundred ‘vulnerabilities’ of varying severity. Luckily most of them could be grouped into a couple of categories, and fixed en masse.
“MIME type mismatch on renderable file”
1 2 3 4 5 6 7 8 9 10
There were various other low-severity MIME type mismatch_es for static .js_ files such as this :
…and getting to the heart of the problem :
These were easily fixed by forcing the mime-type and encoding for files with a .js extension in Apache :
1 2 3 4 5 6 7 8 9 10 11 12 13
I had a similar problem with .css files :
… notably :
The solution to these was similar to the .js fix, but for the .css extension :
1 2 3 4 5 6 7 8 9 10 11
“Inline PNG image”
I had about 50 warnings about inline PNG images :
After a bit of googling I found out that ratproxy wanted .png files to have a Content-Disposition attachment header, to fix a vulnerability in IE6. Once again this was easily fixed in the Apache config :
1 2 3 4 5 6 7 8 9 10 11 12 13
Since you’re almost certain to get a different set of problems to me, there’s a good explanation of the various error codes that is pretty much vital in getting to the bottom of some of this stuff.
I’m not sure how serious any of these vulnerabilities would be out in the wild, but it’s great to have a (free!) tool that goes into this much depth.