One of the main issues to be concerned about when using databases is the exposure of access permissions, that is, usernames and passwords. For convenience in programming, a db. inc file is usually used for storage, such:
Copy codeThe Code is as follows:
<? Php
$ Db_user = 'myuser ';
$ Db_pass = 'mypass ';
$ Db_host = '2017. 0.0.1 ';
$ Db = mysql_connect ($ db_host, $ db_user, $ db_pass );
?>
User names and passwords are sensitive data, so pay special attention to them. They are written in the source code to create risks, but this is an unavoidable problem. If you do not do this, your database will not be able to set the user name 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 (common text ). In this way, if files such as db. inc are stored in the root directory of the website, the risk is raised. All resources in the root directory of the website have URLs. type of the processing method for files suffixed with inc. when accessing this type of files, it will be returned as normal text (default type ), in this way, the access permission is exposed to the client's browser.
To further describe this risk, consider a server with/www as the root directory of the website, if db. inc is saved in/www/inc, which has its own URLhttp: // example.org/inc/db.inc (assuming example.org is a host domain name ). By accessing this URL, you can see the source file that db. inc displays in text mode. No matter which sub-directory you save the file in/www, the risk of access permission exposure cannot be avoided.
The best solution to this problem is to store it in a directory other than the root directory of the website. You don't need to place them to a specific location in the file system for the purpose of containing them. All you need to do is ensure that the Web server has read permission. Therefore, there is no need to put them under the root directory of the website. Any effort to reduce risks is futile as long as the files contained are still under the root directory of the website. In fact, you only need to put the resources that must be accessed through the URL under the root directory of the website. After all, this is a public directory.
The previous topic is also useful for SQLite databases. It is very convenient to store the database in the current directory, because you only need to call the file name without specifying the path. However, saving the database in the root directory of the website poses unnecessary risks. If you do not take security measures to prevent direct access, your database is in danger.
If external factors make it impossible to put all contained files out of the root directory of the website, you can configure Apache to reject requests to. inc resources.
Copy codeThe Code is as follows:
<Files ~ "\. Inc $">
Order allow, deny
Deny from all
</Files>
If you want to write this statement for an example, you can understand that, after all, you have learned some techniques, but this example is a little harder. In fact, you only need to rename the file db. inc. php. It is as if the house is broken through a hole rather than being repaired, but it is just like building a bigger house outside and setting up the house.
You can also see another method to prevent exposure of database access permissions. This method is applicable to the shared server environment (in this environment, although the file is located outside the root directory of the website, but there is still a risk of exposure) very effective.