16

Consider this pseudo code:

(function(window){
   var options = { /*where everything goes */ };

   var instance = (function(options){
       for (var i in options){
       if (options.hasOwnProperty(i)){
         this[i] = options[i];
       }
     }
   })(options);

   instance.callbacks = function(cb){
     //...
   }

   instance.is_allowed = function()
    //... checks, return boolean
   }

   window.instance = instance;
})(this);

If anyone ever wanted to manipulate this code (a malicious user for example), he would rewrite the is_allowed function with his own, for example, using the address bar (he doesn't have firebug, who knows). 

javascript:(function(){ window.instance.is_allowed = function(){ return true; } })();

This is a naive example, but that's the point, anything in Javascript can be overwritten.

I know in es5 we have the Object.defineProperty so you can set:

// being explicit
Object.defineProperty(instance, "is_allowed", {
  enumerable: false,
  configurable: false,
  writable: false,
  value: function(){
    // do checks
  }    
});

Actually, what is BEST in this sense is to use Object.freeze(instance) or Object.seal(instance) instead of Object.defineProperty, since the later can be called again with writable: false (silly huh?)

Is there ANY way that it work in old browsers (namely IE6-8) without too much hassle? If it's impossible, then I'll just shrug and move on.

pocesar
  • 6,860
  • 6
  • 56
  • 88
  • 12
    If your application relies on the integrity of JavaScript code that runs on the client's machine, then that's your actual problem. You shouldn't care about what happens there, just make sure that you sent out only what the client is allowed to see and validate and sanitize everything that comes in. – Niko Feb 03 '13 at 10:10
  • and what about AJAX that can be manipulated (thinking another scenario other than validation). It's not actually MY application, it's a library that runs on other peoples projects btw – pocesar Feb 03 '13 at 10:14
  • Maybe you could think to improve your code with some shim to support cross-browser ES5 Object capabilities. Take a look at http://stackoverflow.com/questions/8221757/polyfill-or-workarounds-for-ecmascript5-new-features – Ragnarokkr Feb 03 '13 at 10:15
  • well I guess I'll just check for `Object.defineProperties` and freeze my whole singleton when the API is available... – pocesar Feb 03 '13 at 10:20
  • 1
    Also available: [`Object.freeze`](https://developer.mozilla.org/en/docs/JavaScript/Reference/Global_Objects/Object/freeze). – Felix Kling Feb 03 '13 at 10:34
  • yeah, Object.freeze is the way to go. I can just care less about old ie anyway I guess – pocesar Feb 03 '13 at 10:36
  • the sad part is that the object CAN be 'unfrozen'. that's just Javascript nature, I can't try to force it be something it isn't http://mohsenweb.com/unfreeze-a-javascript-object/ (at the bottom) – pocesar Feb 03 '13 at 10:43
  • 2
    @Niko is correct. DO NOT WORRY about a "malicious" programmer overriding that. If he wants to be malicious, nothing will stop him from sending an improper request to the server, no matter what Javascript you use. – Paul Draper Feb 03 '13 at 21:20
  • They could just write a completely different application that starts posting crap to your server. Protecting this object (if you could) doesn't protect you from that. Protect your server. – GolezTrol Feb 04 '13 at 08:10

3 Answers3

2

Proposal

I won't say I'm an expert on these things. But assuming you can wrap your code completely and use events to trigger behavior you can use a structure like this:

Closed = function(args) { return (function() {
  "use strict";

  var secret, init, get_secret, use_secret;

  init = function(something){
    secret = something;
  };

  get_secret = function() {
    return secret;
  };

  use_secret = function () {
    console.log(secret);
  };

  /* Run constructor */
  init(args);

  /* Publish API */
  return { use_secret:use_secret };

}())};

Setting it up with obj = Closed("Anything"); you can still have a malicious user overwrite the use_secret() method, since it's exposed, but the get_secret() method, and any other internals, are protected.

If your init method declares a number of event bindings to the application you can keep your state private in this way. The events will be able to trigger internal methods since they where bound from inside the inner closure but external code won't see them.

Reservations

While this might solve your problem, I'm not 100% sure it does, it's not to be trusted anyway. Any user that want to penetrate your application can as long as the security is on the client side. There is nothing to stop them from crafting their own object to replace yours after the fact anyway, ES5 or no ES5.

For anything that actually needs to be secure you will have to revalidate on the server side. Never trust client side code to protect you, the request might not even come from the page you served ...

Jonas Schubert Erlandsson
  • 3,910
  • 1
  • 24
  • 37
  • that's roughly what I'm doing at the moment... I just want to avoid with everything I have currently, any tampering on the jquery plugin i'm the author of, just that, because I won't know who and how people will use it, so I want to keep it 'tamper-proof', so at least my job was done – pocesar Feb 04 '13 at 02:09
2

If anyone ever wanted to manipulate this code (a malicious user for example), he would rewrite the is_allowed function with his own

He could rewrite your whole javascript code or not even use a browser but simulate a "browser-less" request to your server.

Is there ANY way that it work in old browsers (namely IE6-8) without too much hassle?

No. Anything you globally expose can be altered by the user, it is up to the browsers restrict the javascript: behavior to avoid users from being fooled to access pre-crafted links. Firefox recently have made some kind of change to the javascript URL protocol.

As said on this article: http://survey-remover.com/blog/javascript-protocol-dangers/

As of Chrome v13, Firefox v6 and IE 9, the browser developers have taken notice to the dangers of the "javascript:" protocol and have subsequently disallowed code ... In the case of Chrome and IE, the "javascript:" substring is stripped when the code is pasted, whereas Firefox no longer executes the script within the scope of the active page.

So...

If it's impossible, then I'll just shrug and move on.

You should.

Fagner Brack
  • 2,365
  • 4
  • 33
  • 69
0

What if is_allowed would be completely local?

(function(window){
   var options = {}, is_allowed;

   var instance = (function(options){
     for (var i in options) {
     if (options.hasOwnProperty(i)) {
        this[i] = options[i];
       }
     }
     return this;
   })(options);

   instance.callbacks = function(cb){
       /* ... */
   };

   function check_allowed(){
     /* check and let this function set [is_allowed] */
   };

  window.instance = check_allowed()
                     ? instance
                     : { callbacks: function(){(alert('not allowed'));}  };

} (this) );

jsBin mockup

BTW: in your code, window.instance would be undefined.

KooiInc
  • 119,216
  • 31
  • 141
  • 177