Intent to Ship: XSS Auditor violation report MIME type change.

[Mike West]

Contact emails mk...@chromium.org,tse...@chromium.org Spec

https://bugs.webkit.org/show_bug.cgi?format=multiple&id=100892
(Yes. We should absolutely write this down somewhere other than a 5-year old bug on WebKit's tracker. And in The Glorous But ~Distant Future, we'll want to align this with https://wicg.github.io/reporting/. This feature is basically under-loved and under-specified.)

Summary The XSS Auditor's violation reports are now sent with a MIME type of `application/xss-auditor-report` (as opposed to `application/json` which we're sending in the status quo).

Motivation

It's a bad idea to give folks the ability to send `application/json` requests cross-origin to arbitrary endpoints without CORS enforcement. While there's no concrete attack we've seen based on this capability, and the risk is mitigated by the fact that the browser remains in control of the JSON payload delivered, it's advisable to change to a less overloaded MIME type that gives server operators the ability to filter their incoming traffic in a reasonable way. Interoperability risk Firefox: No XSS Auditor

Edge: No reporting functionality in their XSS Auditor

Safari: No public signals, filed: 

Web developers: No signals Compatibility risk

Low.

Safari is the only other browser shipping this functionality, and it's basically unknown. Neither Google nor Facebook (which account for most `X-XSS-Protection` usage) use the feature, and `report-uri.io` didn't know about it until they heard that the MIME type was changing. :/

Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes. OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=691726 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6227193935953920 Requesting approval to ship? Yes. *cough* I've actually already landed this in https://codereview.chromium.org/2717463006. It should have occurred to me to send an I2S, regardless of the feature's quasi-proprietary nature. :(

-mike

[Domenic Denicola]

From: mk...@google.com [mailto:mk...@google.com] On Behalf Of Mike West

> It's a bad idea to give folks the ability to send `application/json` requests cross-origin to arbitrary endpoints without CORS enforcement. While there's no concrete attack we've seen based on this capability, and the risk is mitigated by the fact that the browser remains in control of the JSON payload delivered, it's advisable to change to a less overloaded MIME type that gives server operators the ability to filter their incoming traffic in a reasonable way.

Has there been any consideration given to requiring CORS for such cross-origin reports?

[TAMURA, Kent]

LGTM1.

Though this intent doesn't have UseCounter data, the number of affected page views must be very low.

On Thu, Mar 2, 2017 at 6:57 PM, Mike West <mk...@chromium.org> wrote:

Contact emails mk...@chromium.org,tsepez@chromium.org Spec

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

Ping Mike on Domenic's CORS question.

On Tue, Mar 7, 2017 at 1:09 PM TAMURA, Kent <tk...@chromium.org> wrote:

LGTM1.

Though this intent doesn't have UseCounter data, the number of affected page views must be very low.

On Thu, Mar 2, 2017 at 6:57 PM, Mike West <mk...@chromium.org> wrote:

Contact emails mk...@chromium.org,tse...@chromium.org Spec

[Mike West]

Sorry, I missed Domenic's question. Thanks for the ping!

Going forward, I intend to fold this reporting mechanism (and CSP's, which has similar properties (and Network Error Logging (and HPKP (and `Expect-CT` (and etc.)))) into https://wicg.github.io/reporting/, and by doing so give ourselves an opportunity to rework things in a more sane way. You'll note that that mechanism does indeed intend to make CORS-enabled fetches (see https://wicg.github.io/reporting/#try-delivery).

Changing the MIME type to mitigate the (low) risk of a server looking for JSON seems like a reasonable thing to do, but changing the mechanism more fundamentally is something I'd like to do wholesale by introducing an improved reporting mechanism, rather than transitioning each mechanism individually, and then introducing a new thing on top of it.

-mike

On Tue, Mar 7, 2017 at 5:29 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Ping Mike on Domenic's CORS question.

On Tue, Mar 7, 2017 at 1:09 PM TAMURA, Kent <tk...@chromium.org> wrote:

LGTM1.

Though this intent doesn't have UseCounter data, the number of affected page views must be very low.

On Thu, Mar 2, 2017 at 6:57 PM, Mike West <mk...@chromium.org> wrote:

Contact emails mk...@chromium.org,tsepez@chromium.org Spec

https://bugs.webkit.org/show_bug.cgi?format=multiple&id=100892
(Yes. We should absolutely write this down somewhere other than a 5-year old bug on WebKit's tracker. And in The Glorous But ~Distant Future, we'll want to align this with https://wicg.github.io/reporting/. This feature is basically under-loved and under-specified.)

Summary The XSS Auditor's violation reports are now sent with a MIME type of `application/xss-auditor-report` (as opposed to `application/json` which we're sending in the status quo).

Motivation

It's a bad idea to give folks the ability to send `application/json` requests cross-origin to arbitrary endpoints without CORS enforcement. While there's no concrete attack we've seen based on this capability, and the risk is mitigated by the fact that the browser remains in control of the JSON payload delivered, it's advisable to change to a less overloaded MIME type that gives server operators the ability to filter their incoming traffic in a reasonable way. Interoperability risk Firefox: No XSS Auditor

Edge: No reporting functionality in their XSS Auditor

Safari: No public signals, filed: 

Web developers: No signals Compatibility risk

Low.

Safari is the only other browser shipping this functionality, and it's basically unknown. Neither Google nor Facebook (which account for most `X-XSS-Protection` usage) use the feature, and `report-uri.io` didn't know about it until they heard that the MIME type was changing. :/

Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes. OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=691726 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6227193935953920 Requesting approval to ship? Yes. *cough* I've actually already landed this in https://codereview.chromium.org/2717463006. It should have occurred to me to send an I2S, regardless of the feature's quasi-proprietary nature. :(

-mike

[Anne van Kesteren]

On Tue, Mar 7, 2017 at 7:40 AM, Mike West <mk...@chromium.org> wrote:
> Going forward, I intend to fold this reporting mechanism (and CSP's, which
> has similar properties (and Network Error Logging (and HPKP (and `Expect-CT`
> (and etc.)))) into https://wicg.github.io/reporting/, and by doing so give
> ourselves an opportunity to rework things in a more sane way. You'll note
> that that mechanism does indeed intend to make CORS-enabled fetches (see
> https://wicg.github.io/reporting/#try-delivery).
>
> Changing the MIME type to mitigate the (low) risk of a server looking for
> JSON seems like a reasonable thing to do, but changing the mechanism more
> fundamentally is something I'd like to do wholesale by introducing an
> improved reporting mechanism, rather than transitioning each mechanism
> individually, and then introducing a new thing on top of it.

How does using CORS going forward work? Every existing setup will
break because they suddenly get CORS preflights they won't be equipped
to answer. I also thought these fetches would go without credentials,
but suddenly they are with?


--
https://annevankesteren.nl/

[Mike West]

On Tue, Mar 7, 2017 at 9:52 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

How does using CORS going forward work? Every existing setup will
break because they suddenly get CORS preflights they won't be equipped
to answer.

Right. That's the point I was trying to make. :) Changing the existing reporting mechanisms to require preflights for cross-origin endpoints would be difficult because of existing usage. I'm suggesting that a good way to get to a better place in the future is to build out a centralized reporting mechanism we're happy with, deprecate the old mechanisms, and migrate over time.

 

I also thought these fetches would go without credentials,
but suddenly they are with?

The reporting API spec is in flux, so now's a good time to have these kinds of conversations (though, probably best to do so as issues on that document rather than in this thread).

-mike

[Philip Jägenstedt]

OK, so if this is just one of many mechanisms that doesn't use CORS, let's put that question to the side for this intent. The lack of a spec is not great, but blocking the MIME type change on the creation of a spec for the whole feature doesn't seem reasonable. LGTM2.

On Tue, Mar 7, 2017 at 6:21 PM 'Mike West' via blink-dev <blin...@chromium.org> wrote:

On Tue, Mar 7, 2017 at 9:52 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

How does using CORS going forward work? Every existing setup will
break because they suddenly get CORS preflights they won't be equipped
to answer.

Right. That's the point I was trying to make. :) Changing the existing reporting mechanisms to require preflights for cross-origin endpoints would be difficult because of existing usage. I'm suggesting that a good way to get to a better place in the future is to build out a centralized reporting mechanism we're happy with, deprecate the old mechanisms, and migrate over time.

As long as failure is an option, that sounds good. In other words, the fewer the differences are between the old and the new the better, because we might have both forever :)

[Mike West]

On Wed, Mar 22, 2017 at 6:53 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

OK, so if this is just one of many mechanisms that doesn't use CORS, let's put that question to the side for this intent. The lack of a spec is not great, but blocking the MIME type change on the creation of a spec for the whole feature doesn't seem reasonable. LGTM2.

It's an existing thing that we'd do differently if we were doing it again. Since we _are_ actually doing it again via the Reporting API, that seems like the right place to make more substantive changes (and also a good opportunity to document the feature in a way that we haven't done until now).

On Tue, Mar 7, 2017 at 6:21 PM 'Mike West' via blink-dev <blin...@chromium.org> wrote:

On Tue, Mar 7, 2017 at 9:52 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

How does using CORS going forward work? Every existing setup will
break because they suddenly get CORS preflights they won't be equipped
to answer.

Right. That's the point I was trying to make. :) Changing the existing reporting mechanisms to require preflights for cross-origin endpoints would be difficult because of existing usage. I'm suggesting that a good way to get to a better place in the future is to build out a centralized reporting mechanism we're happy with, deprecate the old mechanisms, and migrate over time.

As long as failure is an option, that sounds good. In other words, the fewer the differences are between the old and the new the better, because we might have both forever :)

I'm pretty confident that we can remove this feature entirely once we offer the new system. That's my plan, in any event. :)

-mike

[Rick Byers]

LGTM3 

sorry for the delay :-(