Giters

w3c / websub

WebSub Spec in Social Web Working Group

Home Page:https://w3c.github.io/websub/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Subscription verification request is not authenticated/protected

aaronpk opened this issue · comments

commented

I am currently writing a subscriber. Section 4.3 describes the verification request that hub sends, where the subscriber is supposed to echo back the challenge.

  1. My subscriber requests the subscription from the hub.
  2. The hub asynchronously makes a request back to the subscriber to verify the subscription request.
  3. I use that request to mark that the subscription was successful. If the hub never makes that verification request, then I know something went wrong and can mark the subscription as not yet active.

The problem lies in that the verification request is a GET request with no secret information, so anybody could forge a verification request to my subscriber. A forged request could also set the lease_seconds to something that could trick the subscriber into thinking things are different.

Potential solutions:

  • The hub could include the hub.secret that the subscriber sent in the first place (Probably not a good idea since this is sent in a GET request and secrets in query parameters is generally bad)
  • The hub could use the hub.secret to compute a digest of the other query parameters, and pass the digest in the request as well.
  • Add a new parameter to the subscription and verification used for this purpose.
  • Other thoughts?
commented

I think these were two separate issues so I broke the other one out: #43

commented

I think this overlaps with #36. Adding an X-Hub-Signature header just like for authenticated content distribution, signing some subset of the hub.* parameters, might work nicely.

commented

In my implementation I just finished, I ended up using callback URLs such as https://example.com/callback?token=xxxx. This allows me to discard any GET/POST requests to the /callback path that don't have a valid token, essentially building a mini authentication mechanism. After finishing that, I'm not sure what else I would actually gain from having an additional signature, so I'm going to drop this issue. See #43 for an editorial suggestion.