3

我们正在将我们的 Web 应用架构转变为基于微服务的架构。关于提供内容（例如 JSON 格式）的 REST API 是否应该寻求对内容进行编码以使其安全，或者获取该内容并显示它的消费者（例如，以 HTML 格式，或以其他方式使用它）应该负责该编码。用例是防止 XSS 攻击和类似的攻击。

提供者的立场是“好吧，我们不知道如何为每个人编码，或者你将如何使用内容，所以消费者当然应该对内容进行编码。”

消费者的立场是“有一个提供者和多个消费者，因此在提供 API 中做一次比希望每个消费者都做更安全。”

是否有任何普遍接受的最佳实践，为什么？

4

3 回答 3

4

通常，通过“内部”流程（无论可能意味着使用什么）的数据应该以任何有意义的“内部”格式存储或编码。所选格式通常旨在最大限度地减少编码/解码步骤并防止数据丢失。

然后，在输出时，使用任何有意义的输出格式对数据进行编码。防止数据丢失很重要，但正确的转义和格式化也是关键。

因此，例如，对于内部 API，二进制格式的数据可能就足够了。但是当您输出 JSON 或 HTML 或 XML 或 PDF 时，您必须对数据进行适当的编码和转义以适应输出格式。

这里重要的一点是，不同的输出格式有不同的“安全”概念。HTML 的“安全”对于 JSON 可能不安全，而 JSON 安全的对于 SQL 可能不安全。数据在输出时专门进行编码，以便您可以为任务使用正确的编码。您不能假设此步骤已提前为您完成，也不应将输出函数置于确定是否必须进行编码的位置。如果您遵守规则：“输出函数总是为了安全而编码”，那么您将永远不必担心数据注入攻击。

于 2013-07-20T05:10:31.080 回答
3

我想说两点很重要：

  • 提供者使用的编码必须在参考文档中以极其清晰和精确的方式指定，以便所有消费者实现者都可以知道会发生什么。
  • 无论提供者使用什么默认编码，都必须保留所有需要的信息，即仍然可以被任何希望这样做的消费者进行转码。

如果您遵循这两条规则，那么您将完成 95% 的可靠性和安全性工作。

至于您的具体问题，一个好的做法是中间立场：提供者默认遵循“通用”编码，但消费者可以（可选）要求提供者可能应用的特定编码 - 这允许提供者支持许多可能不同类型的愚蠢的轻量级客户端，并且可以在以后使用额外的编码进行扩展而不会破坏 API。

于 2013-07-19T21:24:07.640 回答
3

我坚信消费者和提供者都需要尽自己的一份力量成为安全领域的好公民。

作为提供商，我想确保我提供安全的产品。我不需要知道我的客户将使用我的产品的环境，我只需要知道我将如何交付它。如果我的交付是 JSON，那么我可以在发送数据之前使用该上下文来转义我的数据，对于 XML、纯文本等也是如此。此外，已经有一些传输方法有助于提高安全性。JSONP 就是这样一种交付方式。这确保了有效负载被适当地消耗。

作为消费者，顺便说一下，在我们的环境中没有人是最终消费者，我们都是最终客户端的提供者（主要是通过网络浏览器的最终用户。）。因此，我们还必须为此保护数据。我永远不会相信黑盒 API 会为我完成这项工作，我总是会强调确保有效载荷的安全。那里有很多工具，我想到了来自 OWASP 的 ESAPI 项目，它们将有助于通过数据上下文进行清理。请记住，您最终会将这些数据发送给最终用户（浏览器），如果出现问题，您将无法推卸责任。无论缺陷在哪里，您的服务都将被视为易受攻击的服务。此外，作为消费者，您可能并不总是能够依赖黑盒提供商及时修复他们的缺陷。如果他们缺乏支持或他们有更高的优先级怎么办。这是否意味着您继续向最终用户提供已知缺陷？

安全性是关于层次的，在源头和端点上都有保护措施总是更可取的。

于 2013-07-19T22:39:36.280 回答