Fiddling with Fiddler and other Web Application Testing Tools

Part of my job in Information Security at a large international corporation is to evaluate the security of web applications. I get to test for security risks in both internal web apps (either bought or built) as well as third-party ASPs. This is the fun, “hacking” part of my job. In this blog, I’m going to tell you how I do it. My intention is to inform you about each of these tools, not provide a full tutorial.

Before I get to the “how,” I will explain the “why.” According to one vendor, 8 out of 10 Web sites has at least one serious vulnerability. Gartner concurs, stating over 70% of attacks against an organization’s network come at the application layer, not the network or system layer. While I have no idea how they got their numbers, my gut tells me they’re right. You should also see the OWASP Top Ten list of Web Programming Mistakes (http://www.owasp.org/index.php/OWASP_Top_Ten_Project) for the reasons why most web apps are insecure. Lastly, these days everyone is creating a custom web interface to their application. With all this webifying, there has got to be problems. It’s part of my job to look for those problems.

I primarily use manual tools and techniques for my web application assessments. These tools include Fiddler, WebScarab, TamperIE, Bayden IEtoys, and the Internet Explorer Developer Toolbar. Let me explain a little about each:

• Fiddler is an “unofficial” Microsoft free tool and is available at http://www.fiddlertool.com/fiddler/. It is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and “fiddle” with incoming or outgoing data.
• WebScarab is a similar product from OWASP (http://www.owasp.org/index.php/OWASP_WebScarab_Project). It is a framework for analyzing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.
• TamperIE is my favorite. Available from Bayden Systems (http://www.bayden.com/other/), TamperIE is an Internet Explorer plugin that allows you to intercept POSTs and GETs before they occur and gives you a chance to tweak it (change/add POST data). It acts like a proxy intercept, but isn’t one. You can view cookie information as well as all of the input fields that are sent from the client browser to the server application. TamperIE allows you to “tamper” with any input field and even provides built-in examples of SQL injection, cross-site scripting, and buffer overflows. All of this happens after the client has performed any input validation. It’s one of the easiest ways to check for Web application flaws.
• Bayden also provides many other IEToys. They include a tool to cleanup annoying graphics, a web-based dictionary and encyclopedia, IE clear tracks (allows you to delete all browsing history in one click), and a highlighter.
• Internet Explorer Developer Toolbar is also from Microsoft (http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en). It provides a variety of tools for quickly creating, understanding, and troubleshooting Web pages.

What I really do is something that a tool cannot do: mess around. This is where it really gets fun. I act like a regular user and try to break the web application by doing things it doesn’t expect. This include URL manipulation (deleting or changing fields on the URL), Predictable Resource Location attempts, login tampering (trying different login accounts such as admin), and trying to create error messages to see what information it gives out. It’s a lot of trial and error. Web applications tend to be different, so there’s no one set way to do it. That’s why I don’t see how an automated tool can fully test a web application.

From the Forrester View article on Application Security Testing (http://www.expresscomputeronline.com/20060306/management02.shtml), “Fancy tools aren’t enough. Automated testing tools can’t replace smart QA people. Just as attackers use tools and their own expertise, you need to combine tools and expertise to fight them.” I agree; tools are just that: tools to be used by humans to do a job. You need to know what the tool does and how to use it.

I know my method is far from complete, but it does find the lowest hanging fruit. What tools and techniques do you use? What suggestions do you have to help ensure your web applications are secure? Please provide comments below to add to this discussion.