On Tue, Oct 20, 2009 at 1:26 PM, Mike Ter Louw <mter...@uic.edu> wrote: > I'm not sure if hacking at the straw man should occur on the list or on the > wiki. Please let me know if it should go to the wiki.
I've be inclined to discuss feedback on the mailing list where others can see and comment most easily. > Threat Model: > > "We further assume the web developer wishes to prevent the attacker from > achieving any of the following goals: > > * The attacker must not learn the contents of the target web site's > cookies." > > A broader definition than cookie stealing that also covers integrity issues > like defacement could be: > > * The attacker's sequence of injected bytes are interpreted as one or more > script instructions and executed with the privileges of the (CSP-protected) > document. I tried to tighten down the attacker's goals to keep a narrow focus for the module. Running script with the page's privileges seems more like a means to an end rather than a goal unto itself. Although you could argue that stealing the cookie is also just a means to a different end. Either is probably fine, but I'm inclined to leave it as is for now. > If the purpose of the threat model is to scope out the protections afforded > by the module, then the following may be more appropriate: > > * The attacker's sequence of injected bytes are interpreted as an inline > script (i.e., <script> element without |src| attribute, script element > attribute, javascript: URI, dynamic CSS, etc.) > > * The attacker's sequence of injected bytes are interpreted as a reference > to external script, where the external script is located at a different > origin to the document protected by CSP > > * The attacker's sequence of injected bytes are compiled as a result of > executing an allowed script (e.g., via eval(), setTimeout(), setInterval(), > or Function constructor) These are too syntactic for an attacker goal. They pre-suppose a particular solution. > block-xss directive: > > The effects of this directive are given in a default-allow style, which > could lead to gaps in protection. (Some possible gaps are commented on in > the Open Issues section.) Could the effects of block-xss be specified as > exceptions to a default-deny policy? This is a good point. I wrote this as a series of MUST NOT requirements to make it easy to implement and test. We should do a better job of explaining the "why" behind the requirements. If we've missed anything, we should add more requirements to make sure each implementation behaves correctly. Maybe we should add a catch-all MUST NOT requirement that covers anything we've forgotten? > Open Issues section: > > IE's CSS behaviors and expressions could fit in the same category as XBL > bindings, as they are non-standard features that can be used as XSS vectors I've added this to the list of open issues. The catch-all MUST NOT might be sufficient to get these. We can of course mention them in a non-normative note to remind implementors. Thanks! Adam _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
