PHP安全编程：防止SQL注入

SQL 注入是PHP应用中最多见的漏洞之一。事实上使人惊奇的是，开发者要同时犯两个错误才会引起一个SQL注入漏洞，一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。这两个重要的步骤缺一不可，须要同时加以特别关注以减小程序错误。php

对于攻击者来讲，进行SQL注入攻击须要思考和试验，对数据库方案进行有根有据的推理很是有必要（固然假设攻击者看不到你的源程序和数据库方案），考虑如下简单的登陆表单：mysql

 
      1 
      <form action="/login.php" method="POST"> 
     
      2 
      <p>Username: <input type="text" name="username" /></p> 
     
      3 
      <p>Password: <input type="password" name="password" /></p> 
     
      4 
      <p><input type="submit" value="Log In" /></p> 
     
      5 
      </form>

做为一个攻击者，他会从推测验证用户名和密码的查询语句开始。经过查看源文件，他就能开始猜想你的习惯。算法

好比命名习惯。一般会假设你表单中的字段名为与数据表中的字段名相同。固然，确保它们不一样未必是一个可靠的安全措施。sql

第一次猜想，通常会使用下面例子中的查询：数据库

 
      01 
      <?php 
     
      02 
         
      03 
      $password_hash = md5($_POST['password']); 
     
      04 
         
      05 
      $sql = "SELECT count(*) 
     
      06 
            FROM   users 
     
      07 
            WHERE  username = '{$_POST['username']}' 
     
      08 
            AND    password = '$password_hash'"; 
     
      09 
         
      10 
      ?>

使用用户密码的MD5值原来是一个通行的作法，但如今并非特别安全了。最近的研究代表MD5算法有缺陷，并且大量MD5数据库下降了MD5反向破解的难度。请访问http://md5.rednoize.com/ 查看演示（原文如此，山东大学教授王小云的研究代表能够很快的找到MD5的“碰撞”，就是能够产生相同的MD5值的不一样两个文件和字串。MD5是信息摘要算法，而不是加密算法，反向破解也就无从谈起了。不过根据这个成果，在上面的特例中，直接使用md5是危险的。）。安全

最好的保护方法是在密码上附加一个你本身定义的字符串，例如：服务器

 
      1 
      <?php 
     
      2 
         
      3 
      $salt = 'SHIFLETT'; 
     
      4 
      $password_hash = md5($salt . md5($_POST['password'] . $salt)); 
     
      5 
         
      6 
      ?>

固然，攻击者未必在第一次就能猜中，他们经常还须要作一些试验。有一个比较好的试验方式是把单引号做为用户名录入，缘由是这样可能会暴露一些重要信息。有不少开发人员在Mysql语句执行出错时会调用函数mysql_error()来报告错误。见下面的例子：数据库设计

 
      1 
      <?php 
     
      2 
         
      3 
      mysql_query($sql) or exit(mysql_error()); 
     
      4 
         
      5 
      ?>

虽然该方法在开发中十分有用，但它能向攻击者暴露重要信息。若是攻击者把单引号作为用户名，mypass作为密码，查询语句就会变成：函数

 
      1 
      <?php 
     
      2 
         
      3 
      $sql = "SELECT * 
     
      4 
            FROM   users 
     
      5 
            WHERE  username = ''' 
     
      6 
            AND    password = 'a029d0df84eb5549c641e04a9ef389e5'"; 
     
      7 
         
      8 
      ?>

当该语句发送到MySQL后，系统就会显示以下错误信息：加密

 
      1 
      You have an error in your SQL syntax. Check the manual that corresponds to your 
     
      2 
      MySQL server version for the right syntax to use near 'WHERE username = ''' AND 
     
      3 
      password = 'a029d0df84eb55

不费吹灰之力，攻击者已经知道了两个字段名(username和password)以及他们出如今查询中的顺序。除此之外，攻击者还知道了数据没有正确进行过滤（程序没有提示非法用户名）和转义（出现了数据库错误），同时整个WHERE条件的格式也暴露了，这样，攻击者就能够尝试操纵符合查询的记录了。

在这一点上，攻击者有不少选择。一是尝试填入一个特殊的用户名，以使查询不管用户名密码是否符合，都能获得匹配：

 
      1 
      myuser' or 'foo' = 'foo' --

