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

https://dvcs.w3.org/hg/content-security-policy/rev/a33c0305a6bf is an
initial stab at language for this new directive. It's not much more than a
strawman for discussion, so let's go:

1. It behaves similarly to 'sandbox', in that we're really setting modes
for the document, rather than limiting sources of resources. Sandbox,
however, doesn't quote the keywords. I'd originally thought that we should
simply quote all keywords for consistency, but since it's not a source
list, there's really no need. Hrm.

2. I considered folding it into 'script-src' (e.g. 'reflected' might be a
valid source of script?), but couldn't come up with a good syntax for
blocking-mode. A separate directive seems saner.

3. 'reflected-xss' seems better than 'reflected-xss-protection', as the
keywords can then refer to the script itself, rather than the protection.
"reflected-xss 'allow'" sounds better to me than 'reflected-xss-protection
'disable'".

WDYT?

--
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 Tue, Nov 13, 2012 at 12:40 PM, Mike West <mike@mikewest.org> wrote:

> Sounds reasonable. I'll take a stab at adding it to the 1.1 draft shortly.
> On Nov 13, 2012 1:47 AM, "Adam Barth" <w3c@adambarth.com> wrote:
>
>> 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
>> >> >
>> >> >
>> >>
>> >
>>
>>