4 ms·

This isn't really a language issue. This is strictly at the level of browsers having a very complicated and ad-hoc concept of permissions deciding when a page s

This isn't really a language issue. This is strictly at the level of browsers having a very complicated and ad-hoc concept of permissions deciding when a page should be allowed to make requests to, and to which, servers. We could have a richer permission model api exposed to whatever language we were using (so only certain white listed scripts tags would have the ability to make requests for example); but we don't. In any case, this is going to be at the DOM level, which isn't really part of javascript. Pages could have more control (via a header manifest or something) over tracking and permissioning based on where particular scripts come from; but that's not the model we went with. All scripts get put into a single executor and namespace. Now, this isn't an irrevocable choice, but a browser still has to support existing pages that would still be vulnerable to fun XSS attacks.

eridius 8y ago
It is a language issue, because the security hole is the fact that you can redefine the Array constructor or accessor methods. On a similar note, it's also crazy that you can't just use `foo instanceof Array` to figure out if something is an Array because it could be an Array from a different namespace, instead you need `Array.isArray(foo)`.
- deleted 8y ago
  [deleted]
- tptacek 8y ago
  That's not really a security hole except in the weird browser context of having to execute content-controlled code --- and then only due to the same-origin policy. Being able to redefine anything in the system is normally a virtue for a language.
  - rsj_hn 8y ago
    Being able to redefine everything is never a virtue as it introduces non-locality. You can't reason about what a particular piece of code is doing without understanding the full data flow that got you to this point and any re-definitions that might have happened along the way (with one re-definition overwriting the previous one). For example, look at the following code: function test(a) { if (a > 1) { console.log("bigger"); return; } else if (a <= 1) { console.log("smaller"); return; } else { console.log("Why is this happening to me?!"); } } var a = { x : 1, valueOf: function() { this.x -= 1; return this.x==0?1:2; } } test(a);
    - tptacek 8y ago
      I'm not looking to recapitulate the debate about whether monkey patching is good or not. It's probably bad most of the time. That doesn't make the possibility of doing it at all, ever, bad. If it helps you, just substitute "mainstream feature" for "virtue".
      - rsj_hn 8y ago
        There is a difference between being able to monkey patch * objects created in the same scope * objects created outside the current scope but global * global objects * core language features For anyone who has to read code someone else wrote, as you go down this list life becomes much more painful. Even something as simple as forcing all the patches to be in one place so there is an unambiguous place to look for them would make a huge difference.
        tptacek 8y ago
        Well, you can do those things in Ruby, you can do them in Javascript, you can even do them in Python. Is there a high-level "interpretable" language that takes a hard line on this, or is it just a standard we're retrofitting onto Javascript?
        rsj_hn 8y ago
        No, you cannot. In python you can certainly define your own object which might be a list and override the list accessor for your object, but you cannot override the general list accessor for all lists or those lists that you don't have a reference to. This is a big difference between a language like python and javascript. In javascript, buried deep in a function scope of some library might be code that overrides Function.prototype.apply, and then everywhere else in your code that a function is invoked, the new behavior will take effect. Nothing like that type of interference is possible in Python. In Python, you can only monkey patch those things that you have a reference for.
        8y ago
- deleted 8y ago
  [deleted]

eridius 8y ago

It is a language issue, because the security hole is the fact that you can redefine the Array constructor or accessor methods. On a similar note, it's also crazy that you can't just use `foo instanceof Array` to figure out if something is an Array because it could be an Array from a different namespace, instead you need `Array.isArray(foo)`.

deleted 8y ago
[deleted]
tptacek 8y ago
That's not really a security hole except in the weird browser context of having to execute content-controlled code --- and then only due to the same-origin policy. Being able to redefine anything in the system is normally a virtue for a language.
- rsj_hn 8y ago
  Being able to redefine everything is never a virtue as it introduces non-locality. You can't reason about what a particular piece of code is doing without understanding the full data flow that got you to this point and any re-definitions that might have happened along the way (with one re-definition overwriting the previous one). For example, look at the following code: function test(a) { if (a > 1) { console.log("bigger"); return; } else if (a <= 1) { console.log("smaller"); return; } else { console.log("Why is this happening to me?!"); } } var a = { x : 1, valueOf: function() { this.x -= 1; return this.x==0?1:2; } } test(a);
  - tptacek 8y ago
    I'm not looking to recapitulate the debate about whether monkey patching is good or not. It's probably bad most of the time. That doesn't make the possibility of doing it at all, ever, bad. If it helps you, just substitute "mainstream feature" for "virtue".
    - rsj_hn 8y ago
      There is a difference between being able to monkey patch * objects created in the same scope * objects created outside the current scope but global * global objects * core language features For anyone who has to read code someone else wrote, as you go down this list life becomes much more painful. Even something as simple as forcing all the patches to be in one place so there is an unambiguous place to look for them would make a huge difference.
      - tptacek 8y ago
        Well, you can do those things in Ruby, you can do them in Javascript, you can even do them in Python. Is there a high-level "interpretable" language that takes a hard line on this, or is it just a standard we're retrofitting onto Javascript?
        rsj_hn 8y ago
        No, you cannot. In python you can certainly define your own object which might be a list and override the list accessor for your object, but you cannot override the general list accessor for all lists or those lists that you don't have a reference to. This is a big difference between a language like python and javascript. In javascript, buried deep in a function scope of some library might be code that overrides Function.prototype.apply, and then everywhere else in your code that a function is invoked, the new behavior will take effect. Nothing like that type of interference is possible in Python. In Python, you can only monkey patch those things that you have a reference for.
        8y ago
deleted 8y ago
[deleted]