Straw-main XSSModule for CSP
Adam Barth
On Friday, I spoke with Sid, Brandon, and dveditz about dividing the
Content Security Policy specification into modules targeted at
specific threats. This approach as two main benefits:
1) Different browser vendors can implement CSP incrementally by
deploying the most important modules first.
2) A modular approach gives us more flexibility if we wish to target
other threats in the future.
I've taken the liberty of sketching out a straw-man XSSModule for CSP
on the Mozilla wiki:
https://wiki.mozilla.org/Security/CSP/XSSModule
The XSSModule defines a forwards-compatible syntax for the
X-Content-Security-Policy header and defines three directives useful
for mitigating XSS vulnerabilities: (1) block-xss, (2) block-eval, and
(3) script-src. In the common case, a web site can mitigate XSS
vulnerabilities by including the following content security policy:
X-Content-Security-Policy: block-xss
The block-eval directive lets the site further mitigate DOM-based XSS
attacks by blocking "eval-like" constructs. The script-src directive
provides for finer-grained control over loading external scripts in
case the web site loads scripts from other origins.
In principle, we could factor a BaseModule out of the XSSModule that
defines the general syntax of the header and the semantics of
origin-lists, but I've created a single document for clarity. I've
omitted a number of features from the main CSP specification (and
changed some details to improve extensibility), but we can add those
features in separate modules. For example, we could define a
ReportingModule that contains the reporting machinery.
I welcome your feedback,
Adam
Mike Ter Louw
> I've taken the liberty of sketching out a straw-man XSSModule for CSP
> on the Mozilla wiki:
>
> https://wiki.mozilla.org/Security/CSP/XSSModule
>
> Adam
Hi Adam,
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.
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.
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)
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?
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
Mike
Adam Barth
> 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