4 ms·
> But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it,
by rcfox 8y ago
> But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider!
Wouldn't that be solved by binding your listener to 127.0.0.1 (as opposed to 0.0.0.0 or your actual IP)? Sending a request to 127.0.0.1 shouldn't be able to send anything to the network.
- zaroth 8y agoBut can’t any JavaScript in the browser can call back to 127.0.0.1 (within the bounds of cross-origin policy). So you have to check Origin/Referer at least I think. Can you be sure Origin/Referer isn’t spoofed? Then there’s DNS rebinding which can get around the SOP. What about maybe strange ways that malformed requests could end up being reflected back to 127.0.0.1 through rebinding? So it just seems to me that even binding to 127.0.0.1 you have to be ready for just about anything to come in on the socket.
- mholt 8y ago> Can you be sure Origin/Referer isn’t spoofed? As far as I know, browsers forbid modifying these headers, (especially?) when making cross-origin requests.
- laumars 8y agoThe short answer is it depends on your firewall rules. The long answer is if the sender configured their routing to point localhost to your host then your service would still connect and route traffic back to the foreign address. But this type of attack can easily be firewalled against. There is also the potential problem of reverse proxies. However that requires local machine access anyway.