This is the third article out of a series of articles on security of Java web applications.In this article you can find some useful information about security audit tools such as Ratproxy.
The first article in this series is Java web application security. XSS.
Overview
As it is described by Google "Ratproxy is a semi-automated, largely passive web application security audit tool. It is meant to complement active crawlers and manual proxies more commonly used for this task, and is optimized specifically for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments (see the RatProxy Doc page)."
Environments
Ratproxy is currently believed to support Linux, FreeBSD, MacOS X, and Windows (Cygwin) environments.
Main tests
- Potentially unsafe JSON-like responses that may be vulnerable to cross-domain script inclusion
- Bad caching headers on sensitive content
- Suspicious cross-domain trust relationships
- Numerous classes of content serving issues
- Queries with insufficient XSRF defenses
- Suspected or confirmed XSS/data injection vectors
- HTTP and META redirectors.
Installing and run the Ratproxy
If you are a Linux user you can simply find Ratproxy RPM packages at the RPM pbone page (if there are no RPM packages anymore try to ask Google). You can also download the source code from the Ratproxy Download page and compile it with make utility.
After the installation open a terminal window and type the following command in order to become familiar with all the settings:
ratproxy --help
Let's run the Ratproxy! To include output from some less specific checks, the following set of options is a good starting point:
ratproxy -P <host>:<port> -w <outFile> -lextifscgjm
I have my local Tomcat at the 8090 port, so this is the command for me:
ratproxy -P 127.0.0.1:8090 -w /home/ggalkin/Ratproxy_log.txt -lextifscgjm
You can find all necessary information about arguments of Ratproxy at Documentation page or in Help.
Once the proxy is running, you need to configure your web browser to point to an appropriate machine and port (My browser proxy configuration is HTTP Proxy:localhost; Port:8080 ).
If you need help in installing and running Ratproxy on Windows, there is a nice guide: part 1, part 2.
The next step is to open the tested service in your browser and interact with it in a regular, reasonably exhaustive manner: try all available views, features, upload and download files, add and delete data, and so forth. Let's see a simple example.
Simple example
In the "Java web applications security. XSS." article we have already created a simple JSP page "Greeter" with a possible XSS reflected attack. Let's see it once more:
<?xml version="1.0" encoding="UTF-8" ?> <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Greeter</title> </head> <body> <h1>Greeter</h1> <form id="myForm" method="get"> Your name:<input id="in" name="in" /> <input type="submit" value="Get greeting" /> </form> <% String in; if(request.getParameter("in")!=null && request.getParameter("in")!=""){ in = "Hello, "+request.getParameter("in")+"!"; }else{ in = ""; }%> <%= in %> </body> </html>
Now you should run a simple dynamic web application with the JSP page described above, point your browser to the web application, enter your name and submit the form. Do not forget about a host and port you have specified for the Ratproxy (127.0.0.1:8090 for example):
Finally you can terminate the Ratproxy with Ctrl-C.
Report generation
Once the Ratproxy is terminated you can generate a human-readable HTML report from the machine-readable log file.
./ratproxy-report.sh <outFile> <reportFile>
In my case I've run the following command:
/usr/bin/ratproxy-report.sh /home/ggalkin/Ratproxy_log.txt > Ratproxy_report.html
This will produce an annotated, prioritized report with all the identified issues. Now you can open Ratproxy_report.html in your browser and see the result:
You can find Ratproxy_report.html in the Attachments.
Explanation: the “Greeter” is the XSS candidate page where query parameters appear to be echoed back on the page and query data is predictable to third parties. Request does not require cookie authentication.
In conclusion, issue urgency is not high, but this issue is a candidate for further testing.
As you see the problem reported by Ratproxy is self-explanatory.
For the further information see the Ratproxy documentation page.
References
Comments