8 ms·
Yeah, we don't trust just anything that comes in on that socket. For example, we implement standard CSRF mitigations like checking Origin/Referer headers. We al
by mholt 8y ago
Yeah, we don't trust just anything that comes in on that socket. For example, we implement standard CSRF mitigations like checking Origin/Referer headers. We also don't use DNS at all in the local frontend/backend interactions and require the Origin to be exactly "127.0.0.1" (or the IPv6 equivalent) which is what we bind to.
(Edit: I just looked it up again and I'm 99% sure that web pages can't override the Origin header, especially when making cross-origin requests.)
- orf 8y ago> I just looked it up again and I'm 99% sure that web pages can't override the Origin header, especially when making cross-origin requests What about other, potentially unprivileged software running on your machine that can?
- mholt 8y agoIf you've got rogue software running on your machine, all bets are off.
- Ajedi32 8y agoNot necessarily. It could be running in a sandbox, or as unprivileged user, and accessing your app's API over localhost would allow for privilege escalation.
- mholt 8y agoI see your point. But in my book, that's still rogue software. And that's a terrible sandbox. :)
- orf 8y agoI see your point, but you're saying: > Yeah, we don't trust just anything that comes in on that socket Well, you are, you're trusting it came from a browser so the Origin header is correct, right?
- caf 8y agoIt seems like there could be unexpected interactions with other services running on 127.0.0.1, which don't even have to be HTTP to cause problems - eg what if there's a service that echoes back the request in the response if it receives a request it doesn't understand? A remote web page could probably use that to bounce its request to your service but appear to come from 127.0.0.1.