Re: (issue 100) - security considerations

On 19/09/2008, at 5:59 AM, Amit Klein wrote:

>
> 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?

We can certainly discuss it, and have the option to add text warning  
implementers of the dangers, or even specifying protocol extensions to  
mitigate it, if the WG agrees that the problem is serious enough and  
it can be done in a backwards-compatible fashion.


> 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.

If that's indeed the case, it seems to me that it might be worth  
raising this to the APPS area or IETF overall, as it's not just going  
to affect HTTP, and it likely needs to be fixed in DNS, rather than  
just HTTP implementations. Anyone aware if this sort of discussion is  
already going on somewhere else in the IETF? Security area, or DNSEXT,  
perhaps?


Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com

Received on Thursday, 2 October 2008 02:37:52 UTC