Webmention MUST be done anonymously

[bblfish]

One way proposed by @sandhawke and others to reduce the risks of situations described in issue 10: Lack of context in WebMention is to force WebMentions to be anonymous. This way someone POSTing a form can never be taken to be responsible for doing so. This seems to be the argument given by @sandhawke in a comment to that post

It's a POST done without any credentials, so some would say it can't do anything bad, but I think bblfish is imagining that maybe sometimes doing I POST even without credentials could be taken as a commitment. I think there may be occasional poorly designed systems where that's true.

If it is only a problem with poorly designed systems, then they can be blamed for it. On the other hand systems in which the client has authenticated would be well designed. So for those the argument would go through.

Therefore it seems that WebMention cannot allow client to authenticate.

[sandhawke]

I'd probably phrase it more as reducing the risk of XSS attacks, but yes, I'd agree we should say credentials (eg cookies, client certs, etc) MUST NOT be used during the webmention POST operation. From what I've heard, this is probably being adhered to now, just because webmentions are pretty much always sent by a server anyway.

Alternatively we could say that if they are used, that's an extension, and someone defining such an extension needs to carefully analyse the security implications.

[bblfish]

Servers are peers on the web, and so can also authenticate, if only be delegation (eg. WebID authentication and delegation).

Still this also implies that one must Require Same Origin. Otherwise the danger is that the page with the webmention link point to a form on another site that is designed to interpret POSTS with exactly the same attribute values in a manner different from that intended by the webmention agent.

To use the use case from the current WebMention spec Protocol Summary section, this could happen either because someone hacked Aaron's web site, or because a man in the middle has altered Aaron's response 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. 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 )

One can imagine a lot of examples like 6. where the authentication is not required for people inside the network.

[sandhawke]

This seems to be tangled with #15. Maybe that's unavoidable.

I take your point that in practice IP addresses are sometimes used as a credential. Maybe not in the IWC community, but often in enterprise computing. So it's impossible to really know one is making an anonymous webmention.

Conclusion: to avoid opening some security holes, cross-origin webmention is going to have to either be forbidden or require some kind of pre-flight confirmation that what you're posting to is really a webmention endpoint. On the plus side, this pre-flight was going to be needed anyway if we wanted content-negotiation.

Note also that origin checking has to be done with some care. For instance, doing the POST to the endpoint, one MUST NOT follow redirects to another origin.

[bblfish]

Conclusion: to avoid opening some security holes, cross-origin webmention is going to have to either be forbidden or require some kind of pre-flight confirmation that what you're posting to is really a webmention endpoint. On the plus side, this pre-flight was going to be needed anyway if we wanted content-negotiation.

Ok, looks like we are actually making progress here :-)

[aaronpk]

I don't see how a "pre-flight confirmation" actually adds any level of security. The first thing an attacker will do is set up a webmention endpoint that acknowledges that it is a webmention endpoint, and then any of these "attacks" are still possible.

[bblfish]

What kind of attack are you imagining there @aaronpk ?

Suppose from the webmention example in the Protocol Summary that Aaron links to a webmention endpoint that claims to be a webmention endpoint ( In a way yet to be determined, but #11 provides some initial idea ). Now Barnaby's agent finds that endpoint, verifies that it indeed claims to be such an endpoint, and posts the appropriate attribute values there.

1. POSTing to an webmention endpoint does not have any consequences other than what is given by the content posted. This is a bit like posting to an LDP Basic Container, insofar as, posting to a Basic Container does not come with any further illocutionary force other than the creation of the resource sent. So Barnaby's client knows he will not be beholden to anything more than his act of webmention. So Barnaby's client can feel safe that he has not committed himself to something.
2. The endpoint POSTed to could lead to its owner being surprised about the post, and finding the cause of it could alert Aron - though not using his webmention endpoint evidently :-)
3. If either one of these two actors talks to Barnaby he can point out that he followed the right procedure: He read the form before posting.

Still one could go one step further and let the Endpoint describe the endpoint of whome it is. In that case Barnaby's agent could find out that there was a disconnect between Aaron's statement and the endpoint's statement.

[aaronpk]

The only useful thing I can see out of this thread is adding explicit language that requires a webmention sender to not follow an HTTP 30* redirect when sending a POST request to the webmention endpoint, which is already explicitly stated in the HTTP spec but might be worth including here anyway.

[bblfish]

@aaronpk

The only useful thing I can see out of this thread is adding explicit language that requires a webmention sender to not follow an HTTP 30* redirect when sending a POST request to the webmention endpoint, which is already explicitly stated in the HTTP spec but might be worth including here anyway.

I don't think that addresses the core issue.

[aaronpk]

From the original comment:

Therefore it seems that WebMention cannot allow client to authenticate.

There is currently no way for a webmention sender to authenticate following the spec, so this seems like a non-issue.

[bblfish]

@aaronpk I don't understand your comment: All of the HTTP methods for authentication are available. One can have 401 with WWW-Authenticate headers, TLS authentication, password authentication using forms and cookies, etc. etc.... All of this is available to a client.

[aaronpk]

As you mentioned earlier, it seems undesirable to rule out the possibility of making authenticated Webmention requests from the outset. Current implementations do not rely on the Webmention POST being authenticated in any way; all verification is done after the fact. However, I can imagine a future where it may become desirable to add the ability to authenticate the Webmention requests, either for spam prevention or quicker verification, etc.

Is there some way to say that according to the the current Webmention spec the POST request MUST not include any authentication or cookies, while also leaving room to add that possibility in the future?

[aaronpk]

We discussed this on the March 16 telcon, and came to the conclusion to add a note to the spec to the effect of "this spec does not define special handling of a webmention that contains additional headers, so use standard XSS prevention techniques." This has been added to the latest Editor's draft.

http://webmention.net/draft/#cross-site-request-forgery

Please let me know if this addresses the concerns in the issue, and if not, feel free to re-open with new information.