PHP the most important seven security vulnerabilities

PHP is a great language for the fast-growing dynamic web pages. PHP also has the characteristics of junior programmers friendly, such as PHP do not need dynamic statement. However, these features may cause a programmer to unintentionally sneak a security vulnerability into a web application. There are a number of proven vulnerabilities in popular security mailing lists in PHP applications, but once you understand the basic types of vulnerabilities that are common in PHP applications, you'll find it equally as secure as any other language.

In this article, I'll detail several common pitfalls of PHP programs that can lead to security holes. By showing you what you can not do and how you can exploit each specific flaw, I hope you will not only understand how to avoid these specific flaws, but also why these mistakes lead to security breaches.

Understanding every possible flaw will help you avoid the same mistakes made in PHP applications.

Security is a process, not a product A safe and secure approach to application development allows you to generate tighter, more robust code.

Unchecked input defect

If it is not one of the most common PHP security vulnerabilities, one of them is the unvalidated typing error. Users who provide data are simply not trusted. You should assume that all of your web application users are unscrupulous, as some of them are like that. Unverified or incorrectly validated inputs are the root cause of exploits that we will discuss later in this article.

For example, you might write the following code that allows users 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 gap in security holes because the $ _GET [month] and $ _GET [year] variables are not validated in any way. As long as that particular month is between 1 and 12 and provides a suitable four-digit year, that application will work 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 website!

The proper 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 such mistakes, developers who create their own forms of javascript or disable javascript can easily handle such validation methods. To ensure that the month and year entered are numeric and have 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 can safely use code without worrying about the user providing a server that affects your application's input or run input. Regular expressions are a great validation input tool. Although it is hard to grasp it, it is very useful in this situation.

You should always verify the data provided by your users by rejecting data that does not match your expectations. Never use a method that still accepts this data if you know it is bad data, which is a common source of security vulnerabilities. Sometimes, malicious users can avoid this method, for example, use blank characters to mask the bad input method. 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 you have characters that you do not need to include, you should either remove the useless characters if possible or reject them altogether.

Access control flaws

Another drawback, not necessarily limited to PHP applications, is still important, and is the type of vulnerability for access control. This defect arises when the application of parts of your application is restricted to certain users, for example, a management page that allows you to change configuration settings or display sensitive information.

You should check each of your PHP application pages to limit the access rights of the loaded user. If you only check the user's credentials on the index page, a malicious user can go straight to the link to a "deeper" webpage, which will skip the certificate checking process.

For example, if your site has predictable IPs or fixed IP addresses for attacking users, it can be beneficial to your program's security layer by restricting users' access to that user's base IP address and their user's name. It is also good practice to place your restricted web pages in a separate directory protected by the apache.htaccess file.

Place the configuration file outside your web access directory. A configuration file contains database passwords and other information that can be used by malicious users to infiltrate or compromise your site; never allow remote users to access these files. Use PHP's include function to include these files from a non-web-accessible directory, which may include an.htaccess file that contains "negation" in case there is web access to this directory caused by administrator misuse. Although layered security is superfluous, it is a positive thing.