PHP security - access rights exposed

Access rights exposed

One of the main issues to be concerned about when using a database is the exposure of access rights, i.e. username and password. For convenience in programming, a db.inc file is generally used to save it, such as:

CODE:

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

Username and password are sensitive data and require special attention. The fact that they are written in the source code creates risks, but it is an unavoidable problem. If you don't do this, your database won't be protected with a username and password.

If you read the default version of http.conf (Apache's configuration file), you will find that the default file type is text/plain (plain text). In this way, if a file like db.inc is saved in the root directory of the website, it will cause risks. All resources located in the root directory of the website have corresponding URLs. Since Apache does not define the type of processing method for files with the .inc suffix, when accessing this type of file, it will be returned in the form of ordinary text (the default type ), so that access rights are exposed to the client's browser.

To further illustrate this risk, consider a server with /www as the root directory of the website. If db.inc is stored in /www/inc, it has its own URL http://www.php.cn/ (assuming example .org is the host domain name). By accessing this URL, you can see the source file of db.inc displayed in text mode. No matter which subdirectory of /www you save the file, you cannot avoid the risk of access permission exposure.

The best solution to this problem is to save it in an include directory outside of the website root. You don't have to put them in a specific location on the file system in order to include them, all you need to do is make sure the web server has read access to them. Therefore, there is no unnecessary risk in placing them in the website root directory, and any efforts to reduce the risk are in vain as long as the included files are located in the website root directory. In fact, you only need to place the resources that must be accessed through URLs in the root directory of the website. After all, this is a public directory.

## The previous topics are also useful for SQLite databases. Saving the database in the current directory is very convenient because you only need to call the file name without specifying a path. However, storing the database in the root directory of the website represents an unnecessary risk. If you don't use security measures to prevent direct access, your database is at risk.

If it is impossible to place all include files outside the website root directory due to external factors, you can configure Apache to deny requests for .inc resources.

CODE:

<Files ~ "\.inc$">
  Order allow,deny
  Deny from all
</Files>

Translation Note: If I write this just because I want to give an example, it is understandable. After all, everyone has learned some methods, but this example is a bit blunt. In fact, just rename the file to db.inc.php. It is like not repairing a hole in a house but building a bigger house outside to cover the broken house.

In Chapter 8 you can also see another way to prevent database access from being exposed, which is very effective in a shared server environment (where there is still a risk of exposure even though the files are located outside the website root) .

The above is the content of PHP security-access permission exposure. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!