Web application developers often trust that most users are going to follow the rules and use an application as it is intended to be used, but how about when the user (or a hacker) bends the rules? What if a user skips the fancy web interface and starts messing around under the hood without the constraints imposed by the browser?
Firefox is the browser of choice for most hackers because of its plug-in friendly design. One of the more popular hacker tools for Firefox is an add-on called Tamper Data. Tamper Data isn't a super complicated tool, it's merely a proxy, or go-between, that inserts itself in-between the user and the web site or web application that they are browsing.
Tamper Data allows a hacker to peel back the curtain to view and mess with all of the HTTP "magic" taking place behind the scenes. All those GETs and POSTs can be manipulated without the constraints imposed by the user interface seen in the browser.
So why do hackers like Tamper Data so much and why should web application developers care about it? The main reason is because it allows a person to tamper with the data being sent back and forth between the client and the server (hence the name Tamper Data). When Tamper Data is started and a web app or website is launched in Firefox, Tamper Data will show all of the fields that allow user input or manipulation. A hackers can then change a field to an "alternate value" and send the data to the server to see how it reacts.
Let's look at why this might be hazardous to an application:
Say a hacker is visiting an online shopping site and adds an item to their virtual shopping cart. The web application developer who built the shopping cart may have coded the cart to accept a value from the user such as Quantity = "1" and restricted the user interface element to a drop-down box containing predetermined selections for the quantity.
A hacker could attempt to use Tamper Data to bypass the restrictions of the drop-down box which only allow users to select from a set of values such as "1,2,3,4, and 5. Using Tamper Data, the hacker could try to enter a different value of say "-1" or perhaps ".000001".
If the developer hasn't properly coded their input validation routine, then this "-1" or ".000001" value could possibly end up being be passed to the formula used to calculate the cost of the item (i.e. Price x Quantity). This could cause some unexpected results depending on how much error checking is going on and how much trust the developer has in the data coming from the client-side. If the shopping cart is poorly coded, then the hacker may end up getting a possible unintended huge discount, a refund on a product they didn't even purchase, a store credit, or who knows what else.
The possibilities of misuse of a web application using Tamper Data are endless. If I were a software developer, just knowing that there are tools like Tamper Data out there would keep me up at night.
On the flip-side, Tamper Data is an excellent tool for security-conscious application developers to use so they can see how their applications respond to client-side data manipulation attacks.
Developers often create Use Cases to focus on how a user would use the software to accomplish a goal. Unfortunately, they often ignore the bad guy factor. App developers need to put on their bad guy hats and, in addition to use cases, create Misuse Cases to account for hackers using tools such as Tamper Data.
Tamper Data should be part of their security testing arsenal to help ensure that client-side input is validated and verified before it's allowed to affect transactions and server-side processes. If developers don't take an active role in using tools like Tamper Data to see how their applications respond to attack, then they won't know what to expect and could end up paying the bill for 60 inch plasma TV that the hacker just bought for 99 cents using their defective shopping cart..
For more information on the Tamper Data Add-on for Firefox visit the Tamper Data Firefox Add-on Page.
via netsecurity
Would love to here from you...