Closed bblfish closed 8 years ago
Requiring that the webmention endpoint be on the same domain as the page would prevent webmention services from being able to exist, of which there are already a few. Other specs manage fine with allowing delegated services (PubSubHubbub, OAuth, anything using Webfinger, etc). Given that webmention requests are unauthenticated, even to the point where it's completely possible for anyone to send a webmention request on anyone else's behalf, these examples seem to be completely baseless.
@aaronpk I think you may have missed the point (as I understand it). It's not webmention endpoints that are being 'attacked' here, it's all the millions of crufty old web forms, many of them behind corporate firewalls. If webmentions are being sent from machines which are also inside that firewall, there's a new attack vector. It may be there's no actual hole here, but the analysis has to be about how one could possibly trigger a mention to be generated, not just about endpoints (since no actual endpoints are used in this attack).
A webmention can be triggered by a user's publishing software when a post is created, or when a post is updated such as after receiving a comment (see the related Salmention discussions on the wiki), or could be triggered by a webmention sending service, or can be sent manually via curl (we see this a lot when people are testing). I don't see how it's relevant for the spec to talk about protecting unrelated servers from accepting I authenticated POST requests.
Alice sets up an internal (behind the firewall) blog. Mace creates an incendiary blog post about Alice or the company, provoking Alice into blogging about Mace's post, internally. Alice's blogging software now does a webmention. Mace controls where that webmention goes. He can set the endpoint to a behind-the-firewall address (and he can do this just when Alice's software is asking, so there's no sign of it to anyone else).
Now, where is he going to make Alice's blog software do its source=...&target=... POST? How much can he do with that? Well, I think Henry's right that there's all kinds of cruft behind firewalls. That's the whole idea of firewalls -- you can relax and not worry about security on the inside. So there might be services that are triggered by POST that never look at the posted content, or that use URL parameters (which Mace can set), or which mix the two together.
Do you see why there's a risk here? And there's a risk to people who have no reason to be paying attention to webmention, and who don't benefit from it, so that requires we act with extreme caution.
Thanks for the clear example, @sandhawke. I think this is a valid concern and I'm going to open a new issue that talks specifically about this security consideration.
Here is the follow-up issue that details this attack and provides some suggestions for moving forward https://github.com/w3c-social/webmention/issues/20
@bblfish please comment here if you are satisfied or unsatisfied with the result of this discussion
A number of people here have trouble understanding Cross-Origin issues as discussed in issue 10: Lack of context in WebMention. See the discussion there or @kevinmarks comment explaining forms in issue 1.
One answer to this is to require that WebMention links only ever be to the same origin: ie. that people host their own WebMention end point. It could be argued that in that case we do indeed then find ourselves in the same situation pointed out by @kevinmarks with forms since the beginning of the web, and that extra context is not required:
If an answer cannot be found to #10 then this would be a way to reach a minimal consensus.
Examples
Consider the current use case from the current WebMention spec Protocol Summary section.
Imagine that Aron's webmention statement points to the an endpoint on another origin, that understands the
source
andtarget
attributes in a perfectly reasonable way for that service. Perhaps someone hacked Aaron's web site, or a man in the middle has altered Aaron's response to Barnaby's agent's request and changed the link to point to the other endpoint, or just simply because Aaron is himself intent on some form of mischief.As a result Barnaby's webmention enabled agent ( this could be a client or server ) would - having published Barnaby's post referring to Aaron's entry - and having retrieved the mischievous webmention endpoint POST a message, send to this actually non webmention endpoint a message that is interpreted by that agent as meaning something completely different by the server. What kind of meaning could that agent give the
source
andtarget
attributes? Pretty much anything. Here are some ideas:In 6. even though there is no explicit authentication there is an implicit authentication because Barnaby's web agent somehow finds itself inside the firewall. This links this issue to issue #14 "Webmention MUST be done anonymously".
The examples here are examples that could be used by issue #1 "Introduce Property parameters". But if it is easy to imagine a protocol which specifies the relation between link and target, it is also easy to imagine that other people are already using such systems now, without reference to webmention, or that people could develop some inspired by it, or with mischievous intent.