Child pages
  • [security] Possible "Host" header injections [5.2.1-B1]
Skip to end of metadata
Go to start of metadata

In-Portal might be vulnerable to Host header injections due following code in the startup.php:

if ( isset($_SERVER['HTTP_HOST']) ) {
	// accessed from browser
	$http_host = $_SERVER['HTTP_HOST'];
}
else {
	// accessed from command line
	$http_host = $vars['Domain'];
	$_SERVER['HTTP_HOST'] = $vars['Domain'];
}
 
define('SERVER_NAME', $http_host);

Later the SERVER_NAME constant is used to build absolute urls on the website. This way if attacker sends fake Host header then all links would lead to fake domain instead of ours (even though page url in browser would be from our domain).

Forcing to use domain from command line might solve the problem, but not for websites where site domains are used. There you can set wildcards for domain matching and you can't check even them in the startup.php because no database connection is created yet. 

More Info

Related Tasks

1 Comment

  1. Another host header attack is called "host header poisoning". For example if In-Portal is installed on "validsite.com", then passing following host header would make all links invalid:

    Host: validsite.com:random@evilsite.com

    It won't be as bad as for Django (see https://www.djangoproject.com/weblog/2012/oct/17/security/), but still not very user friendly.

    When such malformed (contains symbols, that hostname isn't allowed to have) host header encountered, then we:

    • use hostname from /system/config.php
    • throw an exception about malformed header to let user know, that he might be on unsecured network once application is initialized