7

So reading this blog post, I know how the password reset works and how it's exploitable, but in a real case scenario, how would XSS be possible? Is there a way to send a victim to a page with the host header edited?

Thank you!

Michael Blake
  • 751
  • 4
  • 12
  • 22

1 Answers1

3

The article mentions this example: http://carlos.bueno.org/2008/06/host-header-injection.html

i.e. cache can get served up to victims which will have them using the evil host header. This might even be done by the CDN / reverse proxy / load balancers etc directly in front of a big website, affecting a very large number of their visitors potentially depending on if the page is one which works well for cache hits. It could also be done by caching at ISP's etc which are out of reach for a site to be able to quickly fix it.

"The second half of the vulnerability comes when there is HTTP caching going on somewhere on the path between the site and users. This could be a caching proxy run by the site itself, or downstream in ISP proxies, content delivery networks (CDNs), syndicators, etc. This allows an attacker to potentially rewrite URLs on any page he wishes, and embed that exploited page in caches that may be beyond the control of the victim site."

pacifist
  • 814
  • 4
  • 9
  • 1
    Thank you for that. So from my understanding, it's only possible to exploit if they're storing cache? And how would I test that? I saw the example of a telnet request, but for it to be vulnerable, I'd have to make that request and open the site in my browser to see if it was stored in the cache? – Michael Blake Jan 07 '14 at 23:18
  • 2
    It's only possible if someone stores cache; your side, their side, or in the cloud. Presence of the cache hit with your browser would confirm its possible, but absence doesn't rule it out - by that I mean, if you get the (tampered) cache in your browser, yes, something cached it, but caching strategies vary and it's not guaranteed you'll trigger the cache so if you don't see it it doesn't mean someone else won't; maybe your browser requested it with something that invalidated the caching, or maybe you got load-balanced to something not caching it (yet), if caching were possible at any hops. – pacifist Jan 08 '14 at 02:47
  • 1
    This gives you an idea of the fragility of it: http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/

    Caching is both pervasive but can't be depended on.

     – pacifist Jan 08 '14 at 02:48