|
|
|
|
|
|
by geofft
3076 days ago
|
|
|
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.) |
|
|
> 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.