1

I have a html like this that I deliver to the client from my web server

<html>
<head>
    <script type="text/javascript">
        var myapp = myapp || {};
        myapp.settings = {"abc", "xyz", "123"};
    </script>
</head>
</html>

In the rest of my client app, I have checks that look at the myapp.settings object.

Is myapp.settings secure? Can a hacker add strings or remove strings from myapp.settings? If so, what are some example ways to do so?

govin
  • 6,445
  • 5
  • 43
  • 56
  • 1
    This is not valid JavaScript code. If it's an array, it should use square brackets instead (`[` and `]`), and if it's an object, if should have some values. – Michał Perłakowski Nov 02 '16 at 22:23
  • 2
    What do you expect the worse result of manipulating the settings would be? Because for client-side stuff, I'd expects something called "app settings" to, generally, be completely harmless even if "hacked". At most, I'd imagine the "attacker" might be able to control the view in a way you didn't intend, like laying stuff out in a different order or increasing pagination size or something like that. If there is that should be kept _secret_, it shouldn't be there. If this controls something that can overload the server (max request size, etc), then the server should also restrict it. – VLAZ Nov 02 '16 at 22:35

3 Answers3

4

No, it is not secure.

Yes, a user can manipulate the state of your myapp.settings object rather easily.

Travis J
  • 81,153
  • 41
  • 202
  • 273
  • thanks, can you show me some examples on how it can be manipulated? – govin Nov 02 '16 at 22:20
  • 2
    There is a sort of caveat here, only the actual user can manipulate these objects. It would be very difficult for me for example to manipulate another user's myapp.settings object. Manipulation is as easy as simply accessing the object from the browser console. More advanced versions of access for closed over variables require setting breakpoints but are still viable ways of changing state. – Travis J Nov 02 '16 at 22:21
  • I guess I could use Object.freeze() as pointed out by another user and make it secure or unmodifiable? – govin Nov 02 '16 at 22:25
  • 1
    It isn't really ever going to be secure. Just count on it being attacked, and verify anything sensitive on the server side that what happened with the client interaction was authorized and verified. – Travis J Nov 02 '16 at 22:28
4

No, it is not secure. In fact, nothing in a web page is completely secure.

In your particular example, here are some examples for how your myapp object can be manipulated:

  1. The end-user can open the browser console and type in a line of code to change that object.

  2. The end-user can open the browser debugger, set a breakpoint and when it hits that breakpoint, edit that object.

  3. The end-user can download or create a bookmarklet that when clicked on would modify the myapp object.

  4. The end-user can set up a proxy that intercepts the incoming page, modifies it and then sends it on to the browser.

  5. An attacker can intercept the page on its way to you and modify it (as it goes through your ISP for example). Note: this would be much less likely if you were using https.

Because nothing in the browser is completely secure, security issues have to be addressed with a specific need in mind and then options are explored to handle those specific concerns.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
1

As long as someone can execute a script in that app, they can modify myapp.settings. However, you can prevent this by using Object.freeze() function on it:

Object.freeze(myapp.settings);
myapp.settings.test = 42;
console.log(myapp.settings.test); // undefined
Michał Perłakowski
  • 88,409
  • 26
  • 156
  • 177
  • Setting a breakpoint on the line of code with the freeze will allow interaction with the myapp.settings object in this scenario. – Travis J Nov 02 '16 at 22:23
  • thanks, will Object.freeze() prevent it from being manipulated from the browser console as well? – govin Nov 02 '16 at 22:25
  • @TravisJ I'm assuming that this "hacker" can't modify scripts that already exist in this app. If they can, there's nothing you can do to stop them. – Michał Perłakowski Nov 02 '16 at 22:25
  • 1
    Once a script is loaded, then sure, it is in place and it would be a little crazy to go backwards. However, often going backwards in loading is as simple as `F5`. Any loading script can be modified prior to execution using breakpoints. Scripts are not secure, this is why security needs to be enforced on the server side, and not the client side. – Travis J Nov 02 '16 at 22:27
  • 2
    @govin Yes, but there are other ways to manipulate JavaScript code from browser console (for example setting breakpoints, like Travis J pointed out), so client-side JavaScript code can't really be secure. – Michał Perłakowski Nov 02 '16 at 22:28
  • @TravisJ Don't we have any canonical question explaining the security (or rather lack of it) of client-side JavaScript code (something like [vlaz's comment](http://stackoverflow.com/questions/40390753/is-js-object-within-a-script-tag-secure#comment68033610_40390753) and [jfriend00's answer](http://stackoverflow.com/a/40391133/3853934))?. – Michał Perłakowski Nov 02 '16 at 23:03
  • Not that I am aware of. I think this question was a fair question to ask. There are some related ones though, such as http://stackoverflow.com/q/21692646/1026459, http://stackoverflow.com/q/549/1026459, and http://stackoverflow.com/q/162159/1026459 – Travis J Nov 02 '16 at 23:16