假定将mypass做为密码，整个查询就会变成：

 
      1 
      <?php 
     
      2 
         
      3 
      $sql = "SELECT * 
     
      4 
            FROM   users 
     
      5 
            WHERE  username = 'myuser' or 'foo' = 'foo' -- 
     
      6 
            AND    password = 'a029d0df84eb5549c641e04a9ef389e5'"; 
     
      7 
         
      8 
      ?>

因为中间插入了一个SQL注释标记，因此查询语句会在此中断。这就容许了一个攻击者在不知道任何合法用户名和密码的状况下登陆。

若是知道合法的用户名，攻击者就能够该用户(如chris)身份登陆。只要chris是合法的用户名，攻击者就能够控制该账号。缘由是查询变成了下面的样子：

 
      1 
      <?php 
     
      2 
      $sql = "SELECT * 
     
      3 
            FROM   users 
     
      4 
            WHERE  username = 'chris' -- 
     
      5 
            AND    password = 'a029d0df84eb5549c641e04a9ef389e5'"; 
     
      6 
      ?>

幸运的是，SQL注入是很容易避免的。正如前面所说起的，你必须坚持过滤输入和转义输出。

虽然两个步骤都不能省略，但只要实现其中的一个就能消除大多数的SQL注入风险。若是你只是过滤输入而没有转义输出，你极可能会遇到数据库错误（合法的数据也可能影响SQL查询的正确格式），但这也不可靠，合法的数据还可能改变SQL语句的行为。另外一方面，若是你转义了输出，而没有过滤输入，就能保证数据不会影响SQL语句的格式，同时也防止了多种常见SQL注入攻击的方法。

固然，仍是要坚持同时使用这两个步骤。过滤输入的方式彻底取决于输入数据的类型（见第一章的示例），但转义用于向数据库发送的输出数据只要使用同一个函数便可。对于MySQL用户，可使用函数mysql_real_escape_string( )：

 
      01 
      <?php 
     
      02 
         
      03 
      $clean = array(); 
     
      04 
      $mysql = array(); 
     
      05 
         
      06 
      $clean['last_name'] = "O'Reilly"; 
     
      07 
      $mysql['last_name'] = mysql_real_escape_string($clean['last_name']); 
     
      08 
         
      09 
      $sql = "INSERT 
     
      10 
            INTO   user (last_name) 
     
      11 
            VALUES ('{$mysql['last_name']}')"; 
     
      12 
         
      13 
      ?>

尽可能使用为你的数据库设计的转义函数。若是没有，使用函数addslashes()是最终的比较好的方法。

当全部用于创建一个SQL语句的数据被正确过滤和转义时，实际上也就避免了SQL注入的风险。若是你正在使用支持参数化查询语句和占位符的数据库操做类（如PEAR::DB, PDO等），你就会多获得一层保护。见下面的使用PEAR::DB的例子：

 
      1 
      <?php 
     
      2 
      $sql = 'INSERT 
     
      3 
            INTO   user (last_name) 
     
      4 
            VALUES (?)'; 
     
      5 
      $dbh->query($sql, array($clean['last_name'])); 
     
      6 
      ?>

因为在上例中数据不能直接影响查询语句的格式，SQL注入的风险就下降了。PEAR::DB会自动根据你的数据库的要求进行转义，因此你只须要过滤输出便可。

若是你正在使用参数化查询语句，输入的内容就只会做为数据来处理。这样就没有必要进行转义了，尽管你可能认为这是必要的一步（若是你但愿坚持转义输出习惯的话）。实际上，这时是否转义基本上不会产生影响，由于这时没有特殊字符须要转换。在防止SQL注入这一点上，参数化查询语句为你的程序提供了强大的保护。

注：关于SQL注入，不得不说的是如今大多虚拟主机都会把magic_quotes_gpc选项打开，在这种状况下全部的客户端GET和POST的数据都会自动进行addslashes处理，因此此时对字符串值的SQL注入是不可行的，但要防止对数字值的SQL注入，如用intval()等函数进行处理。但若是你编写的是通用软件，则须要读取服务器的magic_quotes_gpc后进行相应处理。