降低golang服务中下游服务SQL注入风险的最佳实践

在编写 Go 语言 Web 服务时，确保下游服务免受 SQL 注入至关重要。当用户输入字符串用于 MySQL 查找时，存在潜在的 SQL 注入风险。本文探讨了在无法控制数据库调用时，在 Go 代码中净化用户输入的最佳实践。尽管预准备语句通常是防止 SQL 注入的有效方法，但如果下游数据库调用无法立即审核，就需要采取替代措施。

我正在用 golang 编写一个半面向外部的 Web 服务，让用户可以查询有关其帐户的信息，这些信息分布在多个内部遗留服务中。

我的服务将用户输入字符串传递到多个后端 RESTful API，这些 API 根据字符串进行 MySQL 查找以生成结果，这些结果将传回我的服务以提供给用户。

从历史上看，这些遗留后端服务并未暴露给用户输入，因此我不确定它们是否针对 SQL 注入采取了适当的防护措施。

通常，我会使用预准备语句来防止 SQL 注入，以防止数据库引擎将用户字符串视为可解析，但在这种情况下，我不控制数据库调用 - 它们位于下游，而且不切实际立即审核它们。

我可以在 golang 代码中做些什么来尽可能地净化用户输入，以最大限度地降低 SQL 注入的风险？这最终只是一个权宜之计，直到所有下游数据库调用都可以进行注入安全审核。

编辑：出于所有实际目的，用户输入可以是任意字符串，但它不应该是可执行代码。我的服务需要来自用户的字段值，而不是代码。

解决方案

在过去的工作中，我维护了一个允许临时查询的服务设施。它允许管理人员请求报告，而无需等待数周的代码部署（回到部署需要数周的古怪日子）。

我们不支持临时报告查询，方法是让服务接受任意字符串作为输入并将它们作为 sql 执行。我相信你知道，这是非常不安全的。

其工作方式是将报表查询以及所需的查询参数数量存储在数据库中。

CREATE TABLE ManagerQueries (
  id INT PRIMARY KEY,
  query TEXT NOT NULL,
  description TEXT NOT NULL,
  num_params TINYINT UNSIGNED NOT NULL DEFAULT 0
);

INSERT INTO ManagerQueries
SET query = 'SELECT COUNT(*) FROM logins WHERE user_id = {0} AND created_at > {1}',
    description = 'Count a given user logins since a date',
    num_params = 2;

管理器前端可以通过其主键请求查询，而不是通过在 web 请求中指定任意 sql 字符串。

只有 dba 以及其他知道如何编写安全查询的开发人员或经理才被允许向此存储库添加新查询，因此可以保证查询经过测试和审查。

当通过 ui 请求报告查询时，它会强制用户提供查询参数的值。在我们的例子中，它从数据库读取 sql，执行 prepare()，然后绑定 execute() 的值。这样sql注入防御就满足了。

在您的情况下，您的代码可能无法直接访问旧服务的数据库，因此您无法进行准备/执行和使用绑定参数。您必须提交包含集成值的静态查询。

在其他语言中，您可以通过转义使任何字符串值安全地插值到 sql 查询中。请参阅 mysql c api 函数 mysql_real_escape_string()。

数值更容易。您不必转义任何内容，只需确保数值是真实的数字即可。一旦将动态值转换为数字，就可以安全地插回任何 sql 字符串。

不幸的是，我认为 golang sql 包不支持任何转义函数。已要求将此作为一项功能，但据我所知，尚无支持的实现。请参阅此处的讨论：https://github.com/golang/go/issues/18478

所以你可能必须实现自己的转义函数。例如，您可以在官方 mysql c 实现之后对其进行建模：https://github.com/mysql/mysql-server/blob/8.0/mysys/charset.cc#L716

请注意，这比仅使用正则表达式替换要棘手一些，因为您需要考虑多字节字符集。

添加到 bill 的涉及数据输入的答案中。为了确保输出数据的卫生，例如网络服务，请查看 html/template：

以上就是《降低golang服务中下游服务SQL注入风险的最佳实践》的详细内容，更多关于的资料请关注golang学习网公众号！