currently, the HTTP call which the subscriber gets when subscribing to the topic https://api.twitch.tv/helix/streams looks like this for a stream that went offline:
{
"data": []
}
I see two problems with this:
There is no unique ID existing within this payload. Therefore, deduplication cannot be performed on subscriber application level. This however is necessary because subscriber notifications are retried more than once. (There may be more topics as well that don’t contain unique IDs, I’m not sure.)
Because there is no unique ID or nonce existing in the request body, WebSub signatures are the same for each subscriber notification. This enables attackers to forge such requests after recording one (= replay attack). A unique ID would solve this problem, if it has a large enough non-guessable part (!).
Another point is that it would still be cool to have the user_id or something included for an offline stream so that this info does not have to be remembered from the topic or something like this.
Webhook metadata, such as the notification ID, timestamp etc… that’s all sent in as headers as it’s not part of the payload itself.
To differentiate topic notifications, such as offline streams which have identical payloads, you should use different callback URLs. For example: https://mydomain.com/webhooks/streams/12345 or https://mydomain.com/webhooks/streams?user=12345
Using different callback URLs allows you to still use a single handler deal with them all but lets you differentiate each one.
Webhook metadata, such as the notification ID, timestamp etc… that’s all sent in as headers as it’s not part of the payload itself.
Thank you, that helps. I totally missed these values because they were not mentioned in the docs.
To differentiate topic notifications, such as offline streams which have identical payloads, you should use different callback URLs. For example: https://mydomain.com/webhooks/streams/12345 or https://mydomain.com/webhooks/streams?user=12345
I am already using different callback URLs for different streams, that’s basically the only way to differentiate offline stream events right now.
However, there is still this thing with predictable signatures and replay attacks.
I guess this is a “problem” of WebSub itself, and without the hub including a unique nonce or a timestamp that can also be validated by the subscriber to really be unique, this is impossible to prevent.
So I assume the only way to prevent this attack is to use non-guessable callback URL paths together with HTTPS to prevent attackers from even seeing the requests and replay them, am I right?
That’s the intended way, so you’re already doing it right.
Correct. I don’t believe the spec has anything that would allow for verification of the notification as a whole rather than just the payload, so the only preventative measures you can take are as you mentioned such as obscurity with the URL and using HTTPS (which is required for many topics already)