One of the major issues to be concerned with in database usage is access rights, the exposure of user names and passwords. In the programming for the convenience, generally will use a db.inc file to save, for example:
Copy Code code as follows:
<?php
$db _user = ' myuser ';
$db _pass = ' mypass ';
$db _host = ' 127.0.0.1 ';
$db = mysql_connect ($db _host, $db _user, $db _pass);
?>
User names and passwords are sensitive data that require special attention. They are written in the source code to create the risk, but this is an unavoidable problem. If you do not, your database will not be able to set the username and password for protection.
If you have read the default version of http.conf (Apache configuration file), you will find that the default file type is Text/plain (normal text). This raises the risk if a file such as Db.inc is saved in the root directory of the Web site. All resources located in the root directory of the site have corresponding URLs. Because Apache does not define the type of processing for a file of the. inc suffix, when accessing this type of file, it returns (the default type) as plain text, so that access is exposed to the client's browser.
To further illustrate this risk, consider a server that takes/www as the root of the Web site, and if Db.inc is saved in/www/inc, it has a self urlhttp://example.org/inc/db.inc ( Suppose example.org is the host domain name. By accessing the URL, you can see the source file that Db.inc is displayed as text. Whether you save the file in/www which subdirectory, you cannot avoid the risk of exposure to access rights.
The best solution to this problem is to save it in the Include directory outside the root directory of the Web site. You don't have to put them in a specific location in the file system to achieve the purpose of containing them, all you have to do is make sure that the Web server has read access to them. Therefore, it is not necessary to put them in the root directory of the site, as long as the included files are located in the root directory of the site, any risk reduction effort is futile. In fact, you simply place the resources that must be accessed through the URL in the root directory of the site. After all, this is a public directory.
The previous topic is also useful for SQLite databases. It is convenient to keep the database in the current directory because you simply call the filename without specifying the path. However, keeping the database in the root directory of the Web site represents an unnecessary risk. If you don't use security measures to prevent direct access, your database is in danger.
If it is not possible to place all the included files outside the site root directory because of external factors, you can configure the Apache to reject requests for. Inc Resources.
Copy Code code as follows:
<files ~ "\.inc$" >
Order Allow,deny
Deny from all
</Files>
If it is only for an example to write this, you can understand, after all, we have learned some means, but this example is a bit blunt. As a matter of fact, just rename the file to db.inc.php. It was as if the house had broken a hole instead of mending it, but was outside to build a bigger house and put the broken house together.
You can also see another way to prevent database access from being exposed, which is very effective for a shared server environment in which the risk of exposure is still present, although the file is located outside the root directory of the Web site.
