在公共API中允许一些SQL？

Question

我正在公开一个或多或少的公共API，允许用户从数据库中查询数据集。由于用户需要过滤掉特定的数据集，我很想接受SELECT语句的WHERE部分作为API参数。因此，用户可以根据自己的喜好执行复杂的查询，而无需担心混乱的API接口。

我知道我必须捕获SQL注入尝试。

您认为这会绕过API包装数据库的目的太多，还是您认为这是一种理智的方法？

Answer 1

一般来说，我建议不要让他们在他们的请求中嵌入实际的sql

您可以让他们非常轻松地在请求中提交where条件：

<where>
    <condition "field"="name" "operator"="equal" "value"="Fred"/>
</where>

或类似的东西。

这样做的价值是多方面的：

1. 您解析每个条件并确保它们在运行之前是正确的
2. 您可以创建“假”字段，例如可能不存在的“full_name”。
3. 您可以限制他们可以在
上添加条件的列
4. 您可以将用户与基础数据库中的实际更改隔离开来。

我认为最后一点实际上是最重要的。当您需要更改数据库的基础架构时，这一天将到来。最终，它会发生。此时，您会欣赏在用户发送的内容和查询之间有一些“翻译”层。它允许您将用户与基础数据库中的实际更改隔离开来。

API应提供满足用户需求的实际表本身的“抽象”版本，并将其与实际底层数据库的更改隔离开来。

Answer 2

我建议通过修改权限来限制用户帐户，只允许用户从表中SELECT。不允许更新，插入或删除记录集。尽可能地锁定用户，可能是在桌面级别。

Answer 3

如果WHERE子句仅限于几列且比较器限于>, =或<，那么也许您可以让用户传入一些额外的参数来表示列和比较器。然后，您可以在服务器端安全地构建WHERE。

如果这太乱了，那么一定要让他们传递一个完整的WHERE条款 - 清理它并不难，如果你把它与在一个锁定的帐户下运行查询结合起来{{1}只有），那么任何潜在的伤害都是有限的。

Answer 4

我个人不希望允许用户能够直接将SQL传递到我的数据库，风险太大了。

如果您未能捕获所有注射尝试，则可能会导致数据被盗，有人只是破坏您的数据库或者将其劫持用于您真正不想要的其他用途。