PHP+MYSQL网站SQL Injection攻防

程序员们写代码的时候讲究TDD（测试驱动开发）：在实现一个功能前，会先写一个测试用例，而后再编写代码使之运行经过。其实当黑客SQL Injection时，一样是一个TDD的过程：他们会先尝试着让程序报错，而后一点一点的修正参数内容，当程序再次运行成功之时，注入也就随之成功了。

进攻：

假设你的程序里有相似下面内容的脚本：

$sql = "SELECT id, title, content FROM articles WHERE id = {$_GET[''id'']}";

正常访问时其URL以下：

/articles.php?id=123

当黑客想判断是否存在SQL Injection漏洞时，最经常使用的方式就是在整形ID后面加个单引号：

/articles.php?id=123''

因为咱们没有过滤$_GET[''id'']参数，因此必然会报错，可能会是相似下面的信息：

supplied argument is not a valid MySQL result resource in ...

这些信息就足以说明脚本存在漏洞了，咱们能够再耍点手段：

/articles.php?id=0 union select 1,2,3

之因此select 1,2,3是由于union要求两边的字段数一致，前面是id,title,content三个字段，后面1,2,3也是三个，因此不会报语法错误，还有设置id=0是一条不存在的记录，那么查询的结果就是1,2,3，反映到网页上，本来显示id的地方会显示1，显示title的地方会显示2，显示content的地方会显示3。

至于如何继续利用，还要看magic_quotes_gpc的设置：

当magic_quotes_gpc为off时：

/articles.php?id=0 union select 1,2,load_file(''/etc/passwd'')

如此一来，/etc/passwd文件的内容就会显示在本来显示content的地方。

当magic_quotes_gpc为on时：

此时若是直接使用load_file(''/etc/passwd'')就无效了，由于单引号被转义了，可是还有办法：

/articles.php?id=0 union select 1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100))

其中的数字就是/etc/passwd字符串的ASCII：字符串每一个字符循环输出ord(...)

除此觉得，还可使用字符串的十六进制：字符串每一个字符循环输出dechex(ord(...))

/articles.php?id=0 union select 1,2,load_file(0x2f6574632f706173737764)

这里仅仅说了数字型参数的几种攻击手段，属于冰山一角，字符串型参数等攻击手段看后面的文档连接。

防守：

网络上有一些相似SQL Injection Firewall的软件可供使用，好比说GreenSQL，若是网站已经开始遭受SQL Injection攻击，那么使用这样的快捷工具每每会救你一命，不过这样的软件在架构上属于一个Proxy的角色，多半会影响网站并发性能，因此在选择与否这个问题上最好视客观条件来慎重决定。不少时候专业的软件并非必须的，还有不少轻量级解决方案，下面演示一下如何使用awk来检测可能的漏洞。

建立detect_sql_injection.awk脚本，内容以下（若是要拷贝一下内容的话记得不要包括行号）：

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 }

此脚本可匹配出相似以下的问题代码，想要扩展匹配模式也容易，只要照猫画虎写if match语句便可。

1：$sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
2：$res = mysql_query("SELECT * FROM users WHERE username = ''{$_POST[''username'']}''");

使用前别忘了先chmod +x detect_sql_injection.awk，有两种调用方法：

1：./detect_sql_injection.awk /path/to/php/script/file
2：find /path/to/php/script/directory -name "*.php" | xargs ./detect_sql_injection.awk

会把有问题的代码信息显示出来，样子以下：

CRUD: $sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
FILE: /path/to/file.php
LINE: 123

现实环境中有不少应用这个脚本的方法，好比说经过CRON按期扫描程序源文件，或者在SVN提交时经过钩子方法自动匹配。

使用专业工具也好，检测脚本亦罢，都是被动的防守，问题的根本始终取决于在程序员头脑里是否有必要的安全意识，下面是一些必需要牢记的准则：

1：数字型参数使用相似intval，floatval这样的方法强制过滤。
2：字符串型参数使用相似mysql_real_escape_string这样的方法强制过滤，而不是简单的addslashes。
3：最好抛弃mysql_query这样的拼接SQL查询方式，尽量使用PDO的prepare绑定方式。
4：使用rewrite技术隐藏真实脚本及参数的信息，经过rewrite正则也能过滤可疑的参数。
5：关闭错误提示，不给攻击者提供敏感信息：display_errors=off。
6：以日志的方式记录错误信息：log_errors=on和error_log=filename，按期排查，Web日志最好也查。
7：不要用具备FILE权限的帐号（好比root）链接MySQL，这样就屏蔽了load_file等危险函数。
8：......

网站安全其实并不复杂，总结出来就是一句话：过滤输入，转义输出。其中，咱们上面一直讨论的SQL Injection问题就属于过滤输入问题，至于转义输出问题，其表明是Cross-site scripting，但它不属于本文的范畴，就很少说了。

文档：

addslashes() Versus mysql_real_escape_string()
SQL Injection with MySQL
Advanced SQL Injection with MySQL
MySQL注入中导出字段内容的研究——经过注入导出WebShell

转载自:http://www.aspnetjia.com