Trevor Jim wrote: > 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.
Fair point. > 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. But possibly that's not something we want to encourage :-) > 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 > Note to readers: Brendan proposed <jail hash="34af56..."> -- untrusted content here -- </jail hash="34af56..."> That's sort of like script-keys, except that you label the jail with the string the attacker can't know, rather than the script. >> - 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. But making it impossible to set it twice adds defence in depth with very little downside. One can imagine exploits, for certain types of policies, where you can run some simple scripts but not others - but the simple script might be enough to replace the policy engine with "return true;". >> - 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. I actually think it's a better idea. After all, URL parsing is well understood, and you can check the domain to see if the script is coming from somewhere you trust. This is much easier than taking the hit of doing a SHA1SUM of the entirety of Dojo. But you'd need to change the name of the "code" parameter, or perhaps have two parameters, exactly one of which is ever non-null. Having two different types of thing in the same parameter isn't good security. > 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. Well, they have attachEvent, and there's cross-browser compatibility libraries to do the simple fork. But do you actually have any way to make this happen in IE at all? If not, then they'll have to implement it themselves, and can do whatever syntax we pick. >> 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!), Done, BTW. Links at the top to older versions. Gerv _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
