How to improve the prevention of PHP security vulnerabilities from the perspective of website development

Intermediary transaction http://www.aliyun.com/zixun/aggregation/6858.html ">seo diagnose Taobao guest cloud host technology Hall

PHP is a popular language for Web application development because of its powerful function, simple introduction and high efficiency of code execution. With a wide range of uses, the use of PHP security vulnerabilities to the Web site is also more and more attacks, which poses a serious threat to the security of Web applications. There are two main types of personnel who are directly responsible for the safety of the website: one is the website developer and the other is the website manager. In this paper, the author from the point of view of web development, PHP security vulnerabilities of the prevention of a more comprehensive summary and research.

A large number of previous attacks have shown that the reason for PHP security vulnerabilities is not to the user's strict authentication and the output of the system is not properly escaped. The user's input can never be blindly believed, in the absence of verification, can be considered to be contaminated data. The discovery of the system is likely to bring greater security risks before it is properly escaped.

1. No strict validation of user input produces security vulnerabilities and precautions

Consider a system login verification, which requires you to log in with the mailbox and password that you fill in when registering. Under normal circumstances, as long as the input is correct to log in, if the error is not allowed to log in, this is the usual processing process. The program implementation is typically to obtain the mailbox and password entered by the user through a login form, and then pass it to the program to construct an SQL query statement, for example: SELECT COUNT (*) from the users where email= ' myemail@163.com ' and Password= ' Mypass ', and then submit this SQL statement to the background database execution, if the number of records returned is 0, then the mailbox information or password is incorrect or the user is not registered, the system refused to log in, the other is a legitimate user, allowing its login. This verification process for the general customer is very effective, if it is not registered or have no sleeve people the correct mailbox and password are not able to log on to the system. But for hackers, things are different. It is possible to carefully design a string to replace the legitimate e-mail address to circumvent the system's authentication, for example: If the hacker's e-mail address is "Myemail" ori=i--, the password is "Myppass", at this time the SQL statement becomes select COUNT (*) from the Users Wherer email= ' myemail ' or i=i--' and password= ' Mypass ', the number of records returned after the execution of this statement is the total number of records in the users table, not 0, so the system allows it to log on through system logon authentication. This is the famous SQL injection attack. The reason for this is that the hacker carefully constructs a string to replace the legitimate email address and the system does not check the user's input data for legality.

In order to prevent the above PHP security vulnerabilities, we can verify the legality of the user's loss. In order to check the legality of the data entered by the user, the email address is required. We can use regular expressions to the user's email address to verify that the correct mailbox format, so that the hacker can greatly increase the difficulty of designing special strings, to some extent, to prevent the emergence of SQL injection of human vulnerabilities.

In any case, if the user's output of strict verification, of course, the verification method according to different circumstances, not limited to regular expression, which can be to a large extent, to prevent PHP security vulnerabilities.

2, does not have the system output to carry on the proper escaping to produce the security loophole and the prevention

Failure to properly escape the system's output also creates a security vulnerability, a well-known example of a cross-site scripting vulnerability. Suppose you have a system that you can comment on, and it takes the form to submit data. For the average user, this will not be a big problem, but for hackers, the question comes. Because hackers don't really want to comment, they may be trying to steal cookies from other logged-in users. To steal cookies from other users, Black can submit JavaScript code as comment content.

If no escaping from the hacker's submissions before the output, the Lavascript code will be executed by another user's browser, sending cookies to the hacker for the other logged-in users who are browsing the comments. To protect against these cross-site scripting exploits, the steps we take are simple: Use the htmlentities () function to escape the output before outputting the comment content to the client browser. This function converts HTML tags that may be included in the output to HTML entities, allowing the hacker to enter JavaScript code that is not executed.

In any case, the output of the system should be properly escaped (the escape method varies depending on the circumstances, not limited to the htmlentities () function), so that the hacker will not be exploited.

Statement: This article by Zhengzhou Wholesale market: http://www.shun-e.com/market/original submission, respect for the achievements of others, reproduced please specify the source!