W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2012

RE: [webappsec] subsume X-XSS-Protection into CSP 1.1?

From: Hill, Brad <bhill@paypal-inc.com>
Date: Thu, 8 Nov 2012 21:48:16 +0000
To: neil matatall <neil@matatall.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2E4AE2@DEN-EXDDA-S12.corp.ebay.com>
Thanks, just some ideas in response here, no shame intended:

I don’t think our goal is to eliminate as many X- headers as possible, but it’s a good thing to do where it makes logical sense to re-use the CSP mechanism.  Definitely agree it’s important to go through the thought process on this and not just throw everything we can think of into CSP.

X-XSS-Protection seems like a good possible choice because:

1)      it shares the problem domain of CSP

2)      a CSP that forbids unsafe-inline may be one of the few good reasons to disable such a mechanism

3)      it would potentially be useful to resource owners to be able to get reports from the reflected XSS filter if they allow unsafe-inline

We’re also looking at including frame-options under CSP for similar reasons – it is useful to re-use the policy delivery mechanism and syntax, reporting is a useful and desirable feature, and it whether and how to set it depends on its intersection with other directives in the UISafety spec.

X-Content-Type-Options is perhaps not so good a fit.  I guess it could be interpreted as specifying a least privilege policy to a resource, but it’s not clear to me there are any other synergies with the existing policy syntax or that there is any concept of a violation that would make the reporting features useful.

What do others think?

-Brad

From: neil matatall [mailto:neil@matatall.com]
Sent: Thursday, November 08, 2012 3:37 PM
To: public-webappsec@w3.org
Cc: public-webappsec@w3.org
Subject: Re: [webappsec] subsume X-XSS-Protection into CSP 1.1?

[first post to the list, likely don't have all context, shame away]

If accepted, how far do we take this idea?

What about 'X-Content-Type-Options' as well?
XFO - was that what the original 'frame-ancestors' was for?  This seems like more of a stretch.

These make logical sense to me at least, and would further reduce the number of X-headers.

- FNG


On Thursday, November 8, 2012 at 12:07 PM, Adam Barth wrote:
On Thu, Nov 8, 2012 at 12:01 PM, Hill, Brad <bhill@paypal-inc.com<mailto:bhill@paypal-inc.com>> wrote:
As I’m here at the IETF, reviewing the websec’s charter statement and
framework requirements, I note that one of the goals that drove the
formation of both our WGs was to reduce fragmentation and duplication of
security features and make it easier for resource owners to author policy
through a consolidated, extensible mechanism.

In that spirit, I wonder if another logical directive for CSP 1.1 might be
to incorporate the features currently provide by “X-XSS-Protection”. It
eliminates the need for another X- header, and seems like a logical fit.

Would there be any interest in this from implementers who currently manage
XSS filters in their browser?

Yes.

Adam

Received on Thursday, 8 November 2012 21:48:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 November 2012 21:48:45 GMT