Hack #1, hidden fields in forms
First, let’s define what a hidden field is. Here is a line of HTML from a web form:
<INPUT TYPE="HIDDEN" ID="ACCOUNT" VALUE="1234">
That sort of line is typical in web pages that are generated from server-side business applications that work like this:
- A user gets a login page where they are expected to enter a User ID and Password.
- When the page is submitted the server-side app checks for fields named User, Password, and Account. If User is present, the login code is executed, and the Password field is checked against a table. If Account is present, the software assumes the user is already logged in, and opens files related to the account.
The reason why developers use hidden fields is that the user’s "state" within the application needs to be preserved somewhere. A developer can’t be sure that any given user is going to have cookies activated to store data, so they put hidden fields in the form, and those fields get sent back to the server on Submit. Rather than putting a lot of data in a cookie or hidden field, developers (we) choose to usually just insert a token, an ID to uniquely identify the user. When a page comes back to the server, all of the user variables are read back into memory using the ID, we know where the user was and what they’re doing, and when we’re done processing the current transaction we just write the state back to disk and embed the token in the page going back to the user.
Most developers assume the page is going to come back to the server in the same condition that it left the server. If you’re working on an Intranet or Extranet with trusted business partners and employees, then this is almost certainly the case, though not guaranteed. Because of the sense of security, people are tempted to put meaningful data into hidden fields, like CustID, UserID, and other identifiers. But if the application is exposed to the Internet then there are no guarantees.
|The assumption must be that when the page comes back it has been maliciously hacked and someone is trying to access data that they shouldn’t.|
For example, anyone on the internet can use what are called bookmarklets, or favelets to execute code against a page being viewed. When you click on a link in your Favorites list, all the browser does is set a browser variable called document.location to the value of the link. Well, a whole script in a Favorites item will do a lot more than change the page location, it can display and modify the HTML in the page currently being viewed. Such bookmarkets are typically used to make web surfing more pleasant. There are scripts to turn off music on pages, standardize text formatting, change backgrounds which have annoying images, change the color of text and background to make pages more readable, etc. You’ll find a zillion of them here.
As an example, have a look at this Hidden Field Modifier Favelet. When you’re on a web page with a form it will allow you to see hidden fields. Now anyone, yourself included, can snoop around the forms in your website to see if any "hidden" fields have any data that should not be visible to a user. Really you can just right-click the page and View Source to see the same data, but this script will also allow people to modify those fields and then submit them back to the server.
Here is the script that they provide for people to put into their Favorites list:
You’ll notice that isn’t the actual script for viewing or changing the hidden fields at all. This just adds code to the current page being viewed which calls to the souce site for the actual script that does the work.
There are a couple things going on here.
First, you have "script kiddie Zaphod" (I’m trying to avoid using anyone’s real name) on your website poking around to see if he/she can have some fun or get some goodies for free.That may or may not be harmless.
Second, our script kiddie downloaded this script from a website, probably without looking at the scripts involved. The hiddenFields.js script itself is benign, I checked it and it’s coming from a reputable site with some good information on codig, but Zaphod could unwittingly have been running a script that would send the current page URL and other data from every form he uses back to the source server. That could provide some "real" bad guys with a link to your site along with data they need for getting in. It’s not little Zaphod (or your "mostly harmless" intranet employee) that we need to worry about, it’s the people that provided our irresponsible site user with the tools they needed to really do a number on your site. Again, this particular script is fine. I wonder though, if someone hacks that site and quietly replaces that script with something more malicious – how many sites might be compromised before anyone realizes?