Sunday, 10 May 2009

What is the point of client side security

Is hacking the DOM really hacking?

The nature of the browser is that its a client side tool. Pages stored on web servers are downloaded and viewed in your browser which stores all the files, images and scripts locally on your PC as temporary files. Therefore putting any kind of security on the client side is pointless as anyone with a small working knowledge of Internet technology can bypass them. I don't want to link to the site in particular but it appeared as a google advert on my site the other day claiming to protect your whole website from theft including your HTML source code. If you have a spare 30 minutes on your hands, have Firebug installed and did a search for code to protect HTML you would be able to bypass the majority of the wonderful security claims with ease.

Examples of such attempts to use client side code to protect code or content include:

Trying to protect the HTML source code from being viewed or stolen. This will include the original right mouse click event blocker. This was used in the old days in the vain hope that people didn't realise that they could just go to Tool > View Source instead of using the context menu. The other option was just to save the whole web page from the File menu. However you can now just view the whole generated source in most developer tools e.g Firebug.

Some sites will also generate their whole HTML source code with Javascript code in the first place. Packing, encoding and obfuscating it on the way. The code is then run through a function to evaluate it and write it to the DOM. Shame that this can all be viewed without much effort in the Scripts part of Firebug. And many tools let you run your scripts on any page e.g someone at work the other day didn't like the way news sites like the BBC always showed large monetary numbers as £10BN and added a regular expression into one of these tools to automatically change all occurrences to £10,000,000,000 as he thought the number looked bigger and more correct :) stupid example I know but anyhow.

Using special classes to prevent users from selecting content. This is commonly used on music lyric sites to prevent people copying and pasting the lyrics straight off. Shame Firebug lets you modify the DOM on the fly! Just find the class in question with the inspect tool, blank it out and there you go.

Multimedia sites that show content from TV shows that will remain unnamed but only allow users from the USA to view them. Using a proxy sometimes works but for those flash loaded videos that don't play through a proxy you can use YSlow to find the base URI that the movie is loaded from and just load that up directly. To be honest I think these companies have got wise to the fact that people will try this as they now insert location specific adverts into the movies which they never used to do. However its still better than moving to the states!

Sites that pack and obfuscate their Javascript in the hope of preventing users from stealing their code. Obviously minification is good practise for reducing file size but if you want to unpack some JS then you have a couple of options and there maybe some valid reasons other than just wanting to see the code being run e.g preventing XSS attacks.

Option 1 is to use my script unpacker form which lets you paste the packed code into a textarea hit a button and then hey presto you get the unpacked version in another textarea for you to use. It will also decode any encoded characters as well.

If you don't want to use my wonderful form and I have no idea why you wouldn't then Firefox comes to the rescue again. Copy the packed code, open the Javascript error console and paste the code into the input box at the top with the following added to the start of it:

//add to the beginning eval=alert;
eval=alert;eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('3(0,1){4(0===1){2("5 6")}7{2("8 9")}',10,10,'myvar1|myvar2|alert|function|if|well|done|else|not|bad'.split('|'),0,{}))

// unpacked returns
function(myvar1,myvar2){if(myvar1===myvar2){alert("well done")}else{alert("not bad")}




then hit evaluate and the unpacked code will open in an alert box which you can then copy from. What the code is doing is basically changing the meaning of the function eval to alert so that when the packed code runs within its eval statement instead of executing the evaluated code it will show it in the alert.

There are many more techniques which I won't go in to but the question then is why do people do it?

Well the main reason is that people spend a lot of time creating websites and they don't want some clever script kiddy or professional site ripper to come along steal their content and use it without permission.

People will also include whole sites nowadays within frames on their own sites or just rip the whole thing css, images, scripts and all with a click of a button from too many available tools to count. I have personally seen 2 sites now that I have either worked on or know the person who worked with appear up on the net under a different URL with the same design, images, JS code the lot apart from the wording was in Chinese .

The problem is that with every major browser now having developer tool sets like Firebug, IE8 developer toolbar, Operas dragonfly and Firebug-lite available for those without built in tools it seems pretty pointless trying to put any client side security on your sites at all. Even if you didn't want to be malicious and steal or inject anything you can still modify the DOM, run your own Javascript, change the CSS and remove x y and z.

All security measures related to user input should be handled on the server to prevent sql injection and XSS hacks but that's not to say that duplicating validation checks on the client isn't a good idea. For one thing it saves time if you can inform a user that they have inputted something incorrectly before the page is submitted. No one likes to fill in a long form submit it and wait whilst the slow network connection and bogged down server takes too long to respond only to show another page that says one of the following:
  • That user name is already in use please choose another one
  • Your email confirmation does not match
  • Your password is too short
  • You did not complete blah or blah
Things like this should be done client side if possible, using Ajax for checks that need database look ups such as user name availability tests.

However client side code that is purely there to prevent content from being accessed without consent seems pointless in the age of Firebug, IE Developer Tool bar, Dragonfly and all the other cool add-ons. Obviously there is a large percentage of web users out there that wouldn't know the first thing to do when it came to bypassing client side security code and the blocking of the context menu would seem like black magic to them but unfortunately for the people who are wanting to protect their client side code the people that do want to steal the content will have the skills to bypass all your client side cleverness. It may impress your boss and seem worth the $50 for about 10 minutes until someone shows you how you can add your own Javascript to a page to override any functions already there for blocking events and checking for iframe positioning.

My only question would be is it really hacking to modify the DOM to access or bypass certain features meant to keep the content on that page? I don't know what other people think about this but I would say no its not. The html, images, script and CSS are on my computer at the point of me viewing them on whatever browser I am using unless I am trying to change or inject anything onto the web or database server to affect future site visitors or trying to bypass challenge responses then I am not hacking the page.

I'd be interested to know what others think about that question?

Labels: , , , , , , ,

1 Comments:

At 10 May 2009 17:24 , Anonymous Anonymous said...

Yet another good article Rob. I'm with you on this and say that if you modify the DOM using Firebug or whatever then its fairplay. When you start trying to insert content for malicious purposes or try to bypass challenge/response mechanisms then it becomes hacking anything else is fair game.

 

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home