w3c / webmention

Webmention spec
https://www.w3.org/TR/webmention/
112 stars 46 forks source link

Require same Origin #15

Closed bblfish closed 8 years ago

bblfish commented 8 years ago

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:

I'd say that nearly 20 years without a spec more formal than that indicates that we may not need one, given how much has been built on it, theoretical drone strikes notwithstanding.

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 and target 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 and target attributes? Pretty much anything. Here are some ideas:

  1. it could be a service that people use to list porn sites and people linking to them
  2. it could be a service that people use to list blog posts that are sexist and people linking to them
  3. it could be a service that people use to list blog posts that are have copyright infringements and people linking to them
  4. it could be a service that people use to list blog posts that insult the koran and people linking to them
  5. it could be a service that terrorists use to notify a group of the next attack target
  6. it could be an internal secret service department that puts people on a terrorist watch list, and the webmention agent could be built into the client software ( instead of being on the server )

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.

aaronpk commented 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.

sandhawke commented 8 years ago

@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).

aaronpk commented 8 years ago

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.

sandhawke commented 8 years ago

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.

aaronpk commented 8 years ago

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.

aaronpk commented 8 years ago

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

aaronpk commented 8 years ago

@bblfish please comment here if you are satisfied or unsatisfied with the result of this discussion