PHP Security Error Top 7

Security | error

PHP is a scary language for fast-growing dynamic websites. It also has a lot of friendly properties for beginners, such as a variable that doesn't need to be defined to be used directly. However, some of these similar properties make it less likely that programmers will notice some security problems with the application of the Web site. A very famous mailing list is full of examples of vulnerabilities to PHP applications, but once you understand these basic vulnerabilities in PHP applications, PHP will become more secure than any other language.

In this article, I'll explain in detail the common errors that lead to security problems in general PHP programs. And it will show you what you can't do and how these particular vulnerabilities have been discovered, and I hope you will not only know how to avoid these particular mistakes, but also how they can lead to security issues. Understanding each potential vulnerability can help you avoid the same error when writing PHP programs. Security is a process, not a product, which allows you to develop more efficient and robust code by understanding security issues during the development of your application.

unvalidated input Errors An error of not being valued
One of the most common PHP security issues is the vulnerability to filtering user input. General User submissions are not trusted. You should assume that all users who visit your site are malicious. Non-normal input is the most fundamental reason for many PHP application vulnerabilities, which we will discuss later.
Now to give you an example, you can write the following code to allow the user to see that a special month can be displayed by executing a CAL command in UNIX.

$month = $_get[month];
$year = $_get[year];

EXEC ("Cal $month $year", $result);
print "<PRE>";
foreach ($result as $r) {print $r <BR>;}
print "</PRE>";

There are a lot of security issues with this piece of code. For example, $_get[month] and $_get[year] are directly assigned to $month and $year without filtering, and if the user enters a month between 1 and 12, and the year is 4 digits, of course, there is no problem. However, a malicious user adds a "; Ls-la" after the year so that he can see all of your site's directories in a list. More extreme users will add "RM-RF" after the year so they can erase your entire site!
The best way to correct this security problem is to check the data that is entered by the user and make it the format you want. Do not use JS to verify that this validation can easily be bypassed, such as the establishment of a table forms submit data, or browser to disable JS. You should use PHP code to make sure that the year and month you enter are numbers, and that you must be a number. Just like the following code:

$month = $_get[month];
$year = $_get[year];

if (!preg_match ("/^[0-9]$/", $month)) Die ("Bad month, please re-enter.");
if (!preg_match ("/^[0-9]$/", $year)) Die ("Bad year, please re-enter.");

EXEC ("Cal $month $year", $result);
print "<PRE>";
foreach ($result as $r) {print $r <BR>;}
print "</PRE>";

Such code can be used safely, regardless of the data submitted by the user will cause errors in your application or cause the server to run user submitted illegal code. Regular expressions are a very effective tool for validating data. Although it is difficult for him to fully grasp, in this case is very practical.
You should verify the data submitted by the user to reject all illegal data. Be sure not to receive any data until you have verified it, unless you can determine that it must be secure data. This is a common security issue. Sometimes, however, a malicious user submits some specific data in a way that bypasses your validation and can have a detrimental effect.
So you should strictly validate the submitted data, if some characters are not needed, then you should filter out these characters or directly refuse to receive the data.

Access Control FlawsIllegal control vulnerabilities
This is an unnecessary validation for PHP applications, but it is very important to have illegal control. For example, there is a management page where you can modify the configuration of a Web site or display some sensitive information.
You should check the user's permissions while executing every PHP application page. If you only check the user's permission on the homepage, the malicious user can enter the address in the Address bar directly to enter the following pages that do not have permission to judge.
A rigorous examination is recommended. If possible, you can judge their permissions according to the user's IP. Another good way to do this is to put the page you don't want someone to access into a special directory and use the. htaccess in Apache to protect the directory.
Put the site's profile outside the directory where the site can be accessed directly. This configuration file includes the password for the database and other information that would allow a malicious user to exploit your site. Include these files in PHP with the include function. Although it feels a little superfluous to do these things, it has a positive effect on the safety of the website.
For example, I write PHP applications. All of the custom library functions are placed in a includes folder. Generally take these included files to a file name with a. php suffix so that even if your protection is bypassed, the server will parse the files as php files without displaying the contents of those files. The WWW and admin folders are the only folders that can be accessed directly through the URL. The Admin folder is protected by. htaccess, allowing only users who know the user name and password stored in. htpasswd to be accessible.
/home
/httpd
/www.example.com
. htpasswd
/includes
cart.class.php
config.php
/logs
Access_log
Error_log
/www
index.php
/admin
. htaccess
index.php
You should set your Apache default home page name to be index.php and make sure that each directory has index.php this file. When someone accesses a directory that you don't want someone else to visit, let him turn to the homepage of the site, such as a catalog of pictures or something like that.
Never take your backup file with a suffix named. bak and place it in a directory that can be accessed directly from the URL. If you do so, the PHP code in these files will not be parsed, and may even be downloaded directly by the user via the URL. If these files contain passwords or other sensitive information, they may be known and may even be found by search engines, such as Google, directly on the page. Be sure to rename the files to the. bak.php suffix file, which is a bit safer, but the best solution is to control it like CVS. CVS is a bit complicated to learn, but the time you spend learning will be rewarded later. Such a system allows you to keep every different version of the program in a different folder, and if your program has a problem later, these previously saved versions may become your invaluable resource.

[1] [2] [3] Next page