On Jun 12, 3:56 am, Gervase Markham <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Analyzed, no... but I agree that the Request-Source checks should only > > be made for non-safe methods. > Yes; I think the current write-up is confusing on this point.
I've updated the proposal to make this aspect a bit more clear: http://people.mozilla.org/~bsterne/site-security-policy/details.html > >> This means that all script has to be in external .js files. (This is one > >> of the differences in approach from Content-Restrictions.) While this is > >> an encouragement of best practice in JS authorship (unobtrusive script, > >> addition of event handlers using addEventListener() and so on) would > >> site authors find it too restrictive? One interesting proposal I have been sent via private email was from Amit Klein, who suggests potentially allowing authors to include a single, zero-parameter function within event-handling attributes, which could be defined in an external file. From his email: """ Perhaps you should allow something like a single parameter-less function invocation inside handlers, e.g. allow this: <img id="img123" onClick="onclickhandlerfoo()"> Obviously you can't allow parameterized functions, as this will open up security holes, e.g. eval("something bad") or innocent_function(123,eval("bad stuff here"),456) """ I really like this idea, as I think it lowers the barrier to entry to use Site Security Policy. I think (though don't have data to back this up) that there are a fair number of authors who would be comfortable moving their JS function definitions to external files, but wouldn't necessarily be comfortable attaching their own event listeners to DOM objects. This might be a great middle-ground solution. > >> - Can you more carefully define the relative priority and order of > >> application of allow and deny rules in e.g. Script-Source? I also updated the proposal to be more clear about relative rule priorities. > Have you thought about how much SSP applies to non-HTML (e.g. XML) > content? I tried to make Content Restrictions generalizable, at least in > principle, to other sorts of content which contained embedded script or > embedded documents. Yes, I think that SSP should generalize to other document types, certainly XML, that can contain active content. When I get a few moments, I will also make this more clear in the proposal. Thanks, Gerv, for the feedback, and I will keep you and the other participants in this discussion updated as we move toward creating an open standard (W3, WHATWG, etc.). Incidentally, I have been receiving some really great, detailed feedback from various security researchers (mostly private email at this point) and I hope to persuade them to join the standard-creating process. Cheers, Brandon _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
