8 ms·

You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution p

You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (intentional is what is inside the control of the source code—an image decoding bug in the browser causing code execution is outside the scope here). A local deployment (with proper protection of the deployment) guarantees that an application remains static, and cannot be changed arbitrarily for malicious intent. Combined with a relatively easy inspection for intentional remote code execution, you can conclude that there is no direct way for the application to turn malicious. If you do not inspect the source, a local deployment still reduces the chance of a malicious modification being possible from "100% guaranteed" to "maybe, if the application is written in a specific way, or if there is an unintentional code execution bug somewhere in the browser". You will of course never be able to reduce the chance of any application turning malicious to 0 without full verification of the application and platform it runs on (including all other applications running with permissions to interfere).

tptacek 9y ago
I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post. I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.
- arghwhat 9y ago
  They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content." It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here. There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy. With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use). It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.
carussell 9y ago
Not to endorse the argument that a local app written in JS is inherently any more worrisome than one written for, say, .NET or GTK+ (because it's not), but this statement really sticks out: > It is relatively easy to find JavaScript execution points Have you ever been tasked with actually trying to guard against these things in security-critical situations? Because even with a deep understanding of the ECMA/W3C/WHATWG specs, years of experience with the arcane internals of a specific browser and JS engine, those engines' quirks wrt the way those specs are implemented, and the way they extend the specs, this was really tough even 5 years ago. The fact that JS is now an even faster moving target with yearly updates to the spec means that it's harder now. I don't think anyone who's worked on browsers would get behind the statement you made there.
- arghwhat 9y ago
  Yes, I have. The list is not very long, and it is comprehensive. At a previous place of employment, we implemented a full in-JS sandbox. The project was nasty, but as it hooked all JS execution, I do in fact have the fairly short list—what was not hooked would fail, so we were 100% sure that the list was comprehensive. Some of the entries do surprise slightly, mainly due to arcane APIs accepting both strings and function objects. New ECMAScript revisions didn't result in new execution points, although they did complicate the project in other ways. The project also means that I could whine for ages about browser engine quirks, terrible APIs, awful specs and the likes, and will absolutely never look positively on browsers ever again.
danenania 9y ago
A strict content security policy in an http-equiv meta tag is a much simpler and more effective way to accomplish this.
- arghwhat 9y ago
  That will break the app if it wasn't written for it. It doesn't change the argument, though. I'm arguing that it is relatively easy to deal with within the limits of what can be dealt with. If a strict content security policy can be applied, it just gets even easier.
  - danenania 9y ago
    I'd say that a csp is the only reasonable way to verify for a non-trivial app. A deep audit of every line of the app plus the whole dependency graph (that must be repeated on the diffs for every update) is not how I would define 'relatively easy'. And yes, I know it will break if not written for it--I'm saying that coding to fit a strict csp is the only way to have a verifiably secure js app. Without it, you're in the jungle.
    - arghwhat 9y ago
      I don't mind the CSP approach, I was just stating that with it, the app either works, or everything breaks. However, two things: 1. Nothing here requires a deep audit. Finding every execution point can be done with a bit of patience and "git grep". Some terrible frameworks, such as jQuery, can obscure things a bit, in which case knowledge of them speeds things up. 2. This may be a simple slip of words, but CSP does not in any way make your app verifiable secure. Coding towards a strict CSP is more about responsible coding and risk reduction/threat containment, by making foreign JavaScript execution non-trivial. There is nothing in a browser that lets you make something verifiably secure.
      - danenania 9y ago
        1 - Theoretically yes, but this is highly error prone and needs to be repeated on every update. Taking human factors into account, it's not a reliable strategy imho. 2 - My point isn't that a strict CSP makes the app magically secure, just that without it there's realistically no hope, and there's no point in wasting energy on trying to run a nontrivial app that doesn't have a strict CSP locally with the hope of getting around the security concerns of remotely hosted html/js. If you load a local html file with a strict CSP into Chrome with no extensions installed, that's actually a pretty darn secure execution environment. It's much easier to verify than a native app, for example, and it can do a lot less damage. Based on a single line at the top of the file, you can be certain that the app doesn't load remote js or css, doesn't use eval, only communicates with specific domains, etc. It isn't magic, but it can get you a long way and it does offer numerous clear, concrete benefits vs. a remotely hosted app.

tptacek 9y ago

I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post. I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.

arghwhat 9y ago
They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content." It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here. There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy. With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use). It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.

carussell 9y ago

Not to endorse the argument that a local app written in JS is inherently any more worrisome than one written for, say, .NET or GTK+ (because it's not), but this statement really sticks out: > It is relatively easy to find JavaScript execution points Have you ever been tasked with actually trying to guard against these things in security-critical situations? Because even with a deep understanding of the ECMA/W3C/WHATWG specs, years of experience with the arcane internals of a specific browser and JS engine, those engines' quirks wrt the way those specs are implemented, and the way they extend the specs, this was really tough even 5 years ago. The fact that JS is now an even faster moving target with yearly updates to the spec means that it's harder now. I don't think anyone who's worked on browsers would get behind the statement you made there.

arghwhat 9y ago
Yes, I have. The list is not very long, and it is comprehensive. At a previous place of employment, we implemented a full in-JS sandbox. The project was nasty, but as it hooked all JS execution, I do in fact have the fairly short list—what was not hooked would fail, so we were 100% sure that the list was comprehensive. Some of the entries do surprise slightly, mainly due to arcane APIs accepting both strings and function objects. New ECMAScript revisions didn't result in new execution points, although they did complicate the project in other ways. The project also means that I could whine for ages about browser engine quirks, terrible APIs, awful specs and the likes, and will absolutely never look positively on browsers ever again.

danenania 9y ago

A strict content security policy in an http-equiv meta tag is a much simpler and more effective way to accomplish this.

arghwhat 9y ago
That will break the app if it wasn't written for it. It doesn't change the argument, though. I'm arguing that it is relatively easy to deal with within the limits of what can be dealt with. If a strict content security policy can be applied, it just gets even easier.
- danenania 9y ago
  I'd say that a csp is the only reasonable way to verify for a non-trivial app. A deep audit of every line of the app plus the whole dependency graph (that must be repeated on the diffs for every update) is not how I would define 'relatively easy'. And yes, I know it will break if not written for it--I'm saying that coding to fit a strict csp is the only way to have a verifiably secure js app. Without it, you're in the jungle.
  - arghwhat 9y ago
    I don't mind the CSP approach, I was just stating that with it, the app either works, or everything breaks. However, two things: 1. Nothing here requires a deep audit. Finding every execution point can be done with a bit of patience and "git grep". Some terrible frameworks, such as jQuery, can obscure things a bit, in which case knowledge of them speeds things up. 2. This may be a simple slip of words, but CSP does not in any way make your app verifiable secure. Coding towards a strict CSP is more about responsible coding and risk reduction/threat containment, by making foreign JavaScript execution non-trivial. There is nothing in a browser that lets you make something verifiably secure.
    - danenania 9y ago
      1 - Theoretically yes, but this is highly error prone and needs to be repeated on every update. Taking human factors into account, it's not a reliable strategy imho. 2 - My point isn't that a strict CSP makes the app magically secure, just that without it there's realistically no hope, and there's no point in wasting energy on trying to run a nontrivial app that doesn't have a strict CSP locally with the hope of getting around the security concerns of remotely hosted html/js. If you load a local html file with a strict CSP into Chrome with no extensions installed, that's actually a pretty darn secure execution environment. It's much easier to verify than a native app, for example, and it can do a lot less damage. Based on a single line at the top of the file, you can be certain that the app doesn't load remote js or css, doesn't use eval, only communicates with specific domains, etc. It isn't magic, but it can get you a long way and it does offer numerous clear, concrete benefits vs. a remotely hosted app.