Seven major PHP Security vulnerabilities

PHP is a great language for rapidly developing dynamic web pages. PHP is also friendly to junior programmers. for example, PHP does not need to be declared dynamically. However, these features may cause a programmer to inadvertently intrude security vulnerabilities into web applications. In PHP applications, a large number of confirmed vulnerabilities occur in popular security email lists, but 1 "> <LINKhref =" http: // www. php100.

PHP is a great language for rapidly developing dynamic web pages. PHP is also friendly to junior programmers. for example, PHP does not need to be declared dynamically. However, these features may cause a programmer to inadvertently intrude security vulnerabilities into web applications. In PHP applications, the popular security email list shows a large number of proven vulnerabilities, but once you understand the basic types of vulnerabilities common in PHP applications, then you will find that it is as secure as other languages.

In this article, I will detail several common PHP program defects that cause security vulnerabilities. By presenting to you what cannot be done and how to take advantage of each specific defect, I hope that you will not only understand how to avoid these specific defects, but also why these errors can lead to security vulnerabilities.

Understanding every possible defect will help you avoid the same errors in PHP applications.

Security is a process. it is not a product that uses security-beneficial methods in application development that allow you to generate more closely and robust code.

Input defects not verified

If it is not the most common PHP security vulnerability, it is also one of them, that is, the input error is not verified. Users who provide data cannot trust it at all. You should assume that all users of your web applications are tested with confidence, because some of them are like that. Unverified or incorrect verification input is the source of some vulnerabilities, which will be discussed later in this article.

For example, you may write the following code to allow users to view the Calendar. you can call the UNIX cal command to display the specified month.

$ Month = $ _ GET ['month'];

$ Year = $ _ GET ['Year'];

Exec ("cal $ month $ year", $ result );

Print"

";
 
　　foreach ($result as $r) { print "$r
"; }
　　print "

";

 

This code has a security vulnerability gap because the $ _ GET [month] and $ _ GET [year] variables are not verified in any way. As long as the specified month is between 1 and 12 and a suitable four-digit year is provided, the application will run perfectly. However, malicious users may append the parameter "; ls-la" to the year to view the HTML directory list of your website. An extremely bad user may append the "; rm-rf *" parameter to the year and delete the entire website!

The proper way to correct this error is to ensure that the input you accept from the user is what you expect. Developers who create their own form of JavaScript or disable javascript do not need to use javascript verification for such errors, so it is easy to handle such verification methods. To ensure that the input month and year are numbers and only numbers, you need to add the PHP code, as shown below.

$ Month = $ _ GET ['month'];

$ Year = $ _ GET ['Year'];

If (! Preg_match ("/^ [0-9] {1, 2} $/", $ month) die ("Bad month, please re-enter .");

If (! Preg_match ("/^ [0-9] {4} $/", $ year) die ("Bad year, please re-enter .");

Exec ("cal $ month $ year", $ result );

Print"

";
 
　　foreach ($result as $r) { print "$r
"; }
　　print "

";

 

You don't have to worry about providing servers that affect your application input or running input. you can use the code safely. Regular expressions are a great tool for verifying input. Although it is difficult to grasp it, it is very useful in this case.

You should always reject data that does not match your expected data to verify the data provided by your users. Never use a method that still accepts the expected data if you know it is harmful. this method is a common source of security vulnerabilities. Sometimes, malicious users can avoid this method. for example, they can use null characters to conceal bad input. Such input will pass the check, but it still has bad effects.

When you verify any input, you should be as strict as possible. If there are unnecessary characters, you can elaborate on PHP www.xishuophp.com. you should either remove those useless characters or reject the input completely.

Access control defects

Another defect is not necessarily limited to PHP applications, but it is still important that it is the type of access control vulnerability. When some applications of your application are limited to some users, this defect occurs, for example, a management page that allows you to change configuration settings or display sensitive information.

You should check that each page of your PHP application restricts the access rights of the loaded users. If you only check the user certificate on the index page, a malicious user can directly access the link on a "deeper" page, which will skip the certificate check process.

For example, if your website has predictable or fixed IP addresses that attack users, it is advantageous to restrict users to access the basic IP address of the user and their user names on the security layer of your program. Placing your restricted webpage in an independent directory protected by the apache. htaccess file is also a good practice.

Place the configuration file outside your web Access Directory. A configuration file contains the database password and other information that can be used by malicious users to penetrate or damage your site. it never allows remote users to access these files. Use the include function of PHP to include these files from directories that are not accessible to the web. in the event that the directory has been accessed by the administrator due to misoperations, this may include. htaccess file. Although hierarchical security is redundant, it is a positive thing.