Re: Security considerations for DNS rebinding

On Feb 9, 2010, at 10:23 AM, Amit Klein wrote:

> Note that Host header verification is only effective if it can be
> guaranteed that the client side cannot forge it - see

I see some specific IE vulnerabilities cited here which allow the Host header to be forged via request splitting over a proxy: <> It also cites some old Mozilla bugs that enabled header injection. And also some Flash vulnerabilities

Do these vulnerabilities or any similar ones still exist in current versions of browsers or in Flash?


> Thanks,
> -Amit
> On Tue, Feb 9, 2010 at 8:08 PM, Adam Barth <> wrote:
>> On Tue, Feb 9, 2010 at 6:23 AM, Tim <> wrote:
>>>> The DNS Spoofing security considerations subsection has a
>>>> requirement that actually increases the risk of DNS rebinding attacks.
>>>> It says that "If HTTP clients cache the results of host name lookups
>>>> in order to achieve a performance improvement, they must observe the
>>>> TTL information reported by DNS". Clients that follow this advice will
>>>> be at greater risk than if they give cached DNS lookup results a floor
>>>> on time-to-live, or keep a DNS resolution result "pinned" so long as
>>>> any resource from that domain is active. Those are the simplest
>>>> client-side mitigation strategies for DNS rebinding attacks. If DNS
>>>> lookups are cached in the browser for a minimum of, say, an hour,
>>>> there is much less risk of a DNS rebinding attack, because the
>>>> attacker must get the user to keep a page open for at least an hour to
>>>> be able to perform the rebinding attack.
>>> While I'm not an expert on DNS rebinding, I'm afraid I don't agree
>>> that DNS pinning helps prevent rebinding attacks.
>> DNS pinning is not a great solution to DNS rebinding, and I would
>> hesitate to recommend it to user agent implementors.  For details,
>> please see:
>> On the other hand, Host header checking is effective, and it seems
>> valuable for HTTPbis to recommend it to server implementors.
>> Adam

Received on Tuesday, 9 February 2010 18:51:54 UTC