Skip to main content

According to the current Webhooks Events API documentation, only the client authenticates to Strava upon subscription registration/check, with the API client_id and client_secret.

This is great but IMO insufficent, as both parties should somehow be authenticated. In other words, Strava should authenticate with the Webhook suscriptor. The way is done at the moment, an attacker could impersonate Strava's API sending fake event data to the client's endpoint. The only way the client could defend from this would be checking whether if the subscription ID matches or not. But this is neither proposed as a security measure in the documentation site, or implicit within the process (it's something that the clients would need to implement ad-hoc). Moreover, since the subscription_id field is integer, it could be pretty easy for an attacker to guess the right value.

Is there any other way of dealing with this that you could suggest?

Thanks in advance.

Hello everyone.

I have the same security problem regarding the Strava webhook, I consider the "subscription Id" check insufficient.

Only include the hub.verify_token in the GET method (when it would also be necessary in the POST method).

I would need an answer please to know if there is another way to secure (because there is nothing like that in the official documents) the webhook.

Regards.

It is only you and Strava that can (should) know the subscription_id. You could do an additional check to verify that the request origin is coming from Strava. Otherwise, you can valid the individual events, and add rate limiting to mitigate ddos attempts.

It's funny that we have to use the complicated oauth workflow for authentification and authorization but Strava wants to access our systems without any standardized authentication. That prevents me from using webhooks at all.

Reviving this conversation because this is actually a fairly big concern.

As mentioned, the hub.verify_token is only used once, at the time Strava verifies the webhook endpoint. Why isn’t this parameter included in all calls from the Strava webhook?

Or, even better would be a security header with credentials included along with the Client ID and Secret for the app.

Looking through the rest of the Community Hub, it looks like the most common method of verification is whitelisting IPs, but even that seems to be too fluid to be reliable long term.

Same here, lack of verification is pretty concerning.

HMAC in the header wouldn’t change the existing payload and so would be opt in to avoid breaking existing implementations. This *should* be pretty trivial to implement.

Same here. I’m trying to harden the overall security of our app and not having any validation in the webhook payload or headers is making it impossible to add any reasonable level of security. 

 

If someone happens to guess our app’s webhook endpoint (which frankly would be pretty easy to do given enough typewriter monkeys), anyone could send any events to any Strava webhook receiver endpoint.

 

Best case scenario, our app could get rate limited during an attack. But this leaves a gaping hole in the system security wise.

I was surprised to see this too - completely agree there needs to be a way to validate what is received.

Reply


Terms & ConditionsCookie settings