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

Thanks, this is good feedback.

I've dropped the quotes, and explicitly noted that the protections should
be enabled/disabled only for the protected resource.

--
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 Sat, Nov 17, 2012 at 7:24 PM, Adam Barth <w3c@adambarth.com> wrote:

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