Intent to Implement and Ship: Network Error Logging request_headers and response_headers fields

[Douglas Creager]

Contact emails

dcre...@chromium.org

Spec

https://w3c.github.io/network-error-logging/#the-request_headers-member

https://w3c.github.io/network-error-logging/#the-response_headers-member

Summary

The new request_headers and response_headers fields in a NEL policy instruct the user agent to include the values of arbitrary request and response headers when constructing a NEL report about a request.  (The server already has visibility into these headers when servicing the request, so including them in NEL reports about the request does not open up any new security or privacy concerns.)

Motivation

The spec includes an example of using these new fields to verify whether your validated caching is working as expected.  For servers that include information in response headers about which serving infrastructure serviced the request, this would also allow NEL reports to identify network outages that only affect particular pieces of infrastructure.  This would also allow server admins to join NEL reports with distributed tracing data collected server-side.

Interoperability risk

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: Strongly positive (This feature was requested by external developers)

Compatibility risk

This new feature is backwards-compatible with the existing implementation of NEL that has already shipped.  Existing NEL policy headers that do not include these new fields will continue to work as before.  For origins that start to use the new fields in their NEL policies, older user agents will still create NEL reports; those reports will just not include the new fields.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

None

Is this feature fully tested by web-platform-tests?

We will create WPT tests as part of implementing this feature.

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5707065825689600

Requesting approval to ship?

Yes.  This is a small backwards-compatible change; I don't think it needs to be separately flag-protected.

[Daniel Vogelheim]

Douglas,

Can you please file a launch bug and sign up for a security review?

My concern is that this proliferates potentially security sensitive data like login cookies (which the API could include by including the Set-Cookie: or Cookie: http headers in the network log).

Your argument is that the site already knows all header values and therefore this should be a security no-op. That's not a bad argument, but I'm not sure it's sufficient: Large sites (for example google.com) have internally segmented data handling procedures, where a dedicated group has access to e.g. the very security-sensitive login data, with security & audit mechanisms in place to effectively prevent & combat abuse. By your argument, these different groups are the same entity (since they operate on the same site), but in practice they're probably not. Note how in the past we've worked to lock down such cookies further (e.g. with "Secure" or "HttpOnly" Set-Cookie: modifiers).  If we now introduce an API where these same headers could be copied elsewhere, we risk undermining such security measures by allowing the cookie values to end up in places they weren't intended to.

I'm honestly unsure to what extend my concern actually holds up in practice, but I believe it's serious enough that this feature should be security reviewed.

Thanks,

Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1542743183.3054840.1583621064.47649864%40webmail.messagingengine.com.

[Douglas Creager]

Thanks for the feedback, you raise a very good point!

Large organizations like Google should still be able to enforce this kind of policy.  For instance, if your frontend server strips the sensitive request headers before sending the request to a backend service, that same frontend server will have a chance to sanitize any NEL configuration that the backend tries to install, by stripping the same set of sensitive header names from the config.

Given this, do you still feel that the feature needs a launch bug / security review?

[Daniel Bratell]

Just that it's not trivially safe is enough for there to be a security review.

Another thing that might need a review is the specification. What is the status of it? I was a bit surprised to see it defining "network request" with a lot of MUST and MUST NOT statements that might not be fully correct. It seems a bit out of the scope of a logging mechanism specification. It would be great if someone with experience from related specifications like the fetch spec can verify that they work together. Tag review?

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Douglas Creager]

Sure thing, I'll open the launch and security review bugs!

Re network request, I completely agree that NEL isn't the right place for those definitions long-term.   There's an editor's note slightly further down in that section mentioning that we want to move this language into Fetch itself in the near future.  We'll have to be careful to clarify that the extra level of detail in error conditions is only visible to the target of the request via NEL, and not to the initiator of the request (via Fetch API return values, for instance).

[Daniel Bratell]

We (Yoav, Philip, Chris and I) discussed this in the API owners meeting today and concluded that it would be best to get a security minded analysis of the effects of exposing all HTTP headers to web pages before proceeding with the approval process.

As mentioned earlier in this thread, there might be some issues (to be filed) with the specification in general, but nothing that particularly blocks this intent. The security uncertainty is the only blocker.

/Daniel