这种 SQL 构造是不是容易发生 SQL 注入？ [关闭]

Posted 2023-02-19

【中文标题】这种 SQL 构造是不是容易发生 SQL 注入？ [关闭]

【英文标题】：Is this SQL construction prone to SQL Injection? [closed]这种 SQL 构造是否容易发生 SQL 注入？ [关闭]

【发布时间】：2022-01-11 07:20:49

【问题描述】：

注意：任何 SQL 后端都适用于示例（Oracle、SQL Server、mysql、Postgres），但对于我的示例，我使用 MySQL 进行测试。

---

我想知道下面的构造是否容易出现 SQL 注入：

SELECT
    field1,
    field2,
    %s
FROM
    tbl

并且用户可以在那里输入原始字符串。我可以允许错误的输入，但想看看用户是否可以对此做任何有害的事情，前提是我删除了某些字符，例如;。因此，如果用户尝试这样做：

SQL % ('DROP TABLE users; ')

SQL 只会变成无效的 sql，但不一定是恶意的：

SELECT
    field1,
    field2,
    DROP TABLE users
FROM
    tbl

但是考虑到一个天才用户能够在这里编写任何字符串，以上内容对于恶意 SQL 注入是否安全，如果不是，这里可以使用什么示例字符串来执行此操作？

【问题讨论】：

"...并且用户可以在那里输入原始字符串..." -- 是的，根据定义，这很容易受到 SQL 注入的攻击。

每个引擎都有它的特性和错误。您可能无法在查询中轻松找到“漏洞”，但请放心，黑客会的。

您不应该只关心恶意 SQL 注入。您的应用程序应保护用户免受导致您的应用程序出现故障的善意输入。就像您希望允许名为“O'Reilly”的人在您的网站上输入他们的姓名而不会导致错误一样。

但是要回答您的问题，是的，恶意用户可能会通过多种方式造成恶作剧。他们不能从 SELECT 语句中删除表，但他们可以从通常无权读取的其他表中读取数据。或者他们可以执行如此昂贵的查询，从而导致拒绝向其他用户提供服务。我不会详细说明如何执行此操作。

0; DROP TABLE Users; SELECT 1 或 (SELECT passwordHash FROM Users WHERE Admin = 1) 怎么样

【参考方案1】：

您的情况的解决方案是永远不要使用来自后端层外部的字符串组装 SQL 语句。因此，请使用存储在后端内部的字符串。

例如，如果用户可以在 UI 中选择 20 列，则接收一个从 1 到 20 的数字，然后您可以创建一个 IF/ELSE 序列，该序列将为每个数字附加相应的列。

这样，来自外部的参数永远不会被组装到 SQL 语句中，而是使用来组装 SQL 查询。