Add whitelist for valid browser push service hosts
jfbrennan opened this issue · comments
Doesn't look like web-push whitelists the known list of valid browser push services. Is this on purpose?
The list is short and documented by each vendor. AFAIK there are zero hosts other than the ones from browsers that web-push should ever attempt to send messages to. There is apparently a android.chromlum.info
(note the L) malware service and if clients were compromised could potentially send messages to that service.
The list is, from what I've been able to gather, just this:
Browser | Service name | Host |
---|---|---|
Safari | Apple Push Notification Service or APNS | *.push.apple.com |
Chrome, Brave, Opera | Google Firebase Cloud Messaging or FCM | fcm.googleapis.com, android.googleapis.com |
Edge | Windows Push Notification Services | *.notify.windows.com |
Firefox | Mozilla autopush | updates.push.services.mozilla.com (plus other non-prod envs) |
In theory, one might want to run their push service. We could:
- print a warning when an unknown push service is used;
- add a parameter to sendNotification to block unknown push services.
In theory, one might want to run their push service.
If I understand you correctly, it's impossible to get a browser to subscribe to your own push service. PushManager.subscribe()
internally calls the browser vendor's own private push service and you have no way of changing that.
In Firefox you can change it by setting some internal preferences. If you are a big organization who wants to have a private push service, you could do that.
Oh interesting. I'll pray for any org who goes down that path :)
It's not too complex, you "just" need to use an open source Web Push server like https://github.com/mozilla-services/autopush-rs/ and deploy it somewhere :)
This just adds an unnecessary time bomb to the library if any of the vendors decide to change their push service domain, or if any new vendors start to run their own services. If someone is this paranoid about security, it's better to whitelist it on the DNS layer.
Agreed!
Ok I understand the hesitation because things can and do change and you don't want to burden the library with that maintenance. To be fair, there's no "paranoia" here. Attacks have and will happen, like android.chromlum.info
which was a malicious web push endpoint.
There's not a lot of good resources to help guard against this, perhaps this lib could simply add some info/resources in its docs?
I would accept a PR to do one or both of the things in #801 (comment).