Custom $_SERVER vars

PHP
1

While all hardcore PHP developer out there knows that $_SERVER variables can be manipulated, I’m curious to see what modern implementations/practices are there that we can incorporate on our application. I’ve known this fact for quite sometime but didn’t really given it much thought, not until now where my application will be subjected to a professional ethical hacking company. Unless you’ve experience that, I’m pretty sure you don’t know the pressure I’m feeling right now :smiley:

Another question: do we have any modern tools/ways to be able to read the contents of $_SERVER variables on sites? Is there a way that i can see those values when I visit, say, www.myhackproofsite.com?

2

If there is I don’t think anyone here will willingly tell you how to do it because this community is based on web design and helping to secure things - not helping you to attack peoples websites.

3

I simply want to know if its technically possible, because if that is the case, then its no use relying on Server vars, all they could do is to add another layer of protection so to speak. I wasn’t really asking for specifics. And that was just a followup question, my main reason for posting was to ask for best practices/alternatives to using server vars. Still, thanks man for your input…

4

As I’ve already said, no-one here is going to tell you that even with your response which denies wanting to do anything bad.

It’s down to you how you code but nearly all php coders use the $_SERVER vars in their scripts somewhere. I don’t understand why it worries you so much unless you truly want to find a vulnerability to attack.

$_SERVER vars are set by php itself - not by any form submission or url requests which can be changed at runtime.

5

I’m sorry to break it to you, but as I’ve said in my first post, $_SERVER vars can be manipulated. No, it is not created by PHP, but is actually sent by the browser your using. Its very easy for me to specifically make $_SERVER[‘HTTP_REFERRER’] = “www.google.com” on your receiving php script.

6

You’re not breaking anything to me. Yes they can be manipulated by any script you as the webmaster run - but they only remain this way for the duration of the scripts execution. The next script that runs will find the default values. This was not what you were asking though - You were asking about visitors / attackers being able to change them and if they could, how.

7

Treat those like any other vars and escape whatever you need to escape for each use :

  • remove html entities if it’s to be displayed
  • remove \r
    sequences for email and redirects or other headers
  • use prepared statements for your SQL
  • sanitize for use in exec() statements
  • be carefull with paths
  • beware of log poisoning
8

It is important to note what $_SERVER is. This superglobal holds information about the page request as given to PHP by the webserver program (usually Apache, could be anything depending on your setup). Most of it’s contents change with each and every page request.

Here’s the list and their level of vulnerability - safe (they cannot be set by a remote attacker) or unsafe (they can be set by a remote attacker). Notes on the vulnerabilities given where appropriate. All unsafe variables can at the very least be used for an SQL injection attack if you attempt to log them into the database.

  • ‘PHP_SELF’: Safe.
  • ‘GATEWAY_INTERFACE’: Safe
  • ‘SERVER_ADDR’: Safe
  • ‘SERVER_NAME’:
  • ‘SERVER_SOFTWARE’
  • ‘SERVER_PROTOCOL’
  • ‘REQUEST_METHOD’: There are only 4 valid values for this - GET, POST, PUT or HEAD. You can harden your site with this knowledge by requiring the operation the user is requesting to match the method of request. For example - technically speaking your script should only perform a write operation on POST or PUT requests. This is known as a restful state approach.
  • ‘REQUEST_TIME’: Safe
  • ‘QUERY_STRING’: Unsafe. The parsed version of this becomes the $_GET superglobal, so you should rarely need to reference this.
  • ‘DOCUMENT_ROOT’: Safe
  • ‘HTTP_*’: All members of the $SERVER array starting in HTTP are unsafe. They are also the most frequently used path of attack - particularly HTTP_REFERRER and HTTP_USER_AGENT since many scripts attempt to look at these to learn about the visitor. These are the request headers and are entirely subject to the sender to set.
  • ‘HTTPS’: Safe, usually set to merely 1 or left unset if the page isn’t being accessed by secure protocol.
  • ‘REMOTE_ADDR’: Unreliable. The user can falsify this, though it still must be a valid IP (I think). Be careful.
  • ‘REMOTE_HOST’: As above.
  • ‘REMOTE_PORT’: As above.
  • ‘SCRIPT_FILENAME’: Safe
  • ‘SERVER_ADMIN’: Safe as long as your httpd.conf and .htaccess files are uncompromised.
  • ‘SERVER_PORT’: Safe
  • ‘SERVER_SIGNATURE’: Safe
  • ‘PATH_TRANSLATED’: Safe, but varies with server.
  • ‘SCRIPT_NAME’: Safe. Also found in the magic constant FILE
  • ‘REQUEST_URI’: Safe if mod_rewrite is not in use, unsafe if it is in use (since a wide range of requests could be mapped back to the script). How vulnerable the script is to attack by this vector is determined by how lenient the mod_rewrite rules are, but on many sites everything goes over to the PHP script so this is a credible attack vector.
  • ‘PHP_AUTH_DIGEST’: Unsafe.
  • ‘PHP_AUTH_USER’: Unsafe.
  • ‘PHP_AUTH_PW’: Unsafe. – All three of these are used for PHP driven http authorization, and like all inputs from the client should be treated as unsafe.
  • ‘AUTH_TYPE’: Unsafe
  • ‘PATH_INFO’: Unsafe.
9

And there was me thinking that not telling this person about any weaknesses was a good idea. He’s quite clearly asking how to find a websites vulnerabilities :rolleyes:

10

Excuse me?

11

From the quote above he appears quite clearly to be asking how to determine a weakness on any website that could be exploited. If I’m wrong I apologise but you must admit it does seem a bit odd asking if there is any way to find vulnerbilities on a sites $_SERVER array and are there any tools out there to do it.

12

@Arkh and Michael Morris

Thank for your wonderful input! I honestly appreciate you taking the time and sharing your opinions.

To Micheal, your list was great. I actually tried to ‘hack’ to see if i can break my own code online. Currently I’m relying on SERVER_NAME, SERVER_ADDR and SCRIPT_FILENAME. I’ll see if I can make use of the other ‘safe’ parameters you suggest.

PS
You seem to know much about this topic. If I may follow up, when constructing a header for a page request like the code below, aside from HOST, REFERER and METHOD, what other paramneters can be manipulated that would appear in $_SERVER vars?


<?php 
$hdrs = array( 'http' => array(
    'method' => "POST",
    'header'=> "accept-language: en\\r\
" . 
        "Host: www.googlegame.com\\r\
" .
        "Referer: http://www.googlegame.com\\r\
" .  
        "Content-Type: application/x-www-form-urlencoded\\r\
" .
        "Content-Length: 23\\r\
\\r\
" .
        "username=user&score=100\\r\
"
    )
);
?>

@tangoforce
As Ive initially told you, I am merely asking for confirmation if checking server vars are possible. I never ask anyone to tell me/show me how. My purpose is that if they can be read, then there is no reason for me to use $_SERVER vars in the first place. I dont see which part you find odd about me asking. I clearly stated that the application will be subjected to an ethical hacking company, and thus I wanted to make sure my code prevents all possible attacks I’m aware of.

13

You can’t work on your own website security without knowing some of the vulnerabilities known. And there are tools to test common pitfalls which will try to automaticaly attack your website : http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/

14

Thanks for the link man. I read a bit about Acunetics but I didnt have enough time today to fully check it out. I look forward to trying it on the site tomorrow.