Hacker News Reader

Comment by X-Istence | Hacker News Reader

This is a DNS re-bind attack.

I wonder if browsers will need to start including a dev mode toggle to allow access to anything hosted on the local loopback.

browsers absolutely SHOULD do that. A page on the internet shouldn't have access to localhost by default ever.

But this is not a case of a webpage on the internet having access to your localhost, its your local process which access local host!

This is a webpage with an origin outside your host, it is only supposed to have implicit access to the same origin in a sandbox imposed by the local browser. Unfortunately the nature of that policy is broken by not going bellow resolved names, most especially for non-http where the service isn't sent the hostname the client used to resolve it.

So, it is most certainly appropriate for a browser to block local networks (including localhost) from being in foreign domains AFA sanboxing. I also don't want a website attacking my (id)iot router via this broken sandbox.

But don't they update DNS so that the origin for the (presumably sub) domain is now pointing at your localhost? Perhaps the solution is to track the DNS state. Any external to localhost changes should be blocked. And any communication between parent/sub domains should never cross the localhost boundary no matter what DNS might say.

Of course this would interfere with development so it would need to be something you could toggle. But I'm 100% sure there's something I haven't thought of that depends on this behavior.

It's not only a DNS rebind attack. I'm pretty sure in this case even a GET could get rce , so you don't even need to check the cors headers. You can just XHR.

Reply on news.ycombinator.com