Intent to Deprecate and Remove: The `reflected-xss` CSP directive.

549 weergaven
Naar het eerste ongelezen bericht

Mike West

ongelezen,
20 okt 2016, 05:14:0120-10-2016
aan blink-dev
# Eng

# Summary
Early drafts of CSP2 contained a `reflected-xss` directive, which is little more than syntactic sugar for the `X-XSS-Protection` header. It offered no additional functionality beyond that header, just a better syntax. I shipped our implementation as part of shipping CSP2 (https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/wToP6b04zVE/imuPatGy3awJ). I should have undone that in 2015 when we dropped the directive from the CR draft. I'd like to undo it now.

# Motivation
We removed the directive from the spec. No other browser is going to ship the directive. We should stop shipping it too, as it complicates our implementation and could confuse developers.

# Compatibility Risk
1. No other browser ships this directive or plans to do so. Removing it will align our behavior with the rest of the web.

2. This feature replicated functionality in `X-XSS-Protection`, which other browsers do support. We never dropped support for that directive, which means that developers who wanted to change the XSS Auditor's behavior in Safari, Opera, IE, or Edge would have needed to send that header as well.

3. The major risk is that a developer who wished to disable the XSS Auditor does so only via this directive, and not via `X-XSS-Protection`, meaning that they get opted back into filtering mode, which might make their application vulnerable to some attack vectors. I think this is quite unlikely on its face due to the lack of browser support for the directive (https://www.openfuture.org/ is the only page in httparchive that is in this situation), and is further mitigated by the fact that we'll be flipping our default from filter to block in the very near future.

# Alternatives
`X-XSS-Protection`.

# Usage Information
We don't have a metric for this in particular. 

# Tracking bug

# Feature Dashboard

# Requesting approval to remove?
Yes.

-mike

Jochen Eisinger

ongelezen,
20 okt 2016, 05:14:5820-10-2016
aan Mike West, blink-dev
lgtm1

Philip Jägenstedt

ongelezen,
20 okt 2016, 05:24:3520-10-2016
aan Jochen Eisinger, Mike West, blink-dev
lgtm2

Have you tried reaching out to openfuture.org?

As for deprecation, it would be nice if either any unknown directives result in a console message, or if this had a specific message explaining to use X-XSS-Protection instead, whichever is easier to implement.

Mike West

ongelezen,
20 okt 2016, 05:30:2520-10-2016
aan Philip Jägenstedt, Jochen Eisinger, blink-dev
On Thu, Oct 20, 2016 at 11:24 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
Have you tried reaching out to openfuture.org?

 
As for deprecation, it would be nice if either any unknown directives result in a console message, or if this had a specific message explaining to use X-XSS-Protection instead, whichever is easier to implement.

We already send a warning to the console for unrecognized directives, something like "Unrecognized Content-Security-Policy directive 'whatever'."
 
-mike

Philip Jägenstedt

ongelezen,
20 okt 2016, 05:41:5720-10-2016
aan Mike West, Jochen Eisinger, blink-dev
Ah, well that's great. Now if people search for that they'll probably end up in this thread, and figure out that they should use X-XSS-Protection, as intended.

Chris Harrelson

ongelezen,
20 okt 2016, 13:03:0620-10-2016
aan Philip Jägenstedt, Mike West, Jochen Eisinger, blink-dev
LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten