HP+MYSQL website SQL Injection attack and defense

WebjxCom Tip: Programmers pay attention to TDD (Test Driven Development) when writing code: before implementing a function, they will first write a test case, and then write the code to make it run. In fact, when hackers perform SQL Injection, it is also a TDD process: they will first try to make the program report an error, and then correct the parameter content bit by bit. When the program runs successfully again, the injection will follow

Programmers pay attention to TDD (test-driven development) when writing code: before implementing a function, they will first write a test case, and then write the code to make it run. In fact, when hackers perform SQL Injection, it is also a TDD process: they will first try to make the program report an error, and then correct the parameter content bit by bit. When the program runs successfully again, the injection will be successful.
Attack:
Suppose you have a script similar to the following in your program:
$sql = "SELECT id, title, content FROM articles WHERE id = {$_GET[''id'']}";
During normal access, it The URL is as follows:
/articles.php?id=123
When hackers want to determine whether there is a SQL Injection vulnerability, the most common way is to add a single quote after the integer ID:
/articles.php?id=123''
Since we did not filter the $_GET[''id''] parameter, an error will inevitably be reported, which may be similar to the following information:
supplied argument is not a valid MySQL result resource in...
This information is enough to indicate the existence of the script There is a loophole, we can use some tricks:
/articles.php?id=0 union select 1,2,3
The reason why 1,2,3 is selected is because union requires the number of fields on both sides to be the same, and the front is id. There are three fields of title and content, followed by 1, 2, and 3, so no syntax error will be reported. Also, setting id=0 is a non-existent record, so the query result is 1, 2, 3, which is reflected in On the web page, 1 will be displayed where the id is originally displayed, 2 will be displayed where the title is displayed, and 3 will be displayed where the content is displayed.
As for how to continue to use it, it depends on the settings of magic_quotes_gpc:
When magic_quotes_gpc is off:
/articles.php?id=0 union select 1,2,load_file(''/etc/passwd'')
This is the case As a result, the contents of the /etc/passwd file will be displayed where the content was originally displayed.
When magic_quotes_gpc is on:
If you use load_file(''/etc/passwd'') directly at this time, it will be invalid because the single quotes are escaped, but there is a way:
/articles.php?id =0 union select 1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100))
The number is the ASCII of the /etc/passwd string: each character of the string is output in a loop ord(...)
except I think you can also use the hexadecimal format of the string: each character of the string is cyclically output dechex(ord(...))
/articles.php?id=0 union select 1,2,load_file(0x2f6574632f706173737764)
Here are just a few attack methods for numeric parameters, which are just the tip of the iceberg. For attack methods such as string parameters, please see the document link below.
Defense:
There are some software similar to SQL Injection Firewall available on the Internet, such as GreenSQL. If the website has begun to suffer SQL Injection attacks, using such a shortcut tool will often save your life. However, such software has a lot of challenges in its architecture. The role of a Proxy will probably affect the concurrent performance of the website, so it is best to make a careful decision based on objective conditions when choosing whether to choose one. In many cases, professional software is not necessary, and there are many lightweight solutions. Here is a demonstration of how to use awk to detect possible vulnerabilities.
Create the detect_sql_injection.awk script with the following content (remember not to include the line number if you want to copy the content):
01 #!/bin/gawk -f
02
03 /$_(GET|POST|COOKIE|REQUEST)s *[/ {
04 IGNORECASE = 1
05 if (match($0, /$.*(sql|query)/)) {
06 IGNORECASE = 0
07 output()
08 next
09 }
10 }
11
12 function output()
13 {
14 $1 = $1
15 print "CRUD: " $0 "nFILE: " FILENAME "nLINE: " FNR "n"
16 }
This script can match problem codes similar to the following , it is easy to extend the matching mode, just write the if match statement like a cat or a tiger.
1: $sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
2: $res = mysql_query("SELECT * FROM users WHERE username = ''{ $_POST[''username'']}''");
Don't forget to chmod +x detect_sql_injection.awk before using it. There are two calling methods:
1: ./detect_sql_injection.awk /path/to/php/ script/file
2: find /path/to/php/script/directory -name "*.php" | xargs ./detect_sql_injection.awk
will display the problematic code information, as follows:
CRUD: $sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
FILE: /path/to/file.php
LINE: 123
There are many applications of this script in the real environment Methods, such as regularly scanning program source files through CRON, or automatically matching through hook methods when SVN is submitted.
Whether using professional tools or detecting scripts, it is all passive defense. The root of the problem always depends on whether the programmer has the necessary security awareness. Here are some guidelines that must be kept in mind:
1: Digital type Parameters use methods like intval and floatval to force filtering.
2: Use methods like mysql_real_escape_string to force filter string parameters instead of simple addslashes.
3: It is best to abandon the splicing SQL query method such as mysql_query and use PDO's prepare binding method as much as possible.
4: Use rewrite technology to hide real script and parameter information, and filter suspicious parameters through rewrite regular rules.
5: Turn off error prompts and not provide sensitive information to attackers: display_errors=off.
6: Record error information in the form of a log: log_errors= />7: Do not use an account with FILE permissions (such as root) to connect to MySQL. This blocks dangerous functions such as load_file.
8:...
Website security is actually not complicated. It can be summed up in one sentence: filter input and escape output. Among them, the SQL Injection problem we have been discussing above belongs to the problem of filtering input. As for the problem of escaping output, its representative is Cross-site scripting, but it does not belong to the scope of this article, so I will not say more.
Documentation:
addslashes() Versus mysql_real_escape_string()
SQL Injection with MySQL
Advanced SQL Injection with MySQL
Research on exported field content in MySQL injection - Exporting WebShell through injection

Reprinted from: http://www.aspnetjia. com/Cont-328.html

The above has introduced the attack and defense of SQL Injection on the HP+MYSQL website, including various aspects. I hope it will be helpful to friends who are interested in PHP tutorials.