Which $_SERVER variables are safe?

Question

Any variable that a user can control, an attacker can also control and is therefore a source of an attack. This is called a "tainted" variable, and is unsafe.

When using $_SERVER, many of the variables can be controlled. PHP_SELF, HTTP_USER_AGENT, HTTP_X_FORWARDED_FOR, HTTP_ACCEPT_LANGUAGE and many others are a part of the HTTP request header sent by the client.

Does anyone know of a "safe list" or untainted list of $_SERVER variables?

Latterday

Depends on how you define "safe". The values are all safe as they are, it only depends what you use them for. – Roarke

I think in this context, Rook is saying "Which server variables can't be spoofed by the user", such as REMOTE_ADDR. – Submissive

Anything prefaced with HTTP_ is a request header and can be set by the browser or proxy in between. I would consider those as any other user input. – Shive

@vcsjones: REMOTE_ADDR can be spoofed, hijacked, or can be meaningless if client used a proxy. – Hellenist

@Hellenist REMOTE_ADDR is pulled directly from apache's TCP socket, this value cannot be spoofed over the Internet because of the three way handshake. – Latterday

@Rook: good point. I guess with the mention of "spoofing", I was more leaning towards the old act of ip spoofing itself, rather than any sort of faking the actual value of REMOTE_ADDR. And that would be out of the scope of this question. Good to get some insight into how this value is set though, so thanks. – Hellenist

@Rook, That depends on your SAPI. There is no guarantee that every web server will provide any of the stuff in $_SERVER, or even the "correct" values. – Gervais

Answer 1

There's no such thing as "safe" or "unsafe" values as such. There are only values that the server controls and values that the user controls and you need to be aware of where a value comes from and hence whether it can be trusted for a certain purpose. $_SERVER['HTTP_FOOBAR'] for example is entirely safe to store in a database, but I most certainly wouldn't eval it.

As such, let's divide those values into three categories:

Server controlled

These variables are set by the server environment and depend entirely on the server configuration.

• 'GATEWAY_INTERFACE'
• 'SERVER_ADDR'
• 'SERVER_SOFTWARE'
• 'DOCUMENT_ROOT'
• 'SERVER_ADMIN'
• 'SERVER_SIGNATURE'

Partly server controlled

These variables depend on the specific request the client sent, but can only take a limited number of valid values, since all invalid values should be rejected by the web server and not cause the invocation of the script to begin with. Hence they can be considered reliable.

• 'HTTPS'
• 'REQUEST_TIME'
• 'REMOTE_ADDR' *
• 'REMOTE_HOST' *
• 'REMOTE_PORT' *
• 'SERVER_PROTOCOL'
• 'HTTP_HOST' †
• 'SERVER_NAME' †
• 'SCRIPT_FILENAME'
• 'SERVER_PORT' ‡
• 'SCRIPT_NAME'

* The REMOTE_ values are guaranteed to be the valid address of the client, as verified by a TCP/IP handshake. This is the address where any response will be sent to. REMOTE_HOST relies on reverse DNS lookups though and may hence be spoofed by DNS attacks against your server (in which case you have bigger problems anyway). This value may be a proxy, which is a simple reality of the TCP/IP protocol and nothing you can do anything about.

† If your web server responds to any request regardless of HOST header, this should be considered unsafe as well. See How safe is $_SERVER[“HTTP_HOST”]?.
Also see http://shiflett.org/blog/2006/mar/server-name-versus-http-host.

‡ See https://bugs.php.net/bug.php?id=64457, http://httpd.apache.org/docs/current/mod/core.html#usecanonicalphysicalport, http://httpd.apache.org/docs/2.4/mod/core.html#comment_999

Entirely arbitrary user controlled values

These values are not checked at all and do not depend on any server configuration, they are entirely arbitrary information sent by the client.

• 'argv', 'argc' (only applicable to CLI invocation, not usually a concern for web servers)
• 'REQUEST_METHOD' §
• 'QUERY_STRING'
• 'HTTP_ACCEPT'
• 'HTTP_ACCEPT_CHARSET'
• 'HTTP_ACCEPT_ENCODING'
• 'HTTP_ACCEPT_LANGUAGE'
• 'HTTP_CONNECTION'
• 'HTTP_REFERER'
• 'HTTP_USER_AGENT'
• 'AUTH_TYPE' ‖
• 'PHP_AUTH_DIGEST' ‖
• 'PHP_AUTH_USER' ‖
• 'PHP_AUTH_PW' ‖
• 'PATH_INFO'
• 'ORIG_PATH_INFO'
• 'REQUEST_URI' (may contain tainted data)
• 'PHP_SELF' (may contain tainted data)
• 'PATH_TRANSLATED'
• any other 'HTTP_' value

§ May be considered reliable as long as the web server allows only certain request methods.

