Trevor Jim wrote:
> http://www.research.att.com/~trevor/beep.html
>
> Briefly, we modify browsers so that a web site can write a security
> policy on what scripts will be allowed to run in the browser. The
> policy takes the form of a JavaScript function that is simply embedded
> in a web page like any other script. The browser will execute the
> policy before executing any other scripts in the page, essentially
> consulting the policy on whether to execute the other scripts.
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.
- 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.
- 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.
- 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.
- 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?
- 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);
> I'm aware that there may be ongoing work to add a different mechanism
> to firefox to protect against script injection, the "content
> restrictions"
> proposal:
>
> http://groups.google.com/group/mozilla.dev.security/browse_frm/
> thread/d7a2adf3511cc1f1/90aa822a4fc4921b#90aa822a4fc4921b
>
> In comparison to that proposal, an advantage of our proposal is that
> it is very general (the policy provided by the web site can be anything
> written in JavaScript) whereas my impression of content restrictions is
> that the policies that can be enforced are more baked-in or hard-coded.
> Therefore, I hope that our proposal is flexible enough to support policies
> and scenarios which may become necessary in the future.
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.
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.
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.
Of course, the "script" restriction is arguably the most important one.
Certainly the Firefox 3 requirements document thinks so.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
