Merry Christmas

Not Happy Holidays - Happy Christmas!

Increasing your attack surface

I've been looking at a lot of web applications recently, and have done some interesting experiments with them. Too many developers put values into ReadOnly or Hidden Fields, confident in the knowledge that they are safe. After all, they can't be seen or updated... can they?

Well! I've been using the javascript: handler for years. When I started at my place of employment, no one had seen this, but it's surprising how useful this is. To demonstrate, simply type the following into the address bar and hit return:

javascript:alert('hello world');

You should see a javascript alert dialog box pop up.

Extend this to it's natural conclusion, and you begin to see statements like:

javascript:document.getElementById("ReadOnlyBox").value = "blah!";

That is, you can update anything on the client that can be accessed through the DOM!

This method has become deprecated with the release of the IE developer toolbar - in many situations, it's alot easier to use the dev toolbar to change values of controls on the page.

In effect, with web applications, you are giving your interface to a third party that can be quite hard to validate. You need to be very careful about what information you give to the third party, and you have to be very careful about just accepting the values posted to you.

It's probably best not to do the following whn writing secure applications (I'd love to see rebuttals!):

• Rely on hidden or readonly fields to pass data about someone to and from the server. It's safer and easier to associate some server side (session based for example) data with the request that the user can't see, but is persisted between page hits. Or, if you need to put data on the client, encrypt it!


• One log in prompt allows access to all functionality. Although less convenient, it is far safer to periodically ask the user to revalidate their credentials. As long as your validation process isn't too onerous, you've secured functionality. This is especially useful if the user is in a situation where they could leave their workstation.


• Rely too much on client side javascript in an Internet Environment. Let me elaborate on this one... javascript is wonderful, it is possible to create brilliantly interactive user interfaces al la Ajax (and I use it alot:-). It's also a pain in the ass to debug complicated javascript, and it runs on the client machine and thus exposes further vulnerabilities. So if security is of prime concern, it's probably best to limit javascript to simple client side validation... which should never replace server side validation. It goes without saying that you can get away with more (not that you should) in an Intranet environment - you are more likely to be able to successfully validate your user's identity for example.