SQL Injection: Poor Validation

如果依靠 HTML、XML 及其他类型的编码来验证不受信任的输入，攻击者也许就能够修改语句的含义或者执行任意 SQL 命令。

使用 mysql_real_escape_string() 等编码函数可避免一部分 SQL Injection 漏洞，但不能完全避免。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 SQL Injection 攻击，并且可能允许攻击者修改语句的含义或者执行任意 SQL 命令。由于在动态解释代码的给定部分中不可能总是静态确定输入显示的位置，因此 Fortify 安全编码规则包可能会将经过验证的动态 SQL 数据显示为“SQL Injection: Poor Validation”问题，即使验证可能足以防止在该上下文中出现 SQL Injection 攻击时也是如此。

SQL Injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态地构造 SQL 查询。

示例 1： 以下示例演示数据库配置如何影响 mysqli_real_escape_string() 的行为。 将 SQL 模式设置为“NO_BACKSLASH_ESCAPES” 时，反斜杠字符会被视为正常字符，而不是转移字符[5]。 由于 mysqli_real_escape_string() 将此情况考虑在内，因此鉴于数据库配置，当 " 不再转义为 \" 时，以下查询易受到 SQL Injection 的攻击。

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

如果攻击者将 password 字段留空并为 userName 输入 " OR 1=1;-- ，则不对引号进行转义，最后的查询如下所示：

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

由于 OR 1=1 会导致 where 子句的值始终为 true 且双连字符会导致剩余语句被视为注释，因此该查询在逻辑上就等同于一个更为简单的查询：

  SELECT * FROM users;

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将没有被黑名单引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 SQL 查询输入中的字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

防范 SQL Injection 攻击的另外一种常用解决方法是使用存储过程。 虽然存储过程可以阻止某些类型的 SQL Injection 攻击，但是对于绝大多数攻击仍无能为力。 存储过程有助于避免 SQL Injection 攻击的常用方式是限制可传入存储过程参数的语句类型。 但是，有许多方法都可以绕过这一限制，许多危险的语句仍可以传入存储过程。 所以再次强调，存储过程在某些情况下可以避免一些漏洞，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。