从 SQL 注入保护静态 SQL 查询答案

【问题标题】：Securing a static SQL query from SQL Injection从 SQL 注入保护静态 SQL 查询
【发布时间】：2023-04-03 13:53:01
【问题描述】：

我有一个应用程序可以读取数千个包含数据库参数和静态 SQL 语句的平面文件。在我的 java 代码中，我使用 SQL 语句并执行它。由于可能存在 SQL 注入漏洞，这对于 Fortify 来说是不可接受的。例如我的平面文件如下所示：

query: SELECT USER_ID FROM SOME_TABLE WHERE ID='2'

我接受query 并执行它。

我的问题是如何使这样的静态 SQL 安全？有没有办法将这些 SQL 转换为 PreparedStatements？

【问题讨论】：

那么整个语句被执行了吗？我不认为有资格作为 SQL 注入。可能更多地与围绕可以执行的查询的安全性相关。也许在数据库中设置一个特殊的应用程序用户，具有有限的权限（例如，只能从数据库中读取，不能创建/更新/删除任何东西）。或者，如果您想隐藏某些数据，请仅公开数据库上可以选择的视图，而不是整个表。您还需要一个安全层来保护文件不被编辑。
文件是如何生成的
@Luke 是的，你是对的，这不符合 SQL 注入的条件，因为平面文件对于任何会导致一些安全问题的编辑都是安全的。唯一的问题是带有漏洞的强化扫描。
@Strawberry 是手写文件

【解决方案1】：

如果您不根据用户输入更改从文件中读取的 SQL 语句，则不存在 SQL 注入。

另一方面，如果您无法严格控制该文件中的内容（谁可以编辑它？），那么整个程序就是一个巨大的 SQL 注入器。

即使没有绑定参数，您也可以使用 PreparedStatement 让您的代码审查工具满意。这当然不会以任何方式提高安全性。

【讨论】：

感谢您的回复。似乎我只有一个选项可以进行像 PreparedStatement 这样的查询，但仍然有任何自动化程序可以将我的静态 sql 转换为 PreparedStatement，Fortify 对此也很满意。
为什么需要程序？比conn.prepareStatement(sqlFromFile).execute()复杂吗？
我认为我对这种 SQL 注入非常怀疑。你的解决方案就足够了，我可以在 java 中提供，它甚至可以满足 Fortify。我需要更多地关注如何保护平面文件。如果攻击者受到攻击，他可以尽可能多地操纵它。再次感谢您帮助我:)
请注意，Prepared Statement 本身不会让 Fortify 高兴。它会期望你使用 ?查询定义中的通配符，然后执行设置操作以插入实际数据。这将数据与 SQL 查询分开，防止 SQL 注入。如果您信任保护文本文件的控件并且攻击者编辑该文件的机会是远程的，您可以使用 Fortify 的审核指南来信任文件系统。默认情况下，Fortify 认为文件系统不是受信任的数据源。审计指南中有一个复选框可以改变这种假设。