If you would like to read the other parts in this article series please go to:
- SPIKE and BURP for real world computer security usage (Part 2)
- SPIKE and BURP for real world computer security usage (Part 3)
- SPIKE and BURP for real world computer security usage (Part 4)
HTTP proxies are a widely used tool by computer security professionals. They are however largely unknown to a large segment of computer security enthusiasts. This article series will demonstrate how to use an HTTP proxy.
HTTP Proxies and you
The world of computer security is a constantly evolving one. There is a continuous stream of exploits being found in one program or another. It is pretty much impossible to be fluent in all aspects of computer network security. Due to the nature of computer security and its many, many aspects one should almost choose a niche and try to specialize in it. One such area is web application security in its many forms. Why do I say in its many forms? Well not all web applications are written in the same language. Nor do they all share the same configuration or supporting back end programs.
Web application security is an interesting area to specialize in actually, and also a good one. There will always be web applications as the Internet largely evolves around web sites with a myriad of various applications. These applications are of course designed for the potential client to use and interact with. Simply because the public face of a company on the Internet was created by professional programmers does not mean it is bug free. Quite the contrary as we all know. It is well nigh impossible to write perfect code regardless of the language used.
This leads to another facet of web application security. Quite often a large amount of web applications are coded in-house with little in the way of quality assurance. The company programmer will likely simply be happy to have finished the project on time, and has little leeway in assigning time for code audits. There are some tools out there that will do code audits, but many of them are prone to a high volume of false positives. The ones that are good are almost always prohibitively expensive.
All of us non-programmers can appreciate, I think, the difficulty of writing good code. It is especially true when it comes to an enterprise class software program and the thousands of lines of code that make up such a program. There is another side to this as well though. While the programmer may have an excellent grasp of the programming life cycle, they may not always have a firm grasp of the protocol they are generating code for. This is where a firm grasp of the protocol comes in handy as well. While maybe not critical, it certainly helps to know the in’s and out’s of the protocol in question.
So the programmer is now finished writing the web application that he or she was tasked with. It is now time to test it out and try to find any flaws or glitches in it. What would be the best way to do that? Well good question actually. That brings us back to the purpose of this article series. Testing out the brand new web application is best done using an HTTP proxy. This truly excellent tool will allow the developer to interact with the web application in ways that a typical web session would not recreate. The developer can intercept the client side request and change almost every field within to stress test the web application.
Get on with it already!
Hopefully you have not fallen asleep on me by now. It is important to always give some background information for a subject so as to better understand it. The two HTTP proxies that we will look at and use are SPIKE and the BURP suite. The former was written by the very talented Dave Aitel of Immunitysec and the latter, BURP suite, was written by various people as far as I know. I was not able to find a list of contributors to the BURP suite project unfortunately.
Now it is time to install the SPIKE proxy, and you will have hopefully downloaded it by now from the hyperlink in the above paragraph. You will notice there that you need to have a Python interpreter for SPIKE to work. Please surf on over to CPAN and download the Python binary there. You will need to supply an email address, but that is all. Now that you have downloaded and installed Python you will need to also put SPIKE at the root of c:\ drive. From there open up a DOS prompt and open up the SPIKE directory. You will need to read the README.txt file to properly configure your web browser.
Figure 1
Figure 2
Your last step is to now simply type in “runme.bat”. Once you have done so simply type in the url bar in your browser “http://spike/” and you will see SPIKE. We are now in business! Congratulations for you have now installed and configured an HTTP proxy. What to do with it now though? That’s easy enough to answer. Let’s have some fun playing with a web server. In this case I have simply installed the Apache web server on another VMware image for our testing purposes. This will allow us to play with SPIKE in a controlled lab environment. There has been nothing done hardening wise to the web server. Lastly, I have installed a cut down version of my own web site on it for some content.
Time to have some fun!
Whenever you do any type of professional work you should always have some form of packet sniffer running in the background. This is so that you can verify the tools’ output that you are running in case of discrepancies or strange results. This is no different in our case. I shall spark up tcpdump from MicroOLAP which will work fine with Windows XP SP2. It is free for home use. This tool’s installation has been covered several times before in some of my other articles so I won’t dwell on it. Simply said, uncompress the file, and install it at the root of your C drive ie: c:\.
Now that we have our packet sniffer running we will simply tell it to log only the packets between the computer which SPIKE is running on and the computer running our Apache web server. This will cut down on the amount of packets the attacking computer might otherwise see. You can further refine this by instructing tcpdump to log packets with port 80 in it. For an example of this tcpdump please see the below noted screenshot.
Figure 3
You can see I have 945 packets collected in the second or two before I killed the tcpdump session. This is other background activity I have running on my computer. That pretty much exemplifies why you want a relatively narrow collection filter when running lab tests or doing real work. We can see so far that there is a fair amount of stuff to bear in mind before moving forward with using and/or learning how to use an HTTP proxy. It always pays to do a little homework before attempting to learn something new. Otherwise you can easily confuse yourself, and even worse, frustrate yourself to the point that you give up learning how to use a specific tool. We will break the article off at this point, but stay tuned for part two as the HTTP proxy usage will be fast and furious. See you in a bit!
If you would like to read the other parts in this article series please go to:
