数字参数是否会受到 SQL 注入攻击？答案

【问题标题】：Are numeric parameters subject to SQL injection attacks?数字参数是否会受到 SQL 注入攻击？
【发布时间】：2022-06-11 02:59:23
【问题描述】：

考虑一下这个说法：

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM t WHERE id=?");
stmt.setInt(1, id);

以上被认为是安全的免受 SQL 注入攻击。知道id 是int 类型，下面的那个也安全吗？

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM t WHERE id=" + id);

如果没有，会出什么问题？

【问题讨论】：

当id 实际上是int 类型时，不可能进行SQL 注入。
如果id 是一个int，则不可能进行SQL 注入，只会溢出。然而，读者很难检查，它是文本和代码的混合体。参数化的 SQL 可以外部化为 XML 或其他。
现在是安全的。一个问题是，稍后有人可能会决定 String ID 更合适并更改参数类型，但不会更改实现。在这种情况下，你会很脆弱。我喜欢 setInt 方法，因为将 ID 参数更改为 String 需要更改实现，因为如果第二个参数不是整数，setInt 将无法编译
只要是整数就可以了，但是！一些代码分析器可能会将其标记为潜在的 sql 注入。与参数化 sql 保持一致而不是在这里和那里混合字符串 concat 会更容易（对每个人来说）。

标签： java sql-injection

【解决方案1】：

即使id 是一个 int 并且永远不会是其他任何东西，我也能想到两件事可能会出错：

将来有人可能会将id 类型更改为String。
有人可能会将您的代码复制粘贴到代码库的另一部分，然后修改 SQL 使其与 String 连接，从而使该部分易受攻击。

【讨论】：

【解决方案2】：

如果您的语言不支持强类型或输入验证较弱，则某些恶意字符串（例如：“1 OR 1=1”）可能会通过您的请求。

【讨论】：

仅供参考，它被标记为 java，因此它是一种强类型语言。

【解决方案3】：

第一个 Java 是强类型语言，所以从务实的角度来说，sql 注入是不可能进入这部分代码的。

但安全性远不止于此。代码质量也是一个不可掉以轻心的安全级别，如果您在声纳 qube 服务器中传递此代码 sn-p，它将被撤销。

为什么？

首先，如果您不尊重字符串连接，这不是一种性能友好的编码方式。

在大规模应用中，一切都很重要。其中技术债务也是一个漏洞

【讨论】：

【解决方案4】：

之前的响应是正确的 - 作为一个经过验证/键入的 int，这可能是不可利用的。不过应该改成以后的证明吧。

请注意 - 尽管 int 是安全的，但在某些情况下可以通过横向 SQL 注入来利用实数和日期，即使这些值已经过充分验证或来自强类型。此方法使用格式化机制进行注入 - 请参阅 http://www.davidlitchfield.com/Lateral_SQL_Injection_Revisited_Final.pdf.

【讨论】：