1

我正在处理的项目有一个用 JRuby/Java 编写的 REST API，其端点可以访问 MySQL 数据库以检索许多记录。

我们需要允许客户端使用一列或多列过滤这些记录，包括布尔检查和范围值。

我们可以做到这一点的最简单方法是向 API 添加一个字符串参数，然后将其添加到 SQL 语句中。

总体而言，开发团队同意这是一个坏主意，但替代方法是提供几乎相同的过滤语法，将其转换为 SQL。SQL 注入参数的吸引力很强。

所以我的问题是，在任何情况下这样做是安全的吗？

特别是，如果 WHERE 子句预先被完全解析并被识别出来，我们是否可以考虑安全地使用它。或者至少，检查某些触发词，例如 DROP、SELECT 等。

此外，如果有人知道一个好的库可以充当中间人（将外部表达式翻译或解析为 WHERE 子句），那就太好了。

4

4 回答 4

2

OData 和 GData 协议已经以安全和标准的方式实现了此功能。您可以找到两者的服务器和客户端实现，用于 Ruby、PHP、MySQL 等。在此处查看 OData 库

于 2012-11-30T15:37:06.633 回答
1

除了安全隐患之外，允许任意 WHERE 子句是一个坏主意，因为它将“I”从“API”中取出——它不是一个接口。API 应该让用户无需了解实现的细节。像表名和列名。

如果客户端通过构建自己的 WHERE 子句与您的数据进行交互，那么您永远无法更改数据库。那里可能有包含这些语句的代码。如果错误或新功能要求您以一种会破坏现有客户端交互的方式更改数据库，那么您将被卡住。API 应该提供过滤功能，并将请求转换为对后端的调用，让您可以在不破坏 API 的情况下更改后端。

于 2012-11-30T15:47:02.383 回答
1

撇开 SQL 注入问题不谈，您将直接以 API 的形式公开您的内部实现（选择的数据库 - MySQL和您的表结构）。

例如，如果您在后端更改为某些 NoSQL 类型的实现，您的面向公众的 API 将立即中断。同样，如果您重组数据库。即使在我不担心注入攻击的可能性/严重性的环境中，我也不会这样做。

于 2012-11-30T15:45:15.197 回答
0

为此目的有许多 ORM，尤其是在 ruby​​ 中（activerecord，sequel）

您需要做的最基本的事情是转义字符串输入，如果您做得正确，这几乎可以防止后续注入。

如果您也不必直接将参数直接插入到后续语句中，它会有所帮助，而是检查它们的有效性，然后将它们映射到逻辑参数（这并不总是可能的）。例如，如果有一个 html 下拉列表，并且当您提交表单时，它会传递一些参数“firstitem”，将“firstitem”映射到一个 id 或其他您将用于搜索的 id，而不是使用用户提供的版本（假设这个映射不涉及数据库）。

于 2012-11-30T21:43:05.077 回答