PHP security-source code exposure (2)

## Source code exposed

Your WEB server must be able to read your source code and execute it. This means that when the code written by anyone is run by the server, it can also read your source code. On a shared hosting, the biggest risk is that because the WEB server is shared, PHP code written by other developers can read arbitrary files.

 <?php
 
  header(&#39;Content-Type: text/plain&#39;);
  readfile($_GET[&#39;file&#39;]);
 
  ?>

## By running the above script on the host where your source code resides, an attacker can cause the WEB server to read and display any file by specifying the file value as a full path and file name. For example, assuming that the script is named file.php and is located on the host example.org, the contents of the file /path/to/source.php can be exposed by accessing the following link:

http://www.php.cn/

Of course, for this simple code to work, an attacker would have to know exactly where your source code is, but an attacker could write a more complex script that would allow them to browse the entire file system. For such scripts, see the examples later in this chapter.

There is no perfect solution to this problem. As discussed in Chapter 5, you must consider that all of your source code is public, even code that is stored outside of your home WEB directory.

The best approach is to keep all sensitive data in a database. While this adds an extra layer of complexity to writing some code, it's the best way to prevent your sensitive data from being exposed. Unfortunately, there is another problem. How to save your database access password?

Please look at a file named db.inc saved outside the main directory of the website:

 <?php
 
  $db_user = &#39;myuser&#39;;
  $db_pass = &#39;mypass&#39;;
  $db_host = &#39;localhost&#39;;
 
  $db = mysql_connect($db_host, $db_user,
$db_pass);
 
  ?>

If the path to the file is known (or guessed), there is a possibility that another user on your server accesses the file and will gain database access, so that all the data you save in the database will be will be exposed.

The best solution to this problem is to save your database access permissions in a file that can only be read by system administrators in the following format:

 SetEnv DB_USER "myuser"
  SetEnv DB_PASS "mypass"

## SetEnv is an Apache command. The above file means to create two Apache environment variables that represent your database username and password respectively. Of course, the key to this trick is that only system administrators can read the file. If you can't log in as a system administrator, you can restrict the file to being readable only by yourself, which is a similar protection method as above.

 $ chmod 600 db.conf
  $ ls db.conf
  -rw-------  1 chris chris 48 May 21 12:34
db.conf

## This effectively prevents malicious scripts from gaining access to your data, so there is no significant risk to the security of sensitive data held in the database.

For this file to work, you need to be able to access the data in it through PHP. To achieve this goal, you need to write the following inclusion sentence in httpd.conf:

  Include "/path/to/db.conf"

It should be noted that this statement needs to be inserted in the VirtualHost area, otherwise other users can obtain the corresponding content.

Since the parent process of Apache runs as a system administrator (needs to bind to port 80), it is able to read the configuration file, but the child process that handles server requests (running PHP scripts) cannot read the file.

You can access these two variables through the $_SERVER super global array, so in db.inc, you only need to reference the $_SERVER variable instead of stating the database permissions:

<?php
 
  $db_user = $_SERVER[&#39;DB_USER&#39;];
  $db_pass = $_SERVER[&#39;DB_PASS&#39;];
  $db_host = &#39;localhost&#39;;
 
  $db = mysql_connect($db_host, $db_user,
$db_pass);
 
  ?>

If the file is exposed, database access will not be compromised. This is a major security improvement for shared hosting, and it is also an in-depth defense method for independent hosting.

Note that when using the above technique, database access rights are located in the $_SERVER super public array. This requires also restricting ordinary visitors from running phpinfo() to view or any other reasons that cause the contents of $_SERVER to be exposed.

Of course, you can use this technique to protect any information (not just database access), but I find it more convenient to save most data in a database, especially since this technique requires assistance from your hosting provider.

The above is the content of PHP Security-Source Code Exposure (2). For more related content, please pay attention to the PHP Chinese website (www.php.cn)!