|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Submitted: 2013-03-19 19:03 UTC Modified: 2016-06-20 15:27 UTC
Avg. Score:3.0 ± 1.3
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: Assigned: cmb (profile)
Status: Closed Package: Documentation problem
PHP Version: Irrelevant OS: All
Private report: No CVE-ID: None
 [2013-03-19 19:03 UTC]
`HTTP_HOST` is the value from `Host` header, which can, naturally, be spoofed.
On the other hand, `SERVER_NAME` and `SERVER_PORT` should reflect real values.
I've tested some configurations and on majority you can at least change/spoof `SERVER_PORT`.
This can lead to security issues since these environment variables are often trusted.

Test script:

$ch = curl_init('');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host:'));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
echo curl_exec($ch);





Expected result:
string(16) "" string(2) "80"

Actual result:
string(9) "" string(4) "1337"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-19 19:16 UTC]
But how is this a PHP issue? PHP doesn't set the $_SERVER['HTTP_*"] variables at 
all. They are inherited directly from the web server and are the same variables 
that the web server would set for CGI scripts that might get executed. So while 
we could try to do some analysis and filtering at the PHP level, anything else 
the web server invokes would still be getting the spoofed port. The fix should be 
at the web server level.
 [2013-03-19 19:16 UTC]
-Status: Open +Status: Analyzed
 [2013-03-19 19:38 UTC]
Indeed, it's not a PHP issue per se, and I'm glad, thank you.

I'm aware that $_SERVER['HTTP_*'] are passed on, but what about $_SERVER['SERVER_*'] (or you meant everything web server related)?
Why would Apache not know what is the hostname and which port is it serving through?

Nginx and some variations of Apache (haven't tried sending HTTP 1.0 request) settings don't have this "problem".
RFC 2616 states that 1.1 requests specifying a hostname not in use by the server should receive a 400 Bad Request response, which is sometimes (I don't know when exactly) is not the case.

 [2013-03-19 20:58 UTC]
I have no idea why it is filling in the wrong SERVER_PORT, but it is. This 
doesn't come from PHP and it isn't PHP's job to second-guess what the web server 
is telling us here. Try to reproduce it with a straight CGI script without any 
PHP involvement.
 [2013-03-22 16:56 UTC]
With the help of thumbs from #httpd, I was directed to:

It was pointed out:

So, PHP is kept in the dark if these directives are Off.

On our side, docs should be updated to advise that values are not be trusted if aforementioned directives are Off.
 [2013-03-22 16:59 UTC]
-Package: Apache2 related +Package: Documentation problem
 [2016-06-20 15:27 UTC]
Automatic comment from SVN on behalf of cmb
Log: Fix #64457: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing
 [2016-06-20 15:27 UTC]
-Status: Analyzed +Status: Closed -Assigned To: +Assigned To: cmb
 [2016-06-20 15:27 UTC]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.
 [2020-02-07 06:07 UTC]
Automatic comment on behalf of cmb
Log: Fix #64457: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Oct 21 12:03:33 2021 UTC