sql 注入 - 如何清理程序生成的 sql 子句？

Question

在标准 Ajax 中，where 和 order by SQL 子句由程序（而非用户）提供，例如

var url = ".select?dd=emp&where="+escape("emp_tp='abc' and hire_dt<current_date-'2 years' and super_emp_id is distinct from emp_id")

在服务器上回答

$where = (isset($_GET['where'])) ? pureClause($_GET['where']) : null;
$order = (isset($_GET['order'])) ? pureClause($_GET['order']) : null;
...
$query = $query.(($where)?" where $where":'').(($order)?" order by $order":'');

问题是pureClause 函数应该是什么样子？

现在pureClause 如果存在以下任何一种情况，就会引发错误：

; select insert update delete drop create truncate

如果其他注入导致查询失败，没关系，只要数据完好。

对我来说这似乎足够了，但在我心里，我知道我错了。

说明：

• 在 Postgres 中准备好的语句虽然非常快，但设置和维护起来很麻烦 - 它们适用于使用良好的查询，但不适用于自定义查询。
• 为每个事务创建一个准备好的语句是一个 巨大的 db 命中。如果可以在应用级别获得安全性，则更可取。

最后，考虑 where 子句

emp_tp='abc' and hire_dt=current_dt-'2 years' and super_emp_id is distinct from emp_id

这里有多少占位符？这需要在被输入带有占位符的准备好的语句之前正确解析，对吗？还是我完全错过了这条船？

---

主要事实：

• 不为参数化的预处理语句编写 SQL 子句解析器并不实际
• 不编写保证无害的 SQL 子句清理程序并不实际

解决方案：

对于 SELECTS，随机 SQL 可能是个问题：既然保护数据库太难了，那就让数据库保护自己吧！有不同的用户有不同的角色/权限。使用只读用户进行选择。对于普通 SQL，这保证了这些语句不会产生 DML。

最佳实践：四个 db 用户访问

1. developer，做所有事情（从不在网络应用中用作连接）
2. dml - 几乎可以在所有东西上选择 / dml（必须用于 dml）
3. read - 可以选择（用于所有选择，无论是准备好的还是文本）
4. login - 只能执行登录/密码功能（在登录过程中使用）

密码保护：

• dml 和 read 可能无法通过 select 或 dml 访问密码数据
• login 应仅通过受保护的函数访问密码数据，例如，

函数登录（用户名，密码） - 返回 user_id 函数 set_password( usr_id, password ) - 设置密码

• 只有login 可以运行login() 和set_password() 函数
• 根据您的数据库，login可能需要 sql 访问密码列
• 根据您的数据库，password 列可能会受到保护；如果没有，那么应该从user 表中移出到它自己的安全表中

使用管理员工具在mysql 中进行设置大约需要 30 分钟，其中包括编写登录功能和拆分密码列的时间。

Answer 1

您所做的是对 sql 注入的定义，无法对其进行清理。您不能以安全的方式故事结束传递WHERE 子句。您必须在服务器端构建这部分查询。您没有意识到这一点的事实意味着您必须阅读更多关于 sql 注入的信息，明确询问 StackOverflow 是解决此问题的不安全方法。令人担心的是，您可能永远无法了解此漏洞的基本原理。

$order 可以通过白名单以安全的方式完成。例如：

if(in_array($_GET['order'],$list_of_rows)){
   $order=$_GET['order'];
}

如果您要传入表名或列名，请确保根据白名单检查它，否则这将是 sql 注入。

Answer 2

知道了！通过仅被授予数据库 SELECT 权限的数据库用户（连接）路由所有这些查询！

尝试的 DML 会阻塞。这并不能防止 DoS 攻击（有很多方法可以做到这一点！），但确实可以保护数据。也不会进行安全查询，例如登录。但是对于客户端生成的 WHERE 和 ORDER，以防止 DML 为目标，这应该可以正常工作。

10/15 年前总是为不同的角色设置不同的用户，但应用层等已经摆脱了这种习惯。重新投资于这些原则可能是个好主意。

除非听到不同的声音会将其标记为正确答案 - 它满足所有标准，但它避开了编写消毒剂理论上不可能的挑战。

Answer 3

始终使用准备好的语句。它将处理输入转义并避免 sql 注入。不需要像pureClause 这样的黑客。 查看mysqli_stmt::prepare()

Answer 4

正如@Stephen 建议的那样，提供 WHERE 作为对象，然后解析对象并生成安全 SQL 变量在哪里 = { emp_tp：{ 条件：相等 值：'abc' } 变种顺序 = { emp_tp: 'ASC' }

以 json 格式发送：

var params = {
  w: where,
  o: order
}
$.post(url,params,function(result){...}, 'json');

在 PHP 中

$where = isset($_POST['w']) ? json_decode($_POST['w') : array();
if (!empty($where)) {
  foreach ($where as $field => $data) {
     // validate that field exists
     // validate that operator is valid
     $sql .= sprintf('%s %s "%s"', $field, $data->operator, mysql_escape_string($data->value));
  }
}