PHP's 7 major security vulnerabilities

PHP is a great language for fast-growing dynamic Web pages. PHP also has features that are friendly to junior programmers, such as PHP without the need for dynamic declarations. However, these features can cause a programmer to inadvertently sneak security vulnerabilities into the Web application. There are a number of proven vulnerabilities in the popular secure mailing list in PHP applications, but once you understand the basic types of vulnerabilities that are common in PHP applications, you will find that it is just as safe as other languages.

In this article, I will describe in detail several common PHP program flaws that can lead to security vulnerabilities. By showing you what you can't do and how to take advantage of each particular flaw, I hope you will not only understand how to avoid these specific flaws, but also why these errors can lead to security vulnerabilities.

Knowing each possible flaw will help you avoid creating the same error in your PHP application.

Security is a process, not a product that uses security-friendly methods in the application development process to allow you to generate tighter, more robust code.

Failed to verify input defect

If not the most common PHP security vulnerabilities, but also one of them, is not check the input error. Users who provide data cannot be trusted at all. You should assume that all users of your Web application are has evil intentions, because some of them are like that. An unchecked or incorrect validation of input is a source of vulnerability that we will discuss later in this article.

For example, you might write a code that allows the user to view the calendar by calling 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 vulnerability gap because there is no way to validate $_get[month and $_get[year] variables. As long as that particular month is between 1 and 12 and provides a suitable four-digit year, the application will run perfectly. However, a malicious user may append "; Ls-la to the year parameter to see a list of HTML directories for your site. An extremely bad user may append "Rm-rf *" to the year parameter and delete the entire site!

The appropriate way to correct this error is to make sure that the input you receive from the user is what you expect. Instead of using JavaScript validation for this type of error, it is easy for developers who create their own form of JavaScript or disable JavaScript to handle such verification methods. To make sure that the month and year you enter are numbers and only numbers, you need to add 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 can safely use code without having to worry about the user providing input to your application or running the input server. Regular expressions are a great tool for validating input. Although it is difficult to master it, it is very useful in this case.

You should always validate your users ' data by rejecting data that doesn't match the data you expect. Never use a method that still accepts this data when you know the expected data is harmful, and this method is a common source of security vulnerabilities. Sometimes, a malicious user can avoid such a method, for example, using empty characters to mask bad input. Such input will pass the check, but it still has a bad effect.

When you validate any input, you should be as strict as possible. If there are some characters that are not necessarily included, you should either remove those useless characters or reject the input altogether.

Access control flaw

Another flaw that is not necessarily limited to PHP applications, but is still important is the vulnerability type of access control. This flaw occurs when the application of some parts of your application is limited to some users, such as a management page that allows you to change configuration settings or display sensitive information.

You should check every page of your PHP application to restrict the access rights of the users loaded. If you only check the user certificate on the index page, a malicious user can go directly to a link to a "Deeper" page, which skips the process of certificate checking.

For example, if your site has a predictable or fixed IP address that attacks a user, it is advantageous to restrict access to the user's basic IP address and the user's name on the security layer of your program. Placing your restricted Web page is also a good practice in a separate directory protected by apache.htaccess files.

Place the configuration file outside of your Web Access directory. A configuration file contains database passwords and other information that can be used by malicious users to infiltrate or destroy your site, and never allow remote users to access these files. Use PHP's include function to include these files from a directory that is not web accessible, which may include "negate" an.htaccess files in the event that the directory has been erroneously manipulated by the administrator to produce Web Access. Although layered security is superfluous, it is a positive thing.