RSnake and Dan Kaminsky have been talking about session fixation via DNS Rebinding.  As you may recall, an attacker can't abuse your Foo.com cookies in a rebinding attack, though they can walk your browser around Foo.com content and control the session.  The gist of what these guys are talking about is how the attacker can log the victim into the attacker's session.  Interesting stuff...

Dan and RSnake are big on server-side Host header validation as an anti-rebinding strategy.  Every time I starting thinking about this, here's my basic train of thought:

1. Host header validation is simple, and simple is good.  If you implement Host header validation at the server, it just works.
   
   
2. But what about everybody who doesn't conform?  Most web sites don't conform today, and if they do it's not particularly intentional.  I'd hate to see webappsec spend the next 10 years beating up the web properties that don't confirm.  We'd inch the web towards real security in a sort of hostile manner.  There must be a better way...
   
   
3. So coming at this from the other side -- what can the client-side do to help?  The hope there is to not only empower the user to verify their rebinding defenses on any given site, but also to put leverage on the server-side to implement Host header validation (to avoid getting blocked at the more secure clients).  As of now, a simple, practical, and comprehensive client-side anti-rebinding strategy remains elusive.  And if client-enforced Host header validation requires a server-side tweak, say a Host header on the response, that puts us back to the problem in #2 above.
   
   
4. So with all of this, why isn’t "use SSL" the simple anti-rebinding strategy?  In the near term, is there really a better answer?
   

Now, all this being said, I think the Rebinding threat is still yet to be fully defined.  It's possible that some interesting anti-rebinding strategies we see will develop out of a need to address specific attack scenarios identified over time.