Common security threats in PHP website construction include: SQL injection, manipulation of GET and POST variables, buffer overflow attacks, cross-site scripting attacks, in-browser data manipulation and remote form submission.
In SQL injection attacks, users add information to database queries by manipulating forms or GET query strings.
For example, assume you have a simple login database. Each record in this database has a username field and a password field. Build a login form to allow users to log in.
The solution to this problem is to use PHP's built-in mysql_real_escape_string() function as a wrapper around any user input.
This function escapes characters in a string, making it impossible for the string to pass special characters such as apostrophes and allowing MySQL to operate based on special characters. Listing 7 shows the escaped code.
Just because a user has a valid password does not mean that he will act according to the rules - he has many opportunities to cause damage. For example, an application might allow users to view special content.
For example template.php?pid=33 or template.php?pid=321. The part of the URL after the question mark is called the query string. Because the query string is placed directly in the URL, it is also called a GET query string.
Is there anything wrong here?
First of all, there is an implicit belief that the GET variable pid from the browser is safe.
What will happen?
Most users are not that smart and cannot construct semantic attacks. However, if they notice pid=33 in the browser's URL location field, they might start causing trouble.
If they enter another number, then it may be fine; but if they enter something else, such as entering an SQL command or the name of a file (such as /etc/passwd), or doing other mischief, such as Enter a value up to 3,000 characters long, and what happens?
In this case, remember the basic rule, don't trust user input.
Application developers know that the personal identifiers (PIDs) accepted by template.php should be numeric, so they can use PHP's is_numeric() function to ensure that non-numeric PIDs are not accepted.
All you need to do is use strlen() to check whether the length of the variable is non-zero; if so, use an all-numeric regular expression to ensure that the data element is valid. If the PID contains letters, slashes, periods, or anything resembling hexadecimal, then this routine captures it and blocks the page from user activity.
A buffer overflow attack attempts to overflow the memory allocation buffer in a PHP application (or, more precisely, in Apache or the underlying operating system) .
Keep in mind that you may be writing your web application in a high-level language like PHP, but ultimately you'll be calling C (in the case of Apache). Like most low-level languages, C has strict rules for memory allocation.
Buffer overflow attacks send a large amount of data to the buffer, causing part of the data to overflow into adjacent memory buffers, thereby destroying the buffer or rewriting the logic. This can cause a denial of service, corrupt data, or execute malicious code on the remote server.
The only way to prevent buffer overflow attacks is to check the length of all user input.
Note that buffer overflow attacks are not limited to long strings of numbers or letters. You may also see long hexadecimal strings (often looking like \xA3 or \xFF).
Remember, the goal of any buffer overflow attack is to flood a specific buffer and place malicious code or instructions into the next buffer, thereby corrupting data or executing malicious code.
The simplest way to deal with hexadecimal buffer overflow is to not allow input to exceed a certain length.
If you are dealing with a form text area that allows longer entries in the database, there is no way to easily limit the length of the data on the client side. After the data reaches PHP, you can use regular expressions to clear out any hex-like strings.
In a cross-site scripting (XSS) attack, a malicious user often enters information in a form (or through other user input methods), and these inputs will Malicious client-side tokens are inserted into processes or databases.
For example, suppose you have a simple guest book program on your site that allows visitors to leave their name, email address, and a brief message.
A malicious user could take advantage of this opportunity to insert something other than a brief message, such as an image that would be inappropriate for other users or JavaScript that would redirect the user to another site, or steal cookie information.
Fortunately, PHP provides the strip_tags() function, which can remove any content surrounded by HTML tags. The strip_tags() function also allows providing a list of allowed tags.
From a security perspective, using strip_tags() on public user input is necessary. If the form is in a protected area (such as a content management system) and you trust users to perform their tasks correctly (such as creating HTML content for a Web site), then using strip_tags() may be unnecessary and affect productivity .
There is another question: If you want to accept user input, such as comments on posts or guest registration items, and need to display this input to other users, then you must put the response in PHP's htmlspecialchars() in function.
This function converts the ampersand, < and > symbols into HTML entities. For example, the ampersand (&) becomes &. In this case, even if the malicious content escapes the processing of strip_tags() on the front end, it will be processed by htmlspecialchars() on the back end.
There is a type of browser plug-in that allows users to tamper with the header elements and form elements on the page. Using Tamper Data, a Mozilla plug-in, it's easy to manipulate simple forms with many hidden text fields to send instructions to PHP and MySQL.
Before the user clicks Submit on the form, he can start Tamper Data. When submitting the form, he will see a list of form data fields.
Tamper Data allows the user to tamper with this data before the browser completes the form submission.
The easiest way to defend against this tool is to assume that any user could potentially use Tamper Data (or a similar tool).
Provide only the minimum amount of information required by the system to process the form, and submit the form to some dedicated logic. For example, the registration form should only be submitted to the registration logic.
What if you have established a common form processing function and many pages use this common logic?
What should you do if you use hidden variables to control the flow direction?
For example, it may be specified in a hidden form variable which database table to write to or which file repository to use. There are 4 options:
Don't change anything and pray that there aren't any malicious users on the system.
Rewrite the function to use a safer dedicated form processing function and avoid using hidden form variables.
Use md5() or other encryption mechanisms to encrypt table names or other sensitive information in hidden form variables. Don't forget to decrypt them on the PHP side.
Obfuscate the meaning of values by using abbreviations or nicknames, and then convert these values in PHP form processing functions. For example, if you want to reference the users table, you can reference it with u or any string (such as u8y90×0jkL).
The latter two options are not perfect, but they are much better than having the user easily guess the middleware logic or data model.
The advantage of the Web is that it can share information and services. The downside is sharing information and services because some people do things without any scruples.
Take the form as an example. Anyone can visit a Web site and create a local copy of the form using File > Save As on the browser. He can then modify the action parameter to point to a fully qualified URL (not to formHandler.php, but to http://www.yoursite.com/formHandler.php since the form is on this site) and do what he wants If you make any changes, click Submit, and the server will receive this form data as a legal communication flow.
First you may consider checking $_SERVER['HTTP_REFERER'] to determine whether the request comes from your own server. This method can block most malicious users, but it cannot block the most sophisticated hackers. These people are smart enough to tamper with the referrer information in the header to make the remote copy of the form look like it was submitted from your server.
A better way to handle remote form submission is to generate a token based on a unique string or timestamp and put this token in the session variable and the form. After submitting the form, check if the two tokens match. If it doesn't match, you know someone is trying to send data from a remote copy of the form.
Use mysql_real_escape_string() to prevent SQL injection problems.
Use regular expressions and strlen() to ensure that GET data has not been tampered with.
Use regular expressions and strlen() to ensure that user-submitted data does not overflow the memory buffer.
Use strip_tags() and htmlspecialchars() to prevent users from submitting potentially harmful HTML tags.
Prevent the system from being breached by tools like Tamper Data.
Use a unique token to prevent users from submitting forms to the server remotely.
Related recommendations:
Common PHP security attacks and solutions
##Solutions to several common attack methods in PHP website development
PHP implementation example code to prevent cross-site and xss attacks
The above is the detailed content of Common attack methods on PHP websites. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
