Reputation: 2465
I have read several introductory articles about implementing Web Push notifications for desktop browsers but am unable to understand the security part behind storing the obtained subscriptions from users's browser on backend server.
There are many websites that ask for permission to send you push notifications without authenticating/registering on those websites first. If I do grant them the permission and they store this permission string onto their backend server for later use, who's to say I wont generate another subscription string and send it to their backend server's endpoint that they used to save my subscription? and therefore flood their database with subscription entries.
What is the mechanism of identification and validation of received subscription on the backend server when there is no authentication/registration of users available on the website?
To illustrate better:
Website JS code asks browser for push permission -> I grant it by pressing 'allow' on the popped up window -> they take it and store it on their server using HTTP POST for example. Using a simple script I establish connection with the same HTTP endpoint and POST more subscriptions in the same format as the endpoint expects, therefore flooding the backend database.
Upvotes: 1
Views: 843
Reputation: 2465
After a lot of reading and consulting with one of the popular Web Push notification services I confirmed that it is indeed possible to flood backend server's database with forged subscription URLs when there is no authentication available on the website that uses the notification service.
The ways to defend against such attack are similar to the ways of defending agianst DDoS attacks: IP filtering, deleting database entries manually, etc.
Upvotes: 1