今天，一基友问我一个问题说：为什么SQL注入要加单引号，这个当时我一时也回答不上，怪就怪自己理论太菜，不过回去仔细思考了一下，觉得这个问题也是蛮简单的。
首先大家应该明白的一点就是SQL注入的目的：加单引号是为了让后台SQL语句执行的时候报错，这样，我们就可以初步判断单引号被放在SQL语句中执行了，只是执行的语句因为有单引号而出错了，这里我都有点啰嗦了，笑。
要防御这种单引号攻击，服务器有3种办法：
1、 将单引号过滤或者替换 – 一般程序都是这样做的
2、 将单引号转义 – 所谓转义就是让它成为一个普通的字符，而不具备执行功能，php常用addslashes()函数完成这一功能
3、 将服务器设置为不允许爆错或者爆404 not found
下面详细的介绍一下SQL注入的基本原理
SQL注入是什么？
引用老外的话来说，SQL注入是这样描述的：
SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker).SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.
SQL injection (SQLI) is considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project. In 2013, SQLI was rated the number one attack on the OWASP top ten.
There are five main sub-classes of SQL injection:
1：Classic SQLI
2：Blind or Inference SQL injection
3：Database management system-specific SQLI
4：Compounded SQLI
5：The Storm Worm is one representation of Compounded SQLI
哎，其实这些描述我也看不大懂，怪就只能怪自己英语没认真学啊！
接下来，看看实例代码
1：权限绕过
statement = "SELECT * FROM users WHERE name ='" + userName + "';"
大家觉得这条语句有SQL注入没？
答案是：有SQL注入
如果我们在web中提交：
' or '1'='1
' or '1'='1' --
' or '1'='1' ({ ' or '1'='1' /*
那么，SQL查询逻辑就变成这样子了：
SELECT * FROM users WHERE name = '' OR '1'='1';
SELECT * FROM users WHERE name = '' OR '1'='1' -- ';
如果这些SQL查询放在权限验证的代码中，那么该代码就会爆权限绕过了。
2：多语句执行
例如：我们在web中，对name这个变量提交SQL查询：
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
在完整SQL代码中就是这个样子的：
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
这段SQL语句执行的结果是：users表被删除了，userinfo表的内容被完全展示出来！
Tips：
While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as 's mysql_query() function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.
这个意思最完美，我没翻译，怕翻译出错，呵呵！
3：数据类型没有验证
例如：SQL语句本来是这样：
statement := "SELECT * FROM userinfo WHERE id =" + a_var + ";"
这个a_var按正常逻辑来说是int型数据 <虽然用户提交的数据都被server识别为字符 or 字符串>
但是，如果Hacker提交如下payload，SQL语句执行结果将会怎样呢？
1;DROP TABLE users
那么，我们的SQL语句就变成这个样子了：
SELECT * FROM userinfo WHERE id=1;DROP TABLE users;
SQL执行的结果是：users表被删除了！
其实，仔细想来，这个地方还是多语句执行造成的，但问题的关键还是programmer没有对用户提交的数据类型做严格检查。
4：SQL盲注
下面科普一下SQL盲注：
Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.
例如：
Server端SQL查询是这样的：
SELECT * FROM bookreviews WHERE ID = 'Value(ID)';
但是，我们可以将它变成这样：
SELECT * FROM bookreviews WHERE ID = '1' AND '1'='1';
SELECT * FROM bookreviews WHERE ID = '1' AND '1'='2';
如果AND 1=1返回正常页面并且AND 1=2返回错误页面，那么，我们就说这个web页面<当然是后台页面>存在SQL盲注，准确一点是基于布尔型的SQL盲注<Boolean-based SQLBI>。
什么time-based SQLBI、error-based SQLBI，这里就不再细说了。
5：二次注入
二次注入的定义：
Second order SQL injection occurs when submitted values contain malicious commands that are stored rather than executed immediately. In some cases, the application may correctly encode a SQL statement and store it as valid SQL. Then, another part of that application without controls to protect against SQL injection might execute that stored SQL statement. This attack requires more knowledge of how submitted values are later used. Automated web application security scanners would not easily detect this type of SQL injection and may need to be manually instructed where to check for evidence that it is being attempted.
具体实例also see：
6：十六进制转换，可以防御SQL注入攻击
这个不怎么好描述，我举几个实例，大家应该就明白了：
具体实例also see：
实例代码：
File: test.php
include_once( "dosql.php" );
#
# Put your own database information here. I'm using my log file's data.
#
$host = "myhost";
$usr = "myUser";
$pwd = "myPassword";
$db = "myDatabase";
$mysqli = new mysqli( $host, $usr, $pwd, $db );
if( $mysqli->connect_errno ){ echo "Failed to connect to MySQL: (" . $mysqli->connect_errno . ") " . $mysqli->connect_error; exit;
}
echo "SQL INJECTION - Plain\n";
$sql = "select * from log where log_id='2' or 1=1; #'";
$res = dosql( $sql );
foreach( $res[0] as $k=>$v ){ echo "RES[$k] = $v\n";
}
echo "\n\nSQL INJECTION = Hexadecimal\n";
$sql = "select * from log where log_id=unhex('" . bin2hex("2' or 1=1; #") . "')"; $res = dosql( $sql );
foreach( $res[0] as $k=>$v ){ echo "RES[$k] = $v\n";
}
exit;
?>
File: dosql.php
################################################################################
# dosql(). Do the SQL command.
################################################################################
function dosql( $sql )
{ global $mysqli;
$cmd = "insert into log (date,entry) values (NOW(),unhex('" . bin2hex($sql) . "'))"; $res = $mysqli->query( $cmd );
$res = $mysqli->query( $sql );
if( !$res ){ $ary = debug_backtrace();
if( isset($ary[1]) ){ $a = $ary[1]['line']; } else if( isset( $ary[0]) ){ $a = $ary[0]['line']; } else { $a = "???"; } echo "ERROR @ " . $a . " : (" . $mysqli->errno . ")\n" . $mysqli->error . "\n\n"; echo "SQL = $sql\n";
exit;
}
if( preg_match("/insert/i", $sql) ){ return $mysqli->insert_id; } if( preg_match("/delete/i", $sql) ){ return null; } if( !is_object($res) ){ return null; } $cnt = -1;
$ary = array();
$res->data_seek(0);
while( $row = $res->fetch_assoc() ){ $cnt++;
foreach( $row as $k=>$v ){ $ary[$cnt][$k] = $v; } }
return $ary;
}
This outputs:
SQL INJECTION - PLAIN
RES[log_id] = 1
RES[date] = 2015-03-25 10:40:18
RES[entry] = show full columns from log
SQL INJECTION = Hexadecimal
RES[log_id] = 2
RES[date] = 2015-03-25 10:40:18
RES[entry] = select * from log order by title asc
自己好好去琢磨一下！
Tips：
Note that the PLAIN SQL injection actually works - the first record is returned and not the second. But with the hexadecimal put in the correct record is returned. Thus, by using the BIN2HEX and UNHEX commands you no longer have to worry about SQL Injection attacks.
Additionally, overall, the usage of BIN2HEX and UNHEX requires less time to execute than any of the other methods.
This is NOT to say that you shouldn't do checks of whatever you get back from the browser before you put it in to the database. This isn't a magic wand that will fix everything that has ever been wrong with your database or programs. It does though, make it so you do not have to worry about the kinds of SQL injections presented at the beginning of this webpage. Those it will stop.
完