Let’s talk about cookies for a moment. Cookies, for the most part, are persistent. Sure, more browsers are trying to make it easier to reset cookies, but still, a fairly small group of users regularly remove cookies on each browser shutdown, or with enough regularity to make a difference. Now let’s talk about web servers. Web servers, for the most part, don’t care if you send a host header. If you send nothing, it’s the same as if you sent the host name. This has never seemed like a great idea to me, but nevertheless it’s really common, except in virtual hosting environments.
Lastly, let’s talk about DNS rebinding. The browser typically pins the DNS to the same IP-to-DNS mapping for the term of the browser session (DNS rebinding exploits notwithstanding). I’m not trying to discount DNS rebinding exploits for the moment, but rather, there may be another vector here, even if DNS rebinding ever does get “solved” by being able to map the IP to the DNS for the term of the browser session.
Now, remember, the cookies can outlive the browser session, and that is entirely based on how they are set, unless the user intentionally removes them. So let’s take a scenario of a message board that allowed crossdomain images. An attacker could submit two cross domain images. The first being to http://www.attacker.com/image.php and the second being http://victim.attacker.com/somefunction.php. The first image would set a cookie to test and see if the user had visited that domain before. If not it sets a cookie. The second domain (victim.attacker.com) sets a cookie that is designed to be used on www.victim.com.
At some point down the road, the user reboots their browser window. Later they go back to the same board and visit the www.attacker.com image which alerts the DNS for victim.attacker.com to switch to www.victim.com’s IP address. Although the hostname is wrong, the cookie is still sent. Since the cookie doesn’t contain any information to tell the server that it’s being sent a cookie from another subdomain, the server helplessly executes somefunction.php with the credentials set by the attacker.
While this won’t help an attacker gain access to the user’s cookies, it will allow them to set their own, which can have all sorts of nasty side effects, depending on what those cookies control. There are some XSS attacks that can only be performed by setting a cookie that contains the payload, which is normally a non-issue since being able to set a cookie cross domain is supposed to be impossible. However, this scenario would enable those attacks, unless it’s a requirement that that same cookie also contained session information that the attacker couldn’t know since they won’t be able to read the user’s original (legitimate) cookies for www.victim.com. Of course it’s just far easier to do this kind of exploit by just waiting for a certain amount of traffic to hit your site and then just switching the DNS over as well, but that’s just too easy of an attack. Anyway, it’s just a thought!