[benchaney]

Agreed. Not that lost ago, there was a post about how a BitTorrent client had a similar issue. Just like in that case, the real vulnerability was in browsers. I wonder how many programs are going to be discovered to be “vulnerable” before people realize that they are missing the point.

[geofft]

What do you think browsers should do instead?

[benchaney]

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

[geofft]

That doesn't save you from this attack - you can send the index page and some JS over with a long Cache-Control header, and then trigger the site to get loaded some days later when DNS has been changed to point to localhost. The JS will trigger the same XHR and it will succeed this time.

(.. and now that I think about caching, the various "within the same tab" solutions elsewhere in the comments don't work, because they'd force Gmail / OWA / Slack / etc. to get reloaded with a full cache flush when they change IP addresses, which everyone would hate.)

[benchaney]

Can you really reload a website just even if it is rejecting connections just using a long Cache-Control header? I find that hard to believe.

> because they'd force Gmail / OWA / Slack / etc. to get reloaded with a full cache flush when they change IP addresses

I think security issues should be fixed even if the fix imposes an inconvenience. Especially since the inconvenience is basically just a performance issue.

Side note: I don't find the idea that this attack is hard to fix a particularly strong justification for not fixing it. Not being able to connect to arbitrary hosts is deliberately not part of the API exposed to javascript so I think it would be hard to argue that DNS rebinding isn't a bug.

Side note 2: The workaround of "don't trust" localhost doesn't prevent all DNS rebinding based attacks. For instance, if you took out an ad, you could then have a botnet to bypass any ratelimiter.

[michaelermer]

I call BS, it's the responsibility of the server to check Host headers and implement CORS. All browser provide these security measurements. There are valid use cases for having domain aliases for local ips.

[benchaney]

> There are valid use cases for having domain aliases for local ips.

My preferred solution doesn't prevent this, and in fact it is preferred partially because some of the other solutions do.

[SahAssar]

The vulun is in the fact that the program blindly trusts incoming HTTP based only on a nonce being in both the body and a header.

[benchaney]

No, the "vuln" is assuming that only users on the machine can access localhost. This is a completely reasonable assumption, and it is on the browsers for invalidating it.