MySQL against SQL injection risk

MySQL against SQL injection risk0. Guidance

How to identify and avoid SQL injection risk in MySQL

1. About SQL injection

The internet is very dangerous, information and data security is very important, SQL injection is one of the most common intrusion means, its low technology threshold, low cost, large profits, is favored by hackers at all levels.

In general, the approach of SQL injection is to take advantage of a variety of opportunities to add malicious SQL code to the program parameters, and eventually executed by the server side, resulting in undesirable consequences.

For example, we access the interface http://imysql.com/user.php?userid=123 to obtain user information based on the UserID, assuming that this is handled in the program:

$sql = "SELECT * FROM user WHERE UserID = $_get[userid]";

The above code looks both low and very xx, especially in double quotes can also directly reference data type variables, so that PHP is the best language in the world is not too much, haha (in fact, I have written in the early years of PHP).

At this point, if the arguments we pass in are changed to this: Http://imysql.com/user.php?userid=123 or 1=1, this will cause the SQL condition to always be set and all the data will be read out. Or you can pass this parameter: http://imysql.com/user.php?userid= 123 or if (now () =sysdate (), Sleep (5), 1), not only will all the data be read, It will also allow the SQL to execute and wait 5 seconds to return, so the hacker can determine whether the SQL injection probe is successful.

In the above example, in fact, we only need the user input parameters for simple type judgment and control, you can quickly avoid the risk of being injected, for example, change to the following:

$userid = Intval (Strim ($_get[' userid "));

$sql = "SELECT * FROM user WHERE UserID =". Mysql_real_escape_string ($userid);

Visible, at least the underlying SQL injection is not difficult to prevent, as long as at all levels to do enough work. and the simple SQL blind (that is, the game of beating the master) has been able to use sqlmap and other ancillary tools to do, completely do not need manual execution.

2, how to prevent

The above mentioned Sqlmap, which can be used as a tool for SQL blinds, can also be scanned within the new project before the launch, early detection of potential vulnerabilities, timely repair, in turn, we use. Other well-known scanning tools that can detect SQL injection vulnerabilities are: Sqlier, sqlid, SQL Power Injector, Sqlninja.

We can also ourselves by frequently scanning the currently executed SQL list, based on some keywords to determine whether SQL injection or potential risk, the common keywords are:

• Sleep ()-General SQL Blinds are accompanied by the sleep () function, and generally sleep at least 5 seconds or more

• MID ()

• CHAR ()

• ORD ()

• Sysdate ()

• SUBSTRING ()

• DATABASES ()

• SCHEMA ()

• USER ()

• VERSION ()

• Current_User ()

• Load_file ()

• Outfile/dumpfile

• Information_schema

• table_name

• Fwrite ()/fopen ()/file_get_contents ()-These are PHP file manipulation functions

We can check the current active SQL command at a higher frequency, once the above keyword is found, you can immediately record and trigger the alarm, notify the administrator to manually confirm the processing, or even the first to automatically kill these SQL queries (you can use the Pt-kill tool to do this, you can also develop their own), Just in case, give the hacker less chance.

Also, we recommend that you set the option Safe-update/sql_safe_updates to 1 to prevent the error operation from being updated with no WHERE condition, and the entire table data is incorrectly written.

3. Other suggestions

Prevention of SQL injection is only a small part of the data security work, as long as the basic skills can prevent at least 80% of SQL injection detection.

In the app server layer, the PHP development language, for example, in addition to the above mentioned specification user input type, but also can be changed to use the sprintf () function to format the SQL statement, but also to some extent to prevent SQL injection. The PHP CGI program can also be modified to run the main user, at least not the root user, to avoid the code layer is not rigorous caused by hackers upload executable PHP code files. You can also turn off remote file invocation permissions in PHP, SET options allow_url_fopen, Allow_url_include to OFF, and limit the file directories that PHP can open, and not allow cross-region access to sensitive files.

In addition to making data type judgments and user input judgments at the code level, you can add filtering policies to the Web server layer, such as enabling WAF plugins on Nginx. Alternatively, you can purchase business solutions from IDC operators and cloud hosting providers. For companies that value data security, it is more important to spend some money on peace.

4. Appendix

Here are some common SQL injection reference cases:

Case 1:select * from T WHERE a like '%xxx% ' or (IF (Now=sysdate (), SLEEP (5), 1)) or B like ' 1=1 ';

Case 2:select * from T WHERE a > 0 and B in (497 and (SELECT * FROM (SELECT (SLEEP))));

Case 3:select * from T WHERE A=1 and B in (1234, (SELECT (5=5) then SLEEP (5) ELSE 5* (select 5 from Information_sch EMA. character_sets)));

Previous page

MySQL against SQL injection risk