Consider limiting scope of NEL registration
yoavweiss opened this issue · 7 comments
One of the issues outlined in https://github.com/w3c/network-error-logging/issues/136#issuecomment-1557295046 is that any path on an origin can register any report. It seems like we could limit NEL scopes in similar ways to how we limit subdomains: allow any scope to register DNS related reports, but only report NEL on URLs that match the scope in which they were registered for other errors as well as successes.
@clelland - WDYT?
I'm not certain what you mean by "scope" in this context; is that just the specific origin under which the policy is registered? If so, then I think we might already do quite a bit of this:
A response returning a NEL header, for example, from https://a.example.com, creates a policy which is already scoped to either:
- just the specific origin from the request (https://a.example.com), or
- that specific origin and its suborigins (https://a.example.com as well as https://*.a.example.com)
It cannot register a NEL policy for https://b.example.com, or https://example.com, or anything outside of that scope.
Further, in the case of suborigin policies, the policy can only generate DNS-related reports for origins other than the top-level of that scope. It is not supposed to be able to generate success reports, or non-DNS failure reports, for suborigins at all. (See #141 for a possible bug to fix here though)
Apologies for not being clearer. I meant "scope" in the same sense of a ServiceWorker scope (with its path restrictions).
Essentially, we may want to consider limiting the ability to register NEL reports beyond DNS errors to the path that sent NEL headers, but not above it.
This may be reasonable (still thinking through whether it solves the actual problem, or if it just makes the vector slightly different)
At the same time, I'm a bit concerned about the possibility that this makes the API unusable for, say, image CDNs, where now a policy may or may not work, depending on how they've previously structured their URL space.
Feedback on the WebPerfWG call was that this would significantly limit the usefulness of the feature and would significantly reduce its coverage.
Is there a plan to mitigate the issue of rogue content creators? AFAIU by closing this issue you refuse a possible mitigation without actually fixing the core issue.
This issue was suggesting a specific potential mitigation to one of the issues raised, which, after talking to the working group, which includes implementers as well as people actually deploying and using NEL, doesn't seem to be workable.
I think that your statement in #136, that
For example, a party controlling a path on a web server (for example on some shared hosting site) can deploy a tracker that allows such party to receive information on accessed pages on paths on the same domain (or subdomains), provided that the tracked user first accesses a URL controlled by the adversary.
is reasonable to include, with the caveat that the attacking party needs to be able to set HTTP headers (I don't know if many shared hosting sites allow that, but I suspect that most do not.) since just being able to host content is insufficient.
This specific mitigation tries to enforce a boundary which does not exist in practice, and doesn't work well with the way that NEL is actually deployed. In order to be effective, this would have to be the only way of setting policies (since if it were opt-out, then an adversary would simply do that), which would necessitate storing received policies at every path in a origin which a user visits, since NEL headers are generally sent on every response.
It would still be great to solve the underlying problem, but that might not be feasible, and explanatory text might stil be the best measure to take in the meantime. Closing this issue just suggests that we're not implementing this particular mitigation, which was suggested by @yoavweiss in response to #136, but isn't necessarily the only possible mitigation. You're welcome to suggest other concrete solutions.
I think that your statement in #136, that ... is reasonable to include,
Am i supposed to file a separate issue?
with the caveat that the attacking party needs to be able to set HTTP headers (I don't know if many shared hosting sites allow that, but I suspect that most do not.) since just being able to host content is insufficient.
I do not know what share of hosting sites allow that. But for example I control personal pages at our university and I can insert own HTTP headers. Personal pages of my colleagues are hosted in different directories so right now, I can inject NEL headers to learn information that I am not supposed to know. The proposed mitigation in this issue would stop me from learning that information.
I suppose that my university is not the only one to host such configuration. Essentially all the time the content creators can use PHP or other scripting language, they can also insert HTTP headers.