About PHP vulnerabilities and how to prevent PHP vulnerabilities?

Vulnerabilities include XSS, SQL injection, command execution, upload vulnerabilities, local inclusion, remote inclusion, permission bypass, information leakage, cookie forgery, and CSRF (cross-site request. These vulnerabilities are not only for the PHP language, but also a brief introduction to how PHP effectively prevents these vulnerabilities.

Vulnerabilities include XSS, SQL injection, command execution, upload vulnerabilities, local inclusion, remote inclusion, permission bypass, information leakage, cookie forgery, and CSRF (cross-site request. These vulnerabilities are not only for PHP, but also for how PHP effectively prevents them.

1. xss + SQL injection (detailed introduction to xss attacks)

XSS and SQL injection occupy the largest part of the data. For framework types or public files, we recommend that you filter XSS and SQL injection in public files. Use PHP to write a filter function, as shown in the following code:

$ _ REQUEST = filter_xss ($ _ REQUEST );

$ _ GET = filter_xss ($ _ GET );

$ _ POST = filter_xss ($ _ POST );

$ _ COOKIE = filter_xss ($ _ COOKIE );

$ _ POST = filter_ SQL ($ _ POST );

$ _ GET = filter_ SQL ($ _ GET );

$ _ COOKIE = filter_ SQL ($ _ COOKIE );

$ _ REQUEST = filter_ SQL ($ _ REQUEST );

The simplest filter_xss function is htmlspecialchars ()

The simplest filter_ SQL function is mysql_real_escape_string ()

Of course, everyone knows that this type of filtering filter_ SQL (to prevent SQL injection in detail) can only filter injection in character type and search type. there is no way for digital type, but it also indicates that after this layer of filtering, you only need to pay attention to the number-type SQL statement at the end of the article. you can use intval to filter the statements, which makes it much easier.

2. command execution

For command execution, you can start with keywords, which can be divided into three categories

(1) php code execution: eval

(2) shell command execution: exec, passthru, system, shell_exec, etc.

(3) file processing: fwrite, fopen, mkdir, etc.

Pay attention to whether the parameters of these types are controllable.

3. Upload vulnerability

The upload vulnerability is also a key concern. we need to carefully analyze its handling process. There are many ways to bypass the upload, and the safest way is: the file name is randomly named and the suffix is whitelist. The second thing to note is that there may be more than one file to be uploaded. you may encounter such a situation where a third-party editor is included in a directory.

File inclusion vulnerabilities include (), include_once (), require (), require_once (), file_get_contents (), etc.

The most common function is to download files, such as download. php? File =..././etc/passwd.

4. permission bypass

There are two types of permission bypass:

(1) unauthorized access to background files. If the background file does not contain session verification, this issue may occur.

(2) no user isolation, such as mail. php? Id = 23 shows your mail, so change the ID, mail. php? Id = 24 to view others' emails. it is convenient to write code. all the emails are stored in a data table with uniform IDs. you only need to retrieve them by id when displaying the front-end, however, user isolation is not performed to determine the ownership, which may lead to unauthorized access.

This is a common example. this vulnerability is often discovered when a bank is evaluated.

5. information leakage

Information leakage is a low-risk vulnerability. for example, the column directory is a deployment issue, but it has nothing to do with code auditing. such vulnerabilities need to be prevented, such as brute-force paths and brute-force source code. I have encountered such code

　　
On the surface, there seems to be no problem, but when the request changes to xx. php? When a [] = 1, that is, when the parameter is changed to an array, an error will occur, causing the path to leak. if you use isset, the error will not occur. of course, it is too troublesome to guard against each other, we recommend that you disable the error prompt in the configuration file, or add the following code to the public file to disable the error display function:

　　
In the past, PHP point-to-point (phpddt.com) published an article about the PHP vulnerability prevention policy, which describes the dangers of register_globals and how to use Magic Quotes.