views:

336

answers:

4

Are there ways to prevent, or make it difficult enough, for someone to inject Javascript and manipulate the variables or access functions? A thought I had is to change all var names randomly on each reload so the malware script would need to be rewritten every time? Or are there other less painful ways?

I understand that eventually someone will hack his way in, but I'd like to know ways to make it difficult to reproduce the action, so that people won't publish a bookmarklet or something similar for everyone to use. I don't care if experts find their way in the code, but I'd like it to be a bit more complex than javascript:d=0;

If you know ways to make hacking Javascript a bit more difficult, please write those.

+18  A: 

Accept that your javascript will be "manipulated" and make provision at the server side. There's fundamentally nothing you can do to stop people tinkering with the client.

spender
Thanks, I was thinking of a way to make it difficult, it's not really vital to prevent manipulation, but I'd like to prevent at least someone posting a bookmarklet to 'do that cool thing' so everyone can hack. I don't really care if an expert finds eventually a way, but I'd like it to be difficult enough for noobs, and maybe hard to reproduce the action without using tools if that's possible.
stagas
I agree with @spender. The problem with your scenario is that the best you can do is security through obscurity. It will cost you a lot of time and effort and will never fully solve the problem, so you will always have to do it in the server side as well.
fms
I can't concur enough. Security through obscurity is a bad idea. You need to do server-side verification. Period.
g.d.d.c
-1 for not answering the actual question
Steve Elmer
+11  A: 

You can write your JS to use only private methods and variables in a self-executing function. For example, the following code leaves no sign of itself in the global namespace for anyone to monkey with.

(function(){
    var x = 1;
    var y = 2;
    var z = "A am z";
    var clickHandler = function() {
        alert('You clicked the body');
    };
    document.getElementsByTagName('body')[0].addEventListener('click',clickHandler,true);
}());

[EDIT] The above code is susceptible to a user overwriting any globally available objects, methods, events or properties you are using (in this case, document, getElementsByTagName and addEventListener), so if you are truly paranoid you can copy these to your function scope before the page has loaded and the user has a chance to overwrite them. Using addEventListener is a good idea because unlike the event body.onclick, it cannot be removed or overwritten from outside the function.

Andrew
That is useful thank you.
stagas
You have an error in the last line it should be `})();` I think
stagas
I used to write it that way until Crockford got into my head. Except for a missing semicolon (which I will add), the above code does validate according to JSLint;
Andrew
@Andrew: Hmm can you explain the difference of `}())` and `})()` I was aware of self-executing functions but I don't understand what you just did.
stagas
I honestly don't know what difference it makes except that Douglas Crockford says the invocation needs to be entirely inside. Knowing him, there is a very good, very arcane reason. I only know this because my JSLint validator kicks up two warnings when I have the invocation parenthesize outside. The warnings are: `Move the invocation into the parens that contain the function.` and `Wrap the entire immediate function invocation in parens.` Well, I was tired of JSLint hurting my feelings so now I do what it says. We're both happier that way.
Andrew
@stagas - Now that I've looked around, it seems that it is an issue purely of style. The top answer by @altCognito on [this SO thread](http://stackoverflow.com/questions/939386/javascript-immediate-function-invocation-syntax) points to Crockford's own explanation. Basically, the parenthesize around the function either draws attention to the unexecuted function or the result of it and Crockford thinks it should point to the result. So, basically, it's splitting hairs.
Andrew
@Andrew: Heh have you seen http://fabjs.org Now that's stylish code!
stagas
@stagas - That's spats-and-a-top-hat stylish. The only thing that matters to me is readability and thankfully there are lots of ways to write clear, understandable code. Fab code is *very* clear (though I hate it when I have to jump back and forth between 20 1-kilobyte files to follow what is happening in the code). I use most of Crockford's style because I program alone and JSLint really, really helps me catch stupid mistakes, typos, variables I've let escape into the global namespace. I actually disagree with a lot of his style and pedantics, but he's helped me grow more than anyone else.
Andrew
+1 for being the only person to actually answer stagas's question.
Steve Elmer
One extra layer of security is to pass in the document, window, body and undefined variables to your JS, so they are local to the function. `(function(document, window, undefined){ [...]})(document,window);`
Aaron Harun
A: 

Obfuscation and minification should make it a good bit more difficult to hack, but I agree with spender.

JoshNaro
A: 

Any user that will really want to tamper with the client will be able to. The code is on his machine. Even if you obfuscate the client side code, there are tools out their that will help someone un-obfuscate the code back in a second.

What you need to think about though is making the site safe on the server, and safe for other users as well. This means (as a minimum) :

  1. Chacking/Validating every request and input parameters on the server so Users won't be able to alter any server side data by triggering 'hacked' client side functions you wrote.

  2. Check all data that you output to the screen that was originated from user input. Other users might have inserted client side scripts that are dangerous for your site, and especially dangerous to the other users on your site. (If you're using .net then check out the AntiXSS library)

gillyb