Remember what your mother used to tell you about validating parameters in web applications? That it was a good idea to do some checks via JavaScript to save a round trip to the server, but that these same checks must be done on the server as well?

The really crappy web app I use is one at work which we use for help desk / task management.

The problem is simple. The entire security scheme for the app is based in HTML and JavaScript. There are two parts to this security problem.

One is a series of JavaScript variables, which decide what queues you're allowed to read and write to, whether you are allowed to close tasks, and the like.

The other part is a Java Applet, defined with HTML parameters which decides silly little things like whether or not you are considered a support representative, or a user.

There was a day when, in order to mess around with all this, you'd have to go through a lot of hassle by saving the HTML, modifying it, and later loading it. With this particular app, doing that for the entire thing is a bit tough, due to it's rather complex usage of frames and Java.

But no worries, GreaseMonkey is here to the rescue. See, with GreaseMonkey, instead of having to bother with stuff like saving and reloading documents, we can simply instruct GreaseMonkey to change variables after they're loaded.

Really, GreaseMonkey is just a FireFox extension that runs user defined JavaScript on any given page. So, to start messing with this crappy web app, all we need is the following one line script loaded into GreaseMonkey:

write_perms_on_queue2 = true;

Well, the variable names in this app weren't quite that obvious, but you get the idea. That's all you need. Now repeat for all variables you want to modify.

There were also some JavaScript functions they had loaded that I considered annoying. They yelled when I clicked things they didn't think I was supposed to. They'd keep returning "false" (ie, failing) until I clicked things the way they wanted. No problem. Add this to your GreaseMonkey script:

document.annoying_function = function() { return true }

So far, we're on the first security problem. Lets talk about the second one. They have a Java applet which loads all the menu's. I dug around in the source a bit, and discovered tags like this in the applet definition:

Okay, good, I'm considered a 'Rep', but I think I'd like some more permissions.

Now, hard as I tried, I couldn't get GreaseMonkey to fix this. I think the Java Applet loads too early for it to do anything. So, I just saved the page which defines the permissions to my hard drive, and changed it to a more suitable number.

With the monotony of frames they had, I had to jump through a few other little hoops to make this work with this particular app. But, a couple of tweaks later, I load this app using the file on my hard drive, and viola, there it reads:

H4x0r3d Helpdesk Web Interface

There's not a whole lot I really gain by all this aside from some amusement (though, they should still be told about their lax coding, any of our users could do this as well... I guess I'm really not all that concerned though).

Moreso, I think this is a warning of where things are going. Where there used to be at least some hoops to jump through to change data on web pages we've loaded, there's now a mechanism for doing this automatically. There's a repository of such scripts online. I don't think most or maybe even any are bending any security; moreso, most are tweaking websites to better work for us. Which I think is great.

What I think we need to watch out for though is the ease with which one can bypass such poor security mechanisms. There may have been a day where coders could get away with such things, but thats long gone.

Hey, that's pretty cool.

Funny you mention that, I had ended up using one called jad (http://kpdus.tripod.com/jad.html) to take a look at the ones included with the helpdesk package we use, in the hopes of figuring out what the privilege numbers meant.

It helped a bit -- and it was interesting to see what else was going on -- but in this particular case some trial and error turned out to be quicker :-)

You're absolutally right in that now, we could modify the class any which way we want.

Sure Don. You could do it a few ways. The quickest would probably be just to do a "getElementsByTag('FORM')", and loop over the results... you could test to see what attributes each has, and reset the attribute if it exists: if (element.autocomplete == "off") { element.autocomplete = "on"; }