Re: XSS mitigation in browsers

On 1/19/11 2:42 PM, Adam Barth wrote:
> Hi public-web-security,
> 
> I'm not sure if this the right forum for discussing new browser
> features that help mitigate cross-site scripting.  If not, please feel
> free to point me to a better forum.

This is exactly the right forum.  Content Security Policy is the
top-line deliverable listed in the Web Application Security WG proposed
charter.

> As I'm sure many of you are aware, various folks from Mozilla have
> proposed Content Security Policies
> <https://wiki.mozilla.org/Security/CSP> as a way of improving the
> security of web pages by including a security policy.  I'm interested
> two aspects of CSP:
> 
> 1) Cross-site scripting mitigation
> 2) Notification of policy violations

Just to be clear, as Mozilla's CSP proposal hasn't even been discussed
on this list yet and I want to make sure we miss that opportunity,
Mozilla is interested in each of the areas outlined in the proposal.
Apparently, the two areas that Adam is not interested in are:

3) Non-script resource loading
4) Framing restrictions

Since large amounts of thought and discussion have already been invested
in these areas outside of this mailing list, they should be part of the
discussion here to decide if they are worthwhile components of Content
Security Policy.

> The simplest design I could think of that achieves those goals is
> described on this wiki page:
> 
> https://trac.webkit.org/wiki/HTML%20Security%20Policy
> 
> The design is largely inspired by CSP, but different in a few ways:
> 
> 1) Instead of using HTTP headers, the policy is expressed in HTML.  Of
> course, authors will want to place the policy as early as possible in
> their document, so we're using a meta element, which can be placed in
> the head of the document.

I don't think the use of HTML tags instead of HTTP headers is
well-justified.  The obvious drawback to using <meta> tags is that the
whole model can be subverted by an attacker who manages to inject his
attack code or bogus policy tag above the site's legitimate policy tag.
 Mozilla considered the use of <meta> tags as an alternative to the
header, but we ultimately decided that the risk outlined above outweighs
the usability gained by allowing the policy to be expressed as a tag.

> 2) Instead of exposing policy levers for every kind of resource load,
> this proposal only lets the author control the source scripts.  This
> focus on scripts is motivated by wanting to prevent the attacker from
> injecting script into the page.

Providing strong controls around script loading is certainly the primary
focus of Content Security Policy.  But since we are already here
discussing the creation of a new security policy framework, perhaps it
would be beneficial to consider additional policy levers that can help
sites protect themselves moving forward.

I'm especially interested in future classes of attacks that we haven't
yet seen or considered which could potentially be mitigated by such
additional controls.  We can't now claim that these additional levers
will or won't mitigate the attacks, but if the marginal cost of
including them is low then we would do well to build them into the model
from the start.

It is true that the additional controls will lengthen any spec that this
group eventually produces, but they do not add any significant
complexity.  Both Mozilla's and Adam's proposals have already introduced
the concept of trusted domains for script.  This concept is easily
extended to other types of content.

Frame controls, included in Mozilla's CSP proposal as the
frame-ancestors directive, also seem to have value.  Microsoft would not
have introduced the X-Frame-Options header if there wasn't a valid use
case being addressed.  frame-ancestors offers some slight improvements
over X-Frame-Options by allowing for a list of trusted domains; a more
granular approach than the DENY or SAMEORIGIN options of X-F-O.

I will say, though, that neither CSP frame-ancestors nor X-F-O fully
address the clickjacking threat.  They are both improvements over
script-based framebusting, but they only allow sites to prevent their
framing.  We have no current solutions for sites that want to be framed
but don't want to be clickjacked [1].  This is an area I would love to
see this group delve into.

> 3) Instead of reporting violations to the server via HTTP, this
> proposal simply generates a DOM event in the document.  The author of
> the page can listen for the event and wire it up to whatever analytics
> the author uses for other kinds of events (e.g., mouse clicks).

Can you explain the motivation for this change?  If sites want to be
informed of the violations as they occur, won't they set up an event
handler which sends XHRs back to the server anyway?

> Let me know if you have any feedback on this proposal.  In general,
> I'm more interested in feedback that leads to simplification rather
> than feedback that leads to more complexity.

I agree that unjustified complexity should be avoided.  Additional
complexity may be warranted, however, if it leads to a more expressive
and, ultimately, useful model for websites.  Einstein famously said
"Make things as simple as possible, but not simpler."

Regards,
Brandon

[1] NoScript's ClearClick does attempt to address this problem
heuristically, though I'm sure Giorgio can attest to the inherent
challenges of that approach

Received on Thursday, 20 January 2011 21:48:20 UTC