This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Reviews

Testing Web application security using Google's ratproxy

By Keith Winston on July 29, 2008 (4:00:00 PM)

Share    Print    Comments   

To help developers audit Web application security, Google has released an open source tool called ratproxy. It is a non-disruptive tool designed for Web 2.0 and AJAX applications that produces an easy-to-read report of potential exploits.

Ratproxy is a local program designed to sit between your Web browser and the application you want to test. It logs outgoing requests and responses from the application, and can generate its own modified transactions to determine how an application responds to common attacks. The list of low-level tests it runs is extensive, and includes:

  • potentially unsafe JSON-like responses
  • bad caching headers on sensitive content
  • suspicious cross-domain trust relationships
  • queries with insufficient XSRF defenses
  • suspected or confirmed XSS and data injection vectors

Many more tests are performed, all enumerated in the messages.list file included in the package.

The ratproxy package consists of source code, documentation, and an optional component for testing Adobe Flash content called flare-dist. A standard Make file is included, but no configure script. To build the program, simply run make:

   
$ make cc ratproxy.c -o ratproxy -Wall -O3 -Wno-pointer-sign -D_GNU_SOURCE http.c mime.c ssl.c -lcrypto -lssl *** WARNING: flare-dist/flare bianry is not operational. *** Please see flare-dist/README and update it for your OS.

I got the warning because I compiled on Mac OS X, while the Flash testing component in the package, flash-dist, is the Linux version. An OS X version of flash-dist is available, but I did not need it for my testing. The package compiles to a single binary named ratproxy.

The easiest way to get started is to use the recommended start up parameters. The -d parameter tells ratproxy to run tests only on URLs at the specified domain, so it won't accidentally test a site your application links to for images or advertising. The -v parameter tells it where to write trace files, and -w indicates where log records should be written. The log file is used to generate the detailed report.

   
$ ./ratproxy -v /tmp/ -w ratlog.txt -d mydomain.com -lfscm ratproxy version 1.51-beta by <lcamtuf@google.com> [*] Proxy configured successfully. Have fun, and please do not be evil. [+] Accepting connections on port 8080/tcp (local only)...

 

These start up parameters don't include ratproxy's optional disruptive testing mode. If you see the "Accepting connections" message, ratproxy is running locally and listening for connections from a Web browser on the default port of 8080.

The next step is to fire up a Web browser and configure it to connect to ratproxy at 127.0.0.1:8080. Then browse to your application and interact with it normally. Try all the features and visit all of your pages. While you are interacting with the application, ratproxy will observe and run tests. When you are finished with the application, you can close the browser and end ratproxy with Ctrl-C.

Reviewing the report

To create the HTML-formatted security report, run the included shell script against the log file:

   
$ ./ratproxy-report.sh ratlog.txt > report.html

The report.html file contains a list of all issues found sorted by type and severity. The first application I tested was a Ruby on Rails application written for benefits enrollment. The main issue ratproxy found in my application was "POST query with no XSRF protection," which points to a possible cross-site request forgery when updating certain information in the application. After spending some time analyzing the threat, I determined that the issue was mitigated somewhat because information can only be updated using an HTTP POST. Also, updated information must later be confirmed and reviewed by a third party.

On pages that use AJAX forms, ratproxy reported a medium severity issue, "MIME type mismatch on renderable file". There were also a set of informational messages revealing things going on in the application that were not obvious.

Next to each issue in the security report is a link to a trace file with the raw data for that transaction. Trace files contain verbose information on each HTTP request and response in plain text. They include cookies, header information, parameters, payloads, and more. Trace files let you see exactly what is happening between the browser and server. It's nearly as comprehensive as a TCP dump but much more readable.

Gunning for Geeklog and Google

The second test I ran was on the PHP-based Geeklog content management system. I chose it because it has a good reputation for security and, since I use it to run my own site, I had a ready target. I logged into Geeklog on my site and performed several admin functions. The resulting report showed one high severity issue, "POST query with no XSRF protection," and a few medium severity issues, including "Suspicious parameter passing scheme." Interestingly, it also flagged links to Google ads as a low severity issue -- "References to external active content." None of the issues appeared particularly alarming.

As a final test, I pointed ratproxy at google.com, logged in, and added a few widgets to my iGoogle home page. I also changed the theme and moved a couple of things around. This was enough activity to generate 43 trace files and a hefty report. The screenshot shows a snippet of the report.

 

The security report from the iGoogle test produced three different kinds of high severity issues and a handful of medium severity issues. I didn't attempt to decode the report or verify that any of the issues were exploitable, but I was impressed with the thoroughness of it. Ratproxy pulls no punches and plays no favorites.

At this time, ratproxy is still in beta, and the README file warns that some issues may be false positives. Still, testing modern Web applications for security issues is a difficult task. Ratproxy requires a minimal time investment, and the documentation is quite good. It even provides links to several other Web audit tools to help you secure your applications. I found ratproxy to be a stable, highly valuable, and easy-to-use tool.

Share    Print    Comments   

Comments

on Testing Web application security using Google's ratproxy

There are no comments attached to this item.

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya