I was reading this great article about the Mozilla DOM Inspector. The Inspector enables developers to make on-the-fly manipulations to a page in order to debug and try out ideas and solutions. If you haven’t discovered the DOM Inspector yet, it’s worth reading the article as it’s another useful tool to have at your disposal. (It inspects JavaScript and CSS as well as HTML/XML).
This article demonstrates the power of the Inspector by asking you to manipulate a link on that very page by changing its href to one of your own choosing. It occurred to me that this could have quite an impact on web applications and those who write them. Whilst developers always have to be conscious of the fact that anything client-side is open to variance, the DOM inspector makes it pure childsplay.
Consider the common scenario of credit card payment gateways. Basic gateway accounts usually function by the vending site posting a form to a script at the gateway telling it how much to charge in the transaction. The value is usually kept in a hidden field in the standard HTML form. It doesn’t take a genius to realize that a local copy of the page can be saved and edited to hold a different transaction value and then posted to the gateway. However, this is usually accounted for by maintaining application sessions and the gateway only accepting posts from a recognized referrer. If you save a local copy of the page the referrer HTTP header shows the page is not part of the vendor’s site and the gateway rejects the post.
Even this isn’t perfect, as it’s not too hard to spoof HTTP headers. It does, however, prevent opportunist theft to a reasonable extent.
Consider the fact that with a powerful tool like the Mozilla DOM Inspector you can change the value of that hidden field with just a few clicks and still have it pass the referrer check performed by the gateway. So easy that any kid can do it. Ouch.
It may sound grave, but this case isn’t too serious. No one who is concerned with ecommerce security to any valid extent relies on hidden fields in HTML forms. They may be used as a convenience but nothing more. All the calculations are backed up by secure server-side processing and ratification. It’s easy to secure a known point of weakness.
The real concern is with day to day web applications that pass data and meta-data around and collect user input from forms. If the page can be messed with by any average user whilst still maintaining an application session and any referrer or other checks, how is a web application supposed to cope with that? Building in that level of validation and contingency routines is a mammoth task likely to render many web apps uneconomical.
Whatever the risks, it’s certainly not the fault of the excellent DOM Inspector, but just the intrinsic nature of the web. The risk has always been there. I think the difference now is that as a web application developer I am forced to consider the risk and not simply excuse it as improbable.
What do you think?
Comments
Another thing that adds to the pot is new technologies like the .NET initiative. People are still programming in main frame languages because they’ve been around for so long and the development processes are so well documented that its a stable environment. Its the same with web technology... I’m reluctant to do loads of .NET stuff because I know the combination of some good stored procedues, a debugged COM object, wrapped in a small chuck of VBScript works! Yes there are flaws in those technologies but they are often documented and avoidable which makes for happy clients.