(issue 100) - security considerations

Hi

A comment on the statement 'the HTTP solution of not allowing servers to 
answer requests for "other" sites do solves quite a lot of the security 
concerns regarding information theft using HTTP'. Unfortunately, in some 
cases it's possible for the attacker to force the agent to send a forged 
Host header. See http://www.securityfocus.com/archive/1/445490.
I do agree that in general, verifying the request's Host header against 
the expected hosts serviced by the server is a good practice, but it's 
not 100% reliable against a DNS rebinding attack that forges the Host 
header.

There's a different question here (if I may venture to suggest). Is DNS 
rebinding attack in scope for the HTTP RFC? I mean, obviously it's 
possible to mount CSRF attacks against internal hosts, and that's well 
accepted, I suppose. The main 2 differences here are that the browser 
context belongs to the attacker's domain, and as such the browser 
doesn't send cookies, etc. on one hand, but does enable the attacker to 
read back the response. But essentially, it's not entirely different 
than CSRF in the sense that a third part site is accessed.

Also keep in mind that there's no ultimate solution (at least that I 
know of) to this problem. Even if very strict DNS binding is maintained 
by the browser, once you close the browser and re-open it (and the 
attacker switches DNS resolution in between), you're toast. In fact, 
that was the vector used in the original DNS rebinding attack (original 
text: http://viper.haque.net/~timeless/blog/11/, my explanation: item #5 
in 
http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00090.html).

To counter this kind of attack, you can start attaching IP addresses to 
cached resources, but it'll pretty quickly turn very ugly. So back to 
square one. No good solution.

Received on Thursday, 18 September 2008 18:55:53 UTC