‖ May be considered reliable if authentication is handled entirely by the web server.

The superglobal $_SERVER also includes several environment variables. Whether these are "safe" or not depend on how (and where) they are defined. They can range from completely server controlled to completely user controlled.

Roarke

Thank you, Deceze. I can't verify it's all accurate, but I can hope that it will become canonical. – Nial

@Jared Please feel free to edit if there are any inaccuracies. – Roarke

@Roarke - Nothing looks out of place to me, but I'm admittedly not particularly well-versed on this type of thing. – Nial

@deceze: good analysis for the basic ones. There's 20 or so more depending on the PHP version, OS or CLI vs cgi/iis/apache mod usage, but not commonly used. – Hellenist

@bob By all means, please add them. :) – Roarke

@bob It (AFAIK) means the server does a DNS lookup on the REMOTE_ADDR IP. How it does this exactly and whether the DNS lookup can be attacked depends entirely on the server in question. – Roarke

@deceze: sorry, my self-censored comment I think answered itself. But regarding the several other obscure $_SERVER values, I admittedly am not familiar with their true source, even though they appear to be safe (system paths, settings, etc). – Hellenist

Also i have no idea why you put clearly tainted variables as "reliable", i went ahead and fixed that. – Latterday

this is one of the hell answer there – Unmindful

@Roarke You have an incorrect view of security. Everything that comes from a user could also be coming from an attacker and is there for unsafe. – Latterday

@Rook But as I said, it absolutely depends on how you use it. Values just by themselves are neither safe nor unsafe, it depends on what you use them for. Even data sent from a nefarious user is perfectly safe as long as you're not doing anything with it that may compromise your security. – Roarke

@Roarke I am writing a patch for PHP-IDS, they are all unsafe for my purposes. Your list was very misleading until modification. I think that a question like this should not have a "shoot from the hip" approach, and requires some rigor. – Latterday

@Rook: your idea of "safe" makes this question seem a bit arbitrary, especially since it's entirely tied to an obscure extension or custom version of PHP. While you say "should not have a "shoot from the hip" approach", any answer actually seems to require at minimum familiarity with PHP sourcecode to find out how these values are set. Would emailing PHP devs not be a better approach to finding an answer? – Hellenist

@Hellenist acutally my mind is completely blown. I thought i could just say "safe" and nothing else and everyone would immediately understand it. But i should have realized that people don't have a clue what a taint or what a sink is, and are really just wondering around blind implementing vulnerabilities as they go. – Latterday

@Rook: Miscommunication. As deceze hinted at, "safe for what purpose". As I hinted at, your purpose is unknown, and besides there are several other undocumented $_SERVER values depending on how the file is served. In my opinion, the documented ones don't clarify the true source. Otherwise I believe you wouldn't be asking this question. Glad you got a list you can use. But I'd still suggest submitting a bug report (when their bug site is fixed), sending doc maintainers an email, or updating the docs yourself (if you're privy to the link). It would benefit the community to know this info. – Hellenist

SERVER_NAME is not necessarily controlled by the server. Depending on gateway and settings it may be duplicated from HTTP_HOST and hence subject to the same caveat. – Incendiarism

Be careful with REMOTE_HOST. It might be semi-reliable, but not safe for all purposes: its value can be controlled by the attacker. For instance, I would not recommend eval-ing it. An attacker could register a domain name with a malicious name or possibly with strange characters in it. Remember, the attacker controls the domain names, so this variable is mostly controlled by the attacker. There are of course some constraints on its value imposed by the DNS protocol, but I would be wary of relying upon that for security. – Muldon

@Muldon I did note that to some degree and I'm not sure why you'd want to eval it, but good point nonetheless. – Roarke

this should be copied as a user comment into the php manual somewhere. – Miliaria

@Roarke @Rook Does SERVER_PORT need that little cross? bugs.php.net/bug.php?id=64457 – Essam

@TOOTSKI Apparently it does. Thanks! – Roarke

@Roarke Thanks! I have documented it in PHP manual right after opening the bug. Would you mind if I add legend to each variable based on your answer? – Essam

@TOOTSKI Sure. This would also hopefully get more eyes to look at the issue and find those special cases as you did. – Roarke

@deceze, re "arbitrary"; Not entire arbitrary as they conform to a format. For instance, QUERY_STRING cannot contain newline characters under most sapis. – Gervais

Why is SCRIPT_NAME not in the safe ones? – Mistletoe

Answer 2

In PHP every $_SERVER variable starting with HTTP_ can be influenced by the user. For example the variable $_SERVER['HTTP_REINERS'] can be tainted by setting the HTTP header REINERS to an arbitrary value in the HTTP request.

Klute

re "arbitrary"; Not entire arbitrary as they conform to a format. For instance, $_SERVER['HTTP_REINERS'] cannot contain newline characters under most sapis. – Gervais