PHP Security Basics Chapter 8 shared host source code exposure

8.1. Source Code exposure

Your web server must be able to read your source and execute it, which means thatCodeWhen the server is running, it can also read your source code. On a shared host, the biggest risk is that the Web server is shared, so the PHP code written by other developers can read arbitrary files.

 

<? PHP

 

Header ('content-type: text/plain ');

Readfile ($ _ Get ['file']);

 

?>

 

By running the above script on the host where your source code is located, attackers can specify the file value as the complete path and file name so that the Web server can read and display any file. For example, assume that the script is named file. php and is located on example.org. You only need to access the following link to expose the file/path/to/source. php:

Http://example.org/file.php? File =/path/to/source. php

 

Of course, to make this simple code take effect, attackers must know exactly where your source code is located. However, attackers can write more complex scripts to view the entire file system. For more information about this type of script, see the examples later in this chapter.

There is no perfect solution to this problem. As described in chapter 5, you must consider that all your source code is public, and even the code stored outside the home directory of the web.

The best way is to store all sensitive data in the database. Although this makes some code compilation more complex, it is the best way to prevent exposure of sensitive data. Unfortunately, there is another problem. How do I save your database access password?

See a file named dB. inc stored in the home directory of the website:

<? PHP

 

$ Db_user = 'myuser ';

$ Db_pass = 'mypass ';

$ Db_host = 'localhost ';

 

$ Db = mysql_connect ($ db_host, $ db_user, $ db_pass );

 

?>

 

If the path of the file is known (or guessed), another user on your server may access the file and obtain the database access permission, in this way, all data stored in the database will be exposed.

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

 

Setenv db_user "myuser"

Setenv db_pass "mypass"

 

Setenv is an Apache command. The preceding file indicates creating two Apache environment variables that represent your database username and password respectively. Of course, the key to this technique is that only the system administrator can read the file. If you cannot Log On As a system administrator, You can restrict that the file can only be read by yourself. This protection method is similar to the preceding method.

 

$ Chmod 600 dB. conf

$ Ls dB. conf

-RW ------- 1 Chris 48 May 21 12:34 dB. conf

 

This effectively prevents malicious scripts from accessing your data. Therefore, sensitive data stored in the database will not pose a major risk to security.

To make the file take effect, you need to be able to access the data through PHP. To achieve this goal, you need to write the following sentence in httpd. conf:

 

Include "/path/to/DB. conf"

 

Note that this statement must be inserted in the virtualhost region. Otherwise, other users can obtain the corresponding content.

Because Apache's parent process runs as a system administrator (which must be bound to port 80), it can read the configuration file, but the sub-process that processes server requests (run php scripts) the file cannot be read.

You can access these two variables through the $ _ server super Global Array. In this way, you only need to reference the $ _ server variable in db. Inc, instead of specifying the database permissions in it:

<? PHP

 

$ Db_user = $ _ server ['db _ user'];

$ Db_pass = $ _ server ['db _ pass'];

$ Db_host = 'localhost ';

 

$ Db = mysql_connect ($ db_host, $ db_user, $ db_pass );

 

?>

 

If the file is exposed, the database access will not be disclosed. This is a major security improvement for the shared host, and it is also a means of in-depth prevention for independent hosts.

Note that the database access permission is in the $ _ server super public array when you use the above technique. In this case, you need to restrict normal visitors to run phpinfo () or any other reason that causes the $ _ server content to be exposed.

Of course, you can use this technique to protect any information (not just database access permissions), but I find it easier to save most data in the database, this technique requires assistance from your host provider.