数值参数是否容易受到 SQL 注入攻击？

Are numeric parameters subject to SQL injection attacks?

提问人：k314159 提问时间：6/9/2022 更新时间：6/14/2022 访问量：349

问：

请考虑以下语句：

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

上述内容被认为是安全的，不会受到SQL注入攻击。下面的那个也安全吗，知道那是类型吗？idint

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

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

Java SQL注入

评论

2赞 Progman 6/9/2022
当 实际上是 类型时，不可能进行 SQL 注入。idint
0赞 Joop Eggen 6/9/2022
如果是 int，则不可能进行 SQL 注入，只是溢出。然而，读者很难检查，它是文本和代码的混合体。参数化 SQL 可以外部化为 XML 或其他任何内容。id
3赞 Michael 6/9/2022
目前是安全的。一个问题是，有人可能会在以后决定字符串 ID 更合适，并更改参数类型，而不是实现。在这种情况下，您将容易受到攻击。无论如何，我都喜欢这种方法，因为将 ID 参数更改为 String 需要更改实现，因为如果第二个参数不是整数，则无法编译setIntsetInt
1赞 Bagus Tesa 6/9/2022
只要它的整数就可以了，但是！某些代码分析器可能会将其标记为潜在的 SQL 注入。（对每个人来说）与参数化 SQL 保持一致会更容易，而不是在这里和那里混合字符串 concat。

答：

0赞 SuperPommeDeTerre 6/9/2022 #1

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

评论

3赞 Bagus Tesa 6/9/2022
仅供参考，它被标记为 Java，因此它是一种强类型语言。
3赞 Joseph Hendrix 6/9/2022 #2

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

  1. 将来有人可能会将类型更改为 .idString
  2. 有人可能会将您的代码复制粘贴到代码库的另一部分，然后修改 SQL，使其与 连接起来，使该部分容易受到攻击。String
0赞 Mohammed Housseyn Taleb 6/9/2022 #3

首先，Java 是强类型语言，因此，从实用上讲，SQL 注入不可能进入这部分代码。

但安全性远不止于此。 代码质量也是一个安全级别，不能掉以轻心，如果你在声纳 Qube 服务器中传递此代码片段，它将被撤销。

为什么？

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

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

2赞 Egret 6/11/2022 #4

前面的响应是正确的 - 作为经过验证/键入的 int，这很可能是不可利用的。但应该更改它以使其面向未来并提高性能（数据库可以更轻松地缓存编译后的语句）。

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

上一个：如何修改代码以避免SQL注入攻击？

下一个：Sonarqube 在我的休眠 sql 中警告输入驱动的列名的 sql 注入