Forging HTML Forms with FireBug

It’s incredible how insecure most sites are. Even little things like HTML Forms. Most developers don’t even think about this while writing an application. They’ll include some small server-side script to cleanse inputted data before it gets sent to a database, but fail to see if anything has been tampered with; and if the information is legitimate. To illustrate my point, we’ll take a look at a first hand example I conducted this past week.

So this past weekend I get a notice from my water utility company saying we owe a balance and water will be shut off at any moment. This isn’t news to me, as living with broke college students is common catalyst for unpaid bills.

My roomates and I get together, go to the online services to pay the bill, only to find that the utility company requires us to pay in full … and not only that, restricts the payment form so that you must pay the entire bill in one single transaction! (Retarded I know.)

Well none of us have that much money to spot everyone, so I get to thinking. The form basically looks like this. (I’ve edited it for security purposes obviously.)

As you can see they’ve listed the balance, and disabled the Payment Amount field so I cannot adjust how much to charge to my card. Well here comes FireBug.

One feature of FireBug is that it allows us to inspect html elements and make edits to them in real-time. No page refresh is needed as it inserts it directly into the browser window.

I decided to examine the form elements and take out the <input> attribute: “disable” which has prevented me from entering my custom payment amount. Voila! The field become now editable. I then take a look further as I suspected there might be a hidden input element which tells the server-side processing how much it really should be…

And what do you know, I was right! So I edit that element’s value to reflect my newly inserted payment value. Submit the form and without a hitch, it takes my payment. I do this for the rest of my roommates using their own card and we pay the bill in separate payments successfully.

Now what did we learn from this?

Possibly that any kind of data inserted by a user MUST be processed extremely carefully. Obviously, if the utility company’s script made another check to see if my bill was unpaid and had to be paid in full, it would have thwarted this hack. It’s imperative that you NEVER place any security reliance on an interface that a user has access to. Hope we learned something!