如果你从网页中获取用户输入,并将其插入到 SQL 数据库中的话,那么你很可能已经暴露于一种被称作 SQL 注入的安全风险之下了。
本节将会教你如何防止 SQL 注入,以及如何保护 Perl 这样的服务器端脚本中的程序和 SQL 语句。
注入通常发生在获取用户输入的时候,例如预期得到用户的名字,但是得到的却是一段很可能会在你不知情的情况下运行的 SQL 语句。
绝对不要相信用户提供的数据,处理这些数据之前必须进行验证;通常,验证工作由模式匹配来完成。
下面的例子中,name 仅限由字母、数字和下划线组成,并且长度在 8 到 20 之间(你可以根据需要修改这些规则)。
if (preg_match("/^\w{8,20}$/", $_GET['username'], $matches))
{
$result = mysql_query("SELECT * FROM CUSTOMERS
WHERE name=$matches[0]");
}
else
{
echo "user name not accepted";
}
为了展示问题所在,请考虑下面这段代码:
// supposed input
$name = "Qadir'; DELETE FROM CUSTOMERS;";
mysql_query("SELECT * FROM CUSTOMSRS WHERE name='{$name}'");
下面的函数调用本来是要从 CUSTOMERS 表中取得 name 字段与用户给定的输入相匹配的记录。通常情况下,$name 只包含字母和数字,或许还有空格,例如字符串 ilia。但是,这里通过在 $name 上附加一段全新的查询语句,将原有的函数调用变为了数据库的灾难:注入的 DELETE 语句将会删除表中所有的记录。
幸运的是,如果你在使用 MySQL 的话,mysql_query() 函数不允许查询堆积(query stacking),或者说在一次函数调用中执行多次 SQL 查询。如果你试图进行堆积式查询的话,函数调用将会失败。
然而,其他的 PHP 数据库扩展,例如 SQLite 和 PostgreSQL 会愉快地接受堆积式查询,执行字符串中所有的查询,并由此产生严重的安全问题。
你可以在 Perl 或者 PHP 等脚本语言中巧妙地处理所有的转义字符。PHP 的 MySQL 扩展提供了一个 mysql_real_escape_string() 函数,来转义那些对 MySQL 有特殊意义的字符。
if (get_magic_quotes_gpc())
{
$name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query("SELECT * FROM CUSTOMERS WHERE name='{$name}'");
要破解 LIKE 困境,必须有一种专门的转义机制,将用户提供的 '%' 和 '_' 转换为字面值。为此你可以使用 addcslashes() 函数,该函数允许指定要进行转义的字符的范围。
$sub = addcslashes(mysql_real_escape_string("%str"), "%_");
// $sub == \%str\_
mysql_query("SELECT * FROM messages
WHERE subject LIKE '{$sub}%'");
(c) 2024 chaojicainiao.com MIT license