Gervase Markham wrote: > Your proposal is very interesting indeed. Some thoughts: > > - A 6-15% rendering speed decrease may not seem like much, but browser > makers generally consider that an enormous deal. A few years ago, > someone rewrote our entire style system for what I believe was a 5% > speedup. Content authors may feel differently, of course - and they get > to make the trade-off, depending on what method they use.
Yes, there is overhead (though, keep in mind that our measurements do not include network latency). Also, I don't think there's much improvement that you could squeeze out of our implementation, except that if you speed up the javascript engine our idea will benefit as well. Of course, you don't pay the price if the web site does not use our feature. > - The "DOM Sandboxing" policy style runs into the obvious problem with > such proposals - that of premature closure of the sandbox. While your > suggestion of writing all potentially-risky content using > document.write() is novel, I suspect that web authors would run > screaming from the idea. I'm not so sure, because you would typically use the sandbox only around third-party content. In a typical web app that means you are inserting some variable like $x in a template, it would not be much of a change to use something like wrap($x) instead, where the wrap function encapsulates our document.write idea. Consider that in many frameworks you can write a web app so that the source (of the app) looks quite nice, but when you do an actual "view source" in the browser the HTML is not so nice. That's what I think would happen here. Also, Brendan (and maybe others) have suggested elsewhere a sandboxing mechanism that is easier on the eyes (I assume that's the objection you are raising here): http://kathrin.dagstuhl.de/files/Materials/07/07091/07091.EichBrendan.Slides.pdf An advantage of our suggestion over that proposal is that it works in current browsers, i.e., that proposal would require more browser changes. Finally, consider the alternatives. I think whitelists/hashes or your scriptkey idea are probably less appealing to web app authors, unless they have automated help in their authoring tools. At any rate, they can choose to use whichever policy they like; I don't predict what they'll end up with, I just want to make my system flexible enough to accommodate it. Hopefully this experiment gives us some feedback. > - Have you investigated whether there's a possibility of race > conditions? I.e. while <script> tag A is running and setting up the > security function, script tag B has already begun to execute? As I > understand it, as long as neither "defer" nor "async" is specified on > the <script> tag for the monitor function you should be OK, but I > haven't done tests. I think there are not race conditions because javascript does not have concurrency. You browser developers will know better than me, though. I think if there are race conditions in my scheme, then there are race conditions in any web app that uses javascript. > - It would probably be possible, and perhaps be wise, to permit the > property containing the name of the monitor function to be set only once > per page, subsequent attempts triggering an exception. I'm sure it's possible but I suspect that it is not relevant for our current proposal. The danger of having it set more than once would presumably come from malicious code setting it the second time. Our scheme is predicated on the idea that the malicious code never gets to run at all, in other words, it is a very coarse-grained system. > - For external scripts, the function seems to get called on the script > URL (which is not actually "code") and not the script contents itself. > Why is that? A somewhat arbitrary decision --- we had to do one or the other. Practically speaking, for the browsers we modified this was the easier method to implement. We had also looked at ways of implementing our scheme without browser modification, e.g., by crawling the DOM and deleting things, and the script contents are not accessible through the DOM. But again, somewhat arbitrary and this could be changed. > - It might be good to change things a little to better match the naming > conventions and style of interaction used in the DOM. For example, to my > mind, instead of JSSecurity.afterParseHook, a more DOM-ish way of adding > the hook would be: > > document.addEventListener("scriptload", mySecurityFunction); Yes, and for example Opera user javascript has this sort of thing and it was perfect for implementing our scheme. We don't have any particular attachment to syntax, naming, etc. Practically speaking, we made the decision to use a distinguished variable rather than the event system because, looking ahead, we see that IE does not support that style of eventing and as far as I can tell they have no plans to do so. Therefore, the distinguished variable is potentially a cleaner solution cross-platform. > In fact, your proposal bears more similarities to "Script Keys": > http://www.gerv.net/security/script-keys/ > because it focusses on defining which scripts can run, not what they can > do when they do run. I agree; I only became aware of script keys a couple of days ago. > Your proposal has a superset of the Script Keys functionality. In fact, > using a mechanism similar to Script Keys might reduce the time overhead > the hashing suffered from. That would have the additional benefit of > giving the author more flexibility in script writing and removing the > need for your special hash creation tools, balanced against the > additional risk of not preventing any malicious code injection into the > approved scripts themselves. It could reduce overhead compared to hashes, but I think we have to try it and see the numbers. For example, instead of hashing we have also tried a literal string comparison and did not see noticeable improvement. > Comparing it to Content-Restrictions 0.9.2 (note: you cite 0.6 in your > paper; now that I'm getting cited, I may need to provide access to older > versions!), it could accommodate the "script" restriction, but not any > of the other four (host, script-host, cookies and hierarchy). So > arguably there is still a need for that, or something like it. Yes, we don't know what policies might be needed. Figuring that out should be part of the experiment. > Of course, the "script" restriction is arguably the most important one. > Certainly the Firefox 3 requirements document thinks so. Yes, and I agree. I'm not opposed to having the ability have finer grained policies that control what a script can do, but I observe that these are harder systems to build and harder to get multiple browser vendors to agree on. -Trevor _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
