Several common attack methods to solve PHP Web site development

This article is mainly to share with you to solve several common attack methods of PHP website development, Common Security threats in PHP website construction include: SQL injection, manipulating GET and POST variables, buffer overflow attacks, cross-site scripting attacks, data manipulation within the browser, and remote form submission.

1. Preventing SQL injection attacks

In a SQL injection attack, the user adds information to a database query by manipulating the form or GET query string.

For example, suppose you have a simple login database. Each record in this database has a user name field and a password fields. Build a login form that allows users to log in.

The solution to this problem is to use PHP's built-in mysql_real_escape_string () function as a wrapper for any user input.

This function escapes characters in a string, making it impossible for strings to pass special characters such as apostrophes and letting MySQL operate on special characters. Listing 7 shows the code with escape processing.

2. Prevent user from manipulating variables

The user has a valid password and 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.

such as template.php?pid=33 or template.php?pid=321. The part after the question mark in the URL 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, it is implicitly believed that the GET variable pid from the browser is safe.

What's going to happen?

Most users are less intelligent and cannot construct semantic attacks. However, if they notice pid=33 in the URL location domain of the browser, they may start messing up.

If they enter another number, it may be fine, but what happens if you enter something else, such as typing in a SQL command or a file name (such as/etc/passwd), or doing other pranks, such as entering a value up to 3,000 characters long?

In this case, remember the basic rules and do not trust user input.

The application developer knows that the personal identifier (PID) that template.php accepts should be a number, so you can use the PHP is_numeric () function to make sure that you don't accept a non-numeric PID.

All you need to do is use strlen () to check if the length of the variable is not 0, and if so, use an all-numeric regular expression to ensure that the data element is valid. If the PID contains letters, slashes, dots, or anything similar to hexadecimal, this routine captures it and masks the page from user activity.

3. Buffer overflow attack

A buffer overflow attack attempts to overflow a memory allocation buffer in a PHP application (or, more precisely, in Apache or the underlying operating system).

Keep in mind that you may be using a high-level language like PHP to write Web applications, but ultimately you will want to call C (in the case of Apache). Like most low-level languages, C has strict rules for memory allocation.

A buffer overflow attack sends a large amount of data to the buffer, causing partial data to overflow into adjacent memory buffers, thereby destroying the buffer or rewriting logic. This can cause denial of service, corrupt data, or execute malicious code on a remote server.
The only way to prevent a buffer overflow attack is to check the length of all user input.

Note that a buffer overflow attack is not limited to long numeric strings or strings of letters. You may also see long hexadecimal strings (often looking like \xa3 or \xff).

Remember that any buffer overflow attack is intended to overwhelm a particular buffer and place malicious code or instructions in the next buffer, destroying the data or executing malicious code.

The simplest way to counter a hex buffer overflow is to not allow the input to exceed a specific length.
If you are working with a form text area that allows you to enter longer entries in the database, you cannot easily limit the length of the data on the client. After the data arrives in PHP, you can use regular expressions to clear any strings like hexadecimal.

4. Cross-site scripting attacks

In cross-site scripting (XSS) attacks, there is often a malicious user entering information in table consignments (or other user input) that inserts a malicious client tag into the process or database.

For example, suppose you have a simple visitor register program on your site that allows visitors to leave names, e-mail addresses, and short messages.

A malicious user can take advantage of this opportunity to insert something other than a short message, such as an inappropriate image for another user or a JavaScript that redirects the user to another site, or steals cookie information.

Fortunately, PHP provides the Strip_tags () function, which clears any content that surrounds the HTML tag. The Strip_tags () function also allows you to provide a list of allowed tokens.

From a security point of view, it is necessary to use STRIP_TAGS () for public user input. If your form is in a protected area, such as a content management system, and you believe that users will perform their tasks correctly (such as creating HTML content for a Web site), then using Strip_tags () may be unnecessary and will affect productivity.

Another problem: If you want to accept user input, such as comments on posts or visitor registrations, and need to show this input to other users, be sure to put the response in PHP's Htmlspecialchars () function.

This function converts symbols, <, and > symbols into HTML entities. For example, the symbol (&) becomes &. In this case, even if the malicious content is avoiding the processing of the front-end strip_tags (), it will be disposed of by Htmlspecialchars () at the backend.

5. Data manipulation within the browser

There is a class of browser plug-ins that allow users to tamper with head elements and form elements on a page. With Tamper Data (a Mozilla plugin), it's easy to manipulate simple forms that contain many hidden text fields, sending instructions to PHP and MySQL.

The user can launch Tamper Data before clicking Submit on the form. When the form is submitted, he will see a list of form data fields.

Tamper data allows the user to tamper with the information and then the browser completes the form submission.

The simplest way to defend against such a tool is to assume that any user may use Tamper Data (or similar tools).

Provide only the minimal amount of information that the system needs to process the form, and submit the form to some specialized logic. For example, the registration form should only be submitted to the registration logic.

What if a common form handler has been created and many pages use this common logic?

What if you use a hidden variable to control the flow direction?

For example, you might specify which database table to write in a hidden form variable or which file repository to use. There are 4 types of options:

Don't change anything, secretly pray that there are no malicious users on the system.

Override functionality to avoid using hidden form variables by using more secure, specialized form handlers.

Use MD5 () or other encryption mechanisms to encrypt table names or other sensitive information in a hidden form variable. Do not forget to decrypt them on the PHP side.

By using abbreviations or nicknames to blur the meaning of a value, the values are converted in a PHP form handler function. For example, if you want to refer to the Users table, you can refer to it by using U or any string, such as U8Y90X0JKL.

The latter two options are not perfect, but they are much better than making it easier for users to guess the middleware logic or data model.

6. Remote form submission

The benefit of the WEB is the ability to share information and services. The downside is the ability to share information and services, because some people do things without scruple.

Take the form as an example. Anyone can access a Web site and use File > Save as on the browser to create a local copy of the form. He can then modify the action parameter to point to a fully qualified URL (not pointing to formhandler.php, but pointing to http://www.yoursite.com/ formhandler.php, because the form is on this site), making any changes he wants, click Submit, and the server will receive the form data as a legitimate communication stream.

You might want to consider checking $_server[' http_referer '] to see if the request is from your own server, which can block most malicious users, but not the most sophisticated hackers. These people are smart enough to tamper with the referrer information in the header, making the remote copy of the form look like it was submitted from your server.

A better way to handle a remote form submission is to generate a token based on a unique string or timestamp and place the token in the session variables and forms. After submitting the form, check that the two tokens match. If it doesn't match, you know someone is trying to send data from a remote copy of the form.

PHP Web Development Security Summary:

Use Mysql_real_escape_string () to prevent SQL injection problems.

Use regular expressions and strlen () to ensure that the GET data is not tampered with.

Use regular expressions and strlen () to ensure that the data submitted by the user does not overflow the memory buffer.

Use Strip_tags () and htmlspecialchars () to prevent users from committing potentially harmful HTML tags.

Avoid the system being broken by tools such as Tamper Data.

Use unique tokens to prevent users from submitting forms remotely to the server.