- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 12 Nov 2012 16:45:40 -0800
- To: Mike West <mkwst@google.com>
- Cc: "Hill, Brad" <bhill@paypal-inc.com>, neil matatall <neil@matatall.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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