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

On Sat, Nov 17, 2012 at 5:36 AM, Mike West <mkwst@google.com> wrote:
> 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.

I wouldn't bother quoting the keywords.  We only do that for the src
directives because we want to include URL-like syntax.  I would be
very surprised if we wanted to supply URLs in this directive in the
future.

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

Agreed.

> 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'".

<li>If the value of the directive is <code>'allow'</code>, the user
agent MUST disable its active protections against reflected cross-site
scripting attacks.</li>

You should be clear that the user agent ought to disable the XSS
filter for the protected document (rather than globally).  The
definition of filter has the same issue.

Adam


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

Received on Saturday, 17 November 2012 18:25:23 UTC