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

I think it's worth taking a stab at adding this to 1.1.

To what extent would we want/need to specify the mechanical behavior of XSS
detection/protection? At the moment, I don't believe the header is
specified anywhere, so we won't have much to point off to.

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Fri, Nov 9, 2012 at 3:37 AM, Adam Barth <w3c@adambarth.com> wrote:

> 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
> >
> >
>
>