Hi All, A few years back Carlos Bueno posted on this list about the possibility of using the HTTP Host header for cache poisoning. I've recently followed this up and had success poisoning both reverse proxies (Varnish in particular) and Joomla's internal application cache. In Joomla's case this gives attackers persistent XSS on the application's homepage (mercifully Joomla has caching disabled by default). It appears that crafted host headers can also be used to generate 'poisoned' password reset emails from deployable applications and frameworks like Gallery and Django. I've written the details up at http://www.skeletonscribe.net/http-host-header-attacks However, I've had trouble recommending a fix for these issues that is both convincing and convenient. Configuring servers to reject such attacks is relatively tricky judging by Django's series of flawed fixes, and forcing administrators to specify a whitelist of trusted hosts during installation/migration is yet another installation step that developers would rather avoid. Do any of you have thoughts on this? Cheers, James Kettle

Hi James, as this vulnerability is a cross-plattform issue, suggesting mitigations to fix the code *and* configurations of *all* involved systems may sound ridiculous, it's at least not practical, IMHO. This is where a WAF does its job very well, in particular if it supports virtual patching. Cheers, Achim Am 01.05.2013 01:46, schrieb albino: > Hi All, > > A few years back Carlos Bueno posted on this list about the possibility > of using the HTTP Host header for cache poisoning. I've recently > followed this up and had success poisoning both reverse proxies (Varnish > in particular) and Joomla's internal application cache. In Joomla's case > this gives attackers persistent XSS on the application's homepage > (mercifully Joomla has caching disabled by default). It appears that > crafted host headers can also be used to generate 'poisoned' password > reset emails from deployable applications and frameworks like Gallery > and Django. I've written the details up at > http://www.skeletonscribe.net/http-host-header-attacks > > However, I've had trouble recommending a fix for these issues that is > both convincing and convenient. Configuring servers to reject such > attacks is relatively tricky judging by Django's series of flawed fixes, > and forcing administrators to specify a whitelist of trusted hosts > during installation/migration is yet another installation step that > developers would rather avoid. Do any of you have thoughts on this? > > Cheers, > > James Kettle