Summarizes questions about PHP XSS and SQL injection

Vulnerabilities are just a few categories, XSS, SQL injection, command execution, upload vulnerabilities, local inclusion, remote inclusion, permission bypass, information disclosure, cookie forgery, CSRF (Cross station request), and so on. These vulnerabilities are not just for the PHP language, this article simply describes how PHP effectively protects against these vulnerabilities.

1.XSS + SQL Injection (detailed description of XSS attack)

The bulk of this is the nature of XSS and SQL injection, and for frame types or public files, it is recommended that you do a unified XSS and SQL injection filtering in common files. Use PHP to write a filter function, which can be illustrated by the following:

$_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 filtering filter_sql (to prevent SQL injection in detail) can only filter character and search-type injection, for the digital type is no way, but it also shows that after this layer of filtering, just pay attention to the number of SQL statements on the following can be, encountered with the addition of intval filter on it, It's getting much easier.

2. Command execution

For command execution, you can start with a keyword that can be grouped into 3 categories

(1) PHP code execution: eval, etc.

(2) Shell command execution: Exec, PassThru, System, SHELL_EXEC, etc.

(3) Document processing: Fwrite, fopen, mkdir, etc.

For these categories you need to be aware that their parameters are user-controllable.

3. Upload Vulnerability

For the upload vulnerability, but also the focus of attention, to carefully analyze its processing process, for the upload of the bypass way is a lot of the safest way: In the save file is to use the name of random naming and suffix white list way. The second thing to note is that the upload file may be more than one place, do not have omissions, you may encounter such a situation, suddenly in a directory containing a third party editor in the inside.

The file contains the functions involved in the vulnerability such as include (), include_once (), require (), require_once (), file_get_contents (), and so on

The most common is the download file function, such as download.php?file=. /.. /.. /ETC/PASSWD in this type.

4. Permissions Bypass

Permission bypasses can be divided into two categories.

(1) unauthorized access to the background file. The background of the file does not contain the session verification, it is easy to appear such a problem

(2) Not for user isolation, such as mail.php?id=23 display your letter, then change the ID, mail.php?id=24 see someone else's letter, write code is convenient, the letter exists in a data table, ID uniform number, the front-end display only by ID out can be, But no user isolation, the determination of attribution, easy to cause unauthorized access.

Such an example is common, and an assessment of a bank often reveals such a loophole.

5. Information disclosure

Information disclosure is a relatively low-risk vulnerability, such as the column directory This is a deployment problem, and the code audit has nothing to do, and like the storm path, the source of this is the need to prevent. Once encountered such code

　　

Seemingly there is no problem, but when the request to become xx.php?a[]=1, that is, when the parameters into an array, there will be errors so that the path leakage, and use isset judge will not, of course, to prevent too much trouble, we recommend that in the configuration file to turn off the error prompts, Or, add the following code to the public file to turn off the error display feature: