php inc file use risks and considerations
- 2020-11-18 06:08:29
- OfStack
One of the main concerns in database usage is the exposure of user name and password for access rights. In programming, 1 db. inc file is generally saved for convenience, such as:
User names and passwords are sensitive data and require special attention. They pose a risk by being written in source code, but this is an unavoidable problem. If you don't, your database won't be protected by username and password.
If you've read the default version of http.conf (Apache's configuration file), you'll notice that the default file type is text/plain (plain text). This poses a risk if a file like db.inc is saved in the root of the web site. All resources located in the root of the site have the corresponding URL, and since Apache does not define the type of handling for files with the.inc suffix, access to such files is returned as plain text (the default type), thus exposing access to the client's browser.
Risk in order to further illustrate this, consider 1 1 / www as web site under the root directory of the server, if db inc are stored in/www/inc, it has own URLhttp 1: / / example org/inc/db inc (assuming example org is host domain name). By accessing this URL, you can see the source file of ES31en.inc displayed as text. No matter which subdirectory you store the file in /www, there is no way to avoid the risk of access exposure.
The best solution to this problem is to save it in an inclusion directory other than the site root. You don't need to put them in a specific location on the file system for the purpose of including them, all you need to do is make sure that the Web server has read access to them. Therefore, there is no necessary risk in putting them in the root of the site, and any effort to reduce the risk is futile as long as the containing files remain in the root of the site. In fact, all you need to do is place the resources you must access through URL in the root of your site. After all, this is a public directory.
The previous topic is also useful for the SQLite database. Keeping the database in the current directory is very convenient because you only need to call the filename without specifying the path. However, keeping the database in the root of the site represents an unnecessary risk. Your database is at risk if you don't have security in place to prevent direct access.
If external factors make it impossible to place all the contained files outside the site root, you can configure Apache to reject requests for.inc resources.
It would make sense to write it this way just to give you an example, because after all you've learned some tricks, but this example is a little bit stiff. In fact, just rename the file db.inc.php. It is as if a hole is broken in the house and not repaired, and then a bigger house is built outside to put the broken house in place.
Later you can see another way to protect against database access exposure, which is very effective in a Shared server environment where the files are exposed even though they are outside the root of the site.
<?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 and require special attention. They pose a risk by being written in source code, but this is an unavoidable problem. If you don't, your database won't be protected by username and password.
If you've read the default version of http.conf (Apache's configuration file), you'll notice that the default file type is text/plain (plain text). This poses a risk if a file like db.inc is saved in the root of the web site. All resources located in the root of the site have the corresponding URL, and since Apache does not define the type of handling for files with the.inc suffix, access to such files is returned as plain text (the default type), thus exposing access to the client's browser.
Risk in order to further illustrate this, consider 1 1 / www as web site under the root directory of the server, if db inc are stored in/www/inc, it has own URLhttp 1: / / example org/inc/db inc (assuming example org is host domain name). By accessing this URL, you can see the source file of ES31en.inc displayed as text. No matter which subdirectory you store the file in /www, there is no way to avoid the risk of access exposure.
The best solution to this problem is to save it in an inclusion directory other than the site root. You don't need to put them in a specific location on the file system for the purpose of including them, all you need to do is make sure that the Web server has read access to them. Therefore, there is no necessary risk in putting them in the root of the site, and any effort to reduce the risk is futile as long as the containing files remain in the root of the site. In fact, all you need to do is place the resources you must access through URL in the root of your site. After all, this is a public directory.
The previous topic is also useful for the SQLite database. Keeping the database in the current directory is very convenient because you only need to call the filename without specifying the path. However, keeping the database in the root of the site represents an unnecessary risk. Your database is at risk if you don't have security in place to prevent direct access.
If external factors make it impossible to place all the contained files outside the site root, you can configure Apache to reject requests for.inc resources.
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>
It would make sense to write it this way just to give you an example, because after all you've learned some tricks, but this example is a little bit stiff. In fact, just rename the file db.inc.php. It is as if a hole is broken in the house and not repaired, and then a bigger house is built outside to put the broken house in place.
Later you can see another way to protect against database access exposure, which is very effective in a Shared server environment where the files are exposed even though they are outside the root of the site.