Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I noticed this bit of code in drupal_settings_initialize():
// We escape the hostname because it can be modified by a visitor.
if (!empty($_SERVER['HTTP_HOST'])) {
$cookie_domain = check_plain($_SERVER['HTTP_HOST']);
}
However, AFAIK that's already done earlier in the bootstrap by drupal_environment_initialize():
if (isset($_SERVER['HTTP_HOST'])) {
// As HTTP_HOST is user input, ensure it only contains characters allowed
// in hostnames. See RFC 952 (and RFC 2181).
// $_SERVER['HTTP_HOST'] is lowercased here per specifications.
$_SERVER['HTTP_HOST'] = strtolower($_SERVER['HTTP_HOST']);
if (!drupal_valid_http_host($_SERVER['HTTP_HOST'])) {
// HTTP_HOST is invalid, e.g. if containing slashes it may be an attack.
header($_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request');
exit;
}
}
Comment | File | Size | Author |
---|---|---|---|
#1 | 668932-duplicate-sanitizing-http-host.patch | 997 bytes | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedAgreed. The
check_plain()
call was a last-resort measure, but we now have a proper sanitizing for this field.Comment #3
agentrickardConfirmed that the operation order is correct. Patch passes review, too.
Comment #4
webchickAh, fun in a debugger. :)
Committed to HEAD.