First off, this is a long post so go get coffee.
For those of you that aren’t familiar with it, or programs like it, Burp is a local proxy similar to Paros which acts as a middleman intercepting HTTP/S requests and allows the user to inspect and manipulate the traffic traveling from the client to the server and from the server to the client.
Today we will be going over exactly what the title implies, testing web applications. The tools today will be: Apache 2, Tomcat 6, Burp Suite v1.1 and Firefox. Since we are going to be looking at raw HTTP traffic, this post has officially been renamed “raw-ass web app skillz.” Don’t worry, the material still remains the same.
Fulfilling the prerequisites can be a bit tricky, so for those of you on Ubuntu/Debian systems, let’s get you caught up.
You will need a working Apache 2 install so:
sudo apt-get install apache2
For a quick and easy Tomcat install, click here.
Burp which can of course be downloaded here
And firefox which you should already have.
We will be using our Tomcat install to run an insecure web application developed as part of the Insecure Web App Project developed by OWASP. And last but not least, the web application we are going to be using can be located here.
So, let’s go over our checklist real quick:
Firefox
Burp
Apache2
Tomcat6
OWASP Web Application
Since it looks like you have everything we should probably keep moving.
**I would like to take a minute to say that since you have Apache and Tomcat running, for this exercise it is NOT necessary to forward your webserver or otherwise expose your Apache/Tomcat service(s). These tests will be done on the loopback IP and since we are working with an already insecure web application, you do NOT want it exposed to the internet**
Now we are actually going to start the overview (I’m serious).
The first thing we need to do is tell Firefox that we are using a proxy, the proxy on localhost to be more specific. This will allow us to funnel our traffic through Burp. To do this we need to start Burp from its working directory and set our proxy settings in Burp as well as Firefox.
user@host:~/burpsuite_v1.1$ java -jar burpsuite_v1.1.jar
When the Burp window appears, you should be on the intercept tab, you will notice that intercept is on. This means that Burp will be grabbing our requests and holding them until we forward them. You may also drop them or hold them until you are finished inspecting them. Burp will also keep a history of all traffic for later analysis. In the options tab, check the box that says “proxy running on port,” and change the port to 7070. By default your Tomcat install uses port 8080 so if you do not change this, you will receive an error telling you that it could not use port 8080.
Once you have your proxy settings done on Burp, we need to fix them in Firefox. To do this, open up Firefox and then navigate to, edit > preferences > advanced > settings. Set it up so that your proxy settings look the same as those pictured below. Be advised that you need to remove the line in the field, “No Proxy for,” as it will not push traffic trough Burp on localhost. Once your settings match those in the picture below, click “OK” to save your changes.
With our proxy configured on both the browser and Burp, it’s time to navigate to our web application. If you haven’t checked it, read the documentation contained within the OWASP web application we downloaded for this exercise. In case you are lazy (there are a lot of you out there, admit it) I took the liberty of quoting the document.
1. Copy insecure.war file to tomcat’s webapp directory
2. Start Tomcat then use sqltest.jsp to test Tomcat’s database connection.
sqltest.jsp
You should see a list of users and passwords that you can use to login into the application.
Note the application’s database tables are reset to the initial values each time the application is started.
3. Login to the application
Login
Be advised that if you click those links in the Firefox that is configured for our local proxy, they will not load unless you forward the traffic with Burp. We will get to that later but for right now, just copy insecure.war to Tomcat’s webapp directory. If you followed the tutorial that directory is going to be ‘/usr/local/tomcat/webapps.’ Again, for the lazy please run (where insecure is the directory you untar’ed the web app):
sudo cp ~/insecure/insecure.war /usr/local/tomcat/webapps
Let’s start examining our web application in Burp. The first thing you should do is go to your Burp window and turn off intercept. This way we can load the page right away. If you don’t want to turn it off, make sure you click “Forward” until the page loads. Once you are at the application page, go back to Burp and turn intercept mode on. In the proxied Firefox browser navigate to http://127.0.0.1:8080/insecure. If things are working per the tutorial, your browser should look similar to the picture below.
So, right now you should have that pictured page loaded and Burp in interept mode. In case you got lost finding it, it is under the Proxy > Intercept, tabs.
Now, let’s try and log into our web application with anything we choose. This request will need to be forwarded manually through Burp proxy. After you enter a username and password of your choice (make sure it is invalid), click login.
Per usual, this request will need to be forwarded through burp and even though it is not in our immediate window, we can view the contents of it in our history tab. In the screen shot below we can see the raw information on our request under the raw request tab. How appropriate especially since this entry was officially named “raw-ass web app skillz.”
As seen in the shot above, we can examine some detailed information about the request/reply using out history tab. This is pretty normal to be honest and could most likely be viewed via TCP reassembly in Wireshark even though it is not as straight forward.
Now, let’s examine real authenticated requests. If you followed the instructions and clicked sqltest.jsp, you most likely saw a table listing valid login information. For the lazy, see below.
USERID LOGIN PASS NAME EMAIL ADMIN
1 admin secret Administrator admin@mail.com 1
2 asmith andy Andy Smith andy@mail.com 0
3 bmoody beth Beth Moody beth@mail.com 0
4 cjones chris Chris Jones chris@mail.com 0
Let’s use the 2nd login info, because that is my name. Log into your application with the userid ‘asmith’ and the password ‘andy.’ When you are logged in, you will see something interesting. Well, not necessarily all that interesting, but a different page at least. This is the page for our Asmith. Why is this important? We are going to examine that request, which unlike our first, was a valid authentication. From there we will see what we can make happen with parameter tampering, actually, you will be doing that without me.
Now, I will spare you the details but the GET requests are relatively the same. The only major differences are those based upon submitted login credentials. The first point of interest is the response. Why is this interesting? Well, that is actually where this tutorial ends.
I believe that best way to educate someone is determined by their desire to learn. If you paid attention to this post you should have learned a lot such as setting up and installing Tomcat, adding a web application and working with local proxies. On that note, figure out why you should care about the response and request information. Dissect the application further and be sure to check the supplied information on the OWASP web application for additional practice tests like parameter tampering and SQL flaws.
In the mean time, don’t learn to hack, hack to learn!
P.S. If you are interested in more program features which are WAY beyond the scope of this post, be sure to stop over at the Burp page and read up on this awesome program’s features and capabilities.
P.P.S If you have read this far I am assuming you are probably at least relatively interested in the subject matter covered. If you want to learn more about auditing web applications with Burp leave a comment and if the response is solid, I’ll do a part 2 using the same setup and application(s).
P.P.P.S Good lord. This is the last edit I am going to make to this post but in the event that anyone is really fascinated by this, make sure to check out the OWASP Testing Guide.
