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

On Mon, Nov 12, 2012 at 3:38 AM, Mike West <mkwst@google.com> wrote:
> 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?

I don't think we want to go down that rabbit hole.  We can just say
that it enables/disables any heuristic reflective XSS filters that the
user agent might support.

Adam


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

Received on Tuesday, 13 November 2012 00:46:43 UTC