[Editorial] Improve section 4.5 with specific mention of using CORS when retrieving target URLs

[tantek]

From @hildjj at https://groups.google.com/forum/?_escaped_fragment_=msg/mozilla.dev.platform/RPu2oIc70Ug/GuZXnR1JAwAJ#!msg/mozilla.dev.platform/RPu2oIc70Ug/GuZXnR1JAwAJ

Summarized:

Section 4.5 (Limit access to protected resources) should, instead of requiring server administrators to take precautions about dealing with protected resources that their server might have access to, instead recommend using CORS to determine whether resources are public or a protected resource.

[aaronpk]

Section 4.5 is talking about webmention senders, not receivers. Since sending a webmention involves making a POST request, there is a potential danger in an attacker causing a sender to POST to some internal system that has no other authentication mechanism.

The concern brought up by @hildjj is actually something different, since he talks about potentially displaying data from internal systems as a comment, which is actually more about the display of data from webmentions rather than about webmention verification itself. It's similar to the idea of respecting the access control of the data retrieved at the source URL when republishing it on the receiver's website.

[aaronpk]

I don't actually see how an existing CORS mechanism could help with this. However I created a pull request with a note warning about republishing potentially restricted content.

[tantek]

I think the note makes sense, and am also unsure how CORS could be used to improve this. If we figure it out later we can add that in other documentation.

[aaronpk]

@hildjj Does this change address your concern?

[hildjj]

No, that does not address my concern. You are creating an attractive nuisance; people will deploy generic servers on generic networks, and will allow themselves to be attacked really easily.

[sandhawke]

Thanks for your eyes on this, @hildjj. We were concerned about this, and went over it in some detail in https://github.com/w3c/webmention/issues/20 . We ended up unable to think of a plausible security concern, but it's certainly possible we missed something. Can you sketch out the attack you have in mind?

Edit: Never mind about Issue 20. That was about Webmention senders being tricked into doing a harmful POST, not about receivers being tricked into a harmful get.

In the email linked from the intro, @hildjj says:

Nobody is going to remember to sandbox the network connection of the process that is checking the targets. I send you a webmention whose target is "https://intranet/", your process requests that URL, and you post a synopsis of what you found as a comment on the blog entry I put in the source. Yes, there are protections you can put in place for that, but I can't think of any that can be coded generically into a piece of open source software that doesn't open up your internal resources by default.

One issue is how is the webmention going to get through the firewall? From outside the firewall, it seems unlikely one could POST to a machine on the inside. To do that, one would have to have set up the firewall to allow it, which ... seems like a bad idea. And the added note helps clarify why.

On CORS: are you suggesting that webmention receivers should/must make sure there's an Access-Control-Allow-Origin: * on every resource they validate? Would you send an Origin header? Anyway, yes, that would reduce the possibility of behind-the-firewall documents ending up included, I guess. It seems outside the intended use of CORS, though. Is there currently a reason to set Access-Control-Allow-Origin on HTML documents? Checking on a bunch of HTML pages advocating setting that header, none of them set it on the HTML page talking about it (and why would they?). Also, I think it's a pretty big barrier to adoption: I think people are trying to send webmentions for documents where they can't set headers.

[aaronpk]

I send you a webmention whose target is "https://intranet/"

I assume you meant "source" instead of "target"?

[tantek]

@hildjj I thought I understood the threat model here, but I don't think I do any more (because I thought @aaronpk's added text was sufficient).

It seems you think there's some method of faking source (and/or target) when sending a webmention that causes a webmention receiver to retrieve (and possibly display content from) a "protected" (intranet etc.) source.

The link discovery and link checking mechanisms are similar enough in Pingback that if such an attack were actually possible, we should be seeing tons of reports of it due to the orders of magnitude higher numbers of WordPress deployments alone (including presumably behind firewalls).

But no such reports exist AFAIK (for something similar enough in mechanism but much more widely deployed). Thus that makes me suspicious whether or not there's an actual exploitable threat model here or not. (if it was exploitable, we should have seen such exploits on Pingback).

In summary, is there any evidence or any reasoning that demonstrates that Webmention is any more of an "attractive nuisance" than Pingback in this manner?

If not, I would argue this is a non-concern (or at least shift the burden of proof to demonstrating an exploit, even a prototype with Pingback), given the absence of such exploits of Pingback on (presumably) WordPress servers deployed behind firewalls.

[sandhawke]

Ping @hildjj ... We'll be meeting to talk about this tomorrow. A response would be most helpful. @tantek maybe ping in person?

[hildjj]

The error alluded to in 3.2.3 for source URL does not contain a link to the target URL is an adequate mitigation. If this was added to section 4.1 as a MUST, I would be happier.

[sandhawke]

Thanks, @hildjj -- Is the text you want already in 3.2.2, second paragraph, "the receiver ... MUST perform an HTTP GET request on source ... to confirm that it actually mentions the target"? You want that repeated, perhaps more simply stated, in 4.1? That should be fine. You think there might be folks who don't do that?

[aaronpk]

Thanks for the suggestion, @hildjj. Adding that bullet point to section 4.1 makes the section more complete and is a good reminder for folks who skim the document. I've added that to the editor's draft: https://webmention.net/draft/#preventing-abuse

Please go ahead and close the issue if you're happy with it. Thanks!

[hildjj]

The text in 3.2.2 is fine, except that the JSON handling is underspecified. That's a separate, non-blocking issue.

The new text in 4.1 is good. @sandhawke, yes, I think it needs to be mentioned in the security section because it is a key part of the defense mechanism.

I can't close because @tantek opened, but am ok with closing now. Thanks all for the quick response.

[aaronpk]

Thanks!