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

On Thu, Nov 8, 2012 at 1:48 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
> 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?

Yeah, X-XSS-Protection is more likely to be used in combination with
the existing CSP directives.  There are also use cases for getting
violation reports when the XSS filter fires (especially when in
"block" mode).  We're experimenting with generating a CSP-like report
for X-XSS-Protection, but it would be better to unify these
mechanisms.

Adam


> 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> 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 Friday, 9 November 2012 02:38:56 UTC