在你的 SQL 中限制 OR 条件可以修复 SQL 注入漏洞吗？答案

【问题标题】：Will limiting OR conditions in your SQL can fix SQL injection vulnerbilty?在你的 SQL 中限制 OR 条件可以修复 SQL 注入漏洞吗？
【发布时间】：2019-05-05 16:05:22
【问题描述】：

我们的网站被报告为易受 SQL 注入攻击，修复此漏洞的开发人员告诉他们必须限制搜索条件中的 OR 子句。

以前用户搜索的订单数量大约为 500 个，现在已受到限制。正如他所说，根据 SQL 注入实践，您必须限制 SQL 中的 OR 条件。

例如，以下日志显示了那些 OR 条件，根据他的说法，这些条件是有限的。

还好吗？他的说法是对的吗？

编辑：数据库是 Oracle 11.2。

条件：

and (UPPER(online_order_id) LIKE :param_online_order_id0
or UPPER(online_order_id) LIKE :param_online_order_id1
or UPPER(online_order_id) LIKE :param_online_order_id2
or UPPER(online_order_id) LIKE :param_online_order_id3
or UPPER(online_order_id) LIKE :param_online_order_id4
or UPPER(online_order_id) LIKE :param_online_order_id5 
or UPPER(online_order_id) LIKE :param_online_order_id6 
or UPPER(online_order_id) LIKE :param_online_order_id7
or UPPER(online_order_id) LIKE :param_online_order_id8
or UPPER(online_order_id) LIKE :param_online_order_id9 
or UPPER(online_order_id) LIKE :param_online_order_id10
or UPPER(online_order_id) LIKE :param_online_order_id11
or UPPER(online_order_id) LIKE :param_online_order_id12
or UPPER(online_order_id) LIKE :param_online_order_id13
or UPPER(online_order_id) LIKE :param_online_order_id14
or UPPER(online_order_id) LIKE :param_online_order_id15
or UPPER(online_order_id) LIKE :param_online_order_id16
or UPPER(online_order_id) LIKE :param_online_order_id17
or UPPER(online_order_id) LIKE :param_online_order_id18
or UPPER(online_order_id) LIKE :param_online_order_id19
or UPPER(online_order_id) LIKE :param_online_order_id20
or UPPER(online_order_id) LIKE :param_online_order_id21
or UPPER(online_order_id) LIKE :param_online_order_id22
or UPPER(online_order_id) LIKE :param_online_order_id23
or UPPER(online_order_id) LIKE :param_online_order_id24
or UPPER(online_order_id) LIKE :param_online_order_id25
or UPPER(online_order_id) LIKE :param_online_order_id26
or UPPER(online_order_id) LIKE :param_online_order_id27
or UPPER(online_order_id) LIKE :param_online_order_id28
or UPPER(online_order_id) LIKE :param_online_order_id29
or UPPER(online_order_id) LIKE :param_online_order_id30
or UPPER(online_order_id) LIKE :param_online_order_id31
or UPPER(online_order_id) LIKE :param_online_order_id32
or UPPER(online_order_id) LIKE :param_online_order_id33
or UPPER(online_order_id) LIKE :param_online_order_id34
or UPPER(online_order_id) LIKE :param_online_order_id35
or UPPER(online_order_id) LIKE :param_online_order_id36
or UPPER(online_order_id) LIKE :param_online_order_id37
or UPPER(online_order_id) LIKE :param_online_order_id38
or UPPER(online_order_id) LIKE :param_online_order_id39
or UPPER(online_order_id) LIKE :param_online_order_id40
or UPPER(online_order_id) LIKE :param_online_order_id41
or UPPER(online_order_id) LIKE :param_online_order_id42
or UPPER(online_order_id) LIKE :param_online_order_id43
or UPPER(online_order_id) LIKE :param_online_order_id44
or UPPER(online_order_id) LIKE :param_online_order_id45
or UPPER(online_order_id) LIKE :param_online_order_id46
or UPPER(online_order_id) LIKE :param_online_order_id47
or UPPER(online_order_id) LIKE :param_online_order_id48
or UPPER(online_order_id) LIKE :param_online_order_id49
or UPPER(online_order_id) LIKE :param_online_order_id50
or UPPER(online_order_id) LIKE :param_online_order_id51
or UPPER(online_order_id) LIKE :param_online_order_id52
or UPPER(online_order_id) LIKE :param_online_order_id53
or UPPER(online_order_id) LIKE :param_online_order_id54
or UPPER(online_order_id) LIKE :param_online_order_id55
or UPPER(online_order_id) LIKE :param_online_order_id56
or UPPER(online_order_id) LIKE :param_online_order_id57
or UPPER(online_order_id) LIKE :param_online_order_id58
or UPPER(online_order_id) LIKE :param_online_order_id59
or UPPER(online_order_id) LIKE :param_online_order_id60
or UPPER(online_order_id) LIKE :param_online_order_id61
or UPPER(online_order_id) LIKE :param_online_order_id62
or UPPER(online_order_id) LIKE :param_online_order_id63
or UPPER(online_order_id) LIKE :param_online_order_id64
or UPPER(online_order_id) LIKE :param_online_order_id65
or UPPER(online_order_id) LIKE :param_online_order_id66
or UPPER(online_order_id) LIKE :param_online_order_id67
or UPPER(online_order_id) LIKE :param_online_order_id68
or UPPER(online_order_id) LIKE :param_online_order_id69
or UPPER(online_order_id) LIKE :param_online_order_id70
or UPPER(online_order_id) LIKE :param_online_order_id71)

【问题讨论】：

防止 SQL 注入的唯一安全方法是使用绑定变量（“准备好的语句”）。 OR 条件的数量与此无关（一个非常非常长的 OR 条件列表可能打开拒绝服务攻击的风险，具体取决于所使用的 DBMS，但不是注入攻击)
您使用哪种编程语言？
你为什么要比较 online_order_id 和 72 个参数？！ (:param_online_order_id0 -> :param_online_order_id71) 这有代码味道。 :-)
他们修好了，但修错了。他们没有在 Oracle 端引入数组类型并将 that 作为一个参数的类型，而是决定将每个值（具有相同“类型”）作为单独的参数传递。跨度>
您展示的代码不易易受 SQL 注入攻击。然而，300+ OR 条件可能意味着 Oracle（尤其是旧版本）需要大量时间来优化该语句。

标签： sql oracle sql-injection

【解决方案1】：

在执行此类功能的代码中经常看到 SQL 注入，因为代码将一个 in 子句放在一起，该子句由将值连接在一起形成的子句（通常没有验证）。

正如一些人在 cmets 中指出的那样 - 您的开发人员很可能修复了 SQL 注入，但这样做的方式可能会导致性能问题和其他限制。开发人员正确地遵循了使用参数化查询（绑定变量）的一般指导，但在这种情况下盲目地遵循该指导并不能很好地工作。

解决此问题的最佳方法（正如 Damien_The_Unbeliever 所提到的）是将其绑定到 Oracle DB 端的 array type - 这只需要一个绑定，并且将为您提供最佳性能。这需要在 DB 端添加一个对象，因此实现起来比较复杂。

另一种选择是继续使用 in 子句，但确保代码在值被连接时验证它们 - 在订单 ID 的情况下，您可能只需检查它是否为整数。这不会像第一个选项那样执行，但会更优雅地处理大量订单。

【讨论】：