1

我正在和一位同事讨论 API 的开发，下面的提议让我想知道它的安全性。

设想：

在服务器 A 上运行的 Web 应用程序（除其他功能外）允许管理员用户指定任意 URL，以及与每个 URL 相关的帐户中的用户的安全性。所以基本上：

URL:"/foo/bar", UserID:1234, AllowedToView:true

然后，管理员用户在自己的独立服务器 B 上运行自己的 Web 应用程序。他们希望通过检查来检查已登录该服务器 B 应用程序的最终用户是否有权访问该服务器 B 应用程序上的特定 URL服务器 A 上的 API。

此检查可能有 2 种形式：

  1. 发生在用户从服务器 B 请求 url 的上下文中的服务器端 HTTP 调用（从服务器 B 到服务器 A），因此如下所示：

     User requests "/foo/bar" with their client from server B
 During the processing of that request on server B, it makes an HTTP call to server A to check if that user has access to the requested URL
 With the response from server A, server B can then either allow the user to access or redirect, send 403 access denied, etc.

  2. 从最终用户的客户端直接向服务器 A 发出 AJAX 请求，并利用 JavaScript 响应。跨域脚本的问题在这里可能会出现问题。

立即想到的一个挑战是，管理员用户必须有一种方法可以直接将在服务器 B 上访问其 Web 应用程序的最终用户与在服务器上的 Web 应用程序中与该用户关联的 UserID 关联起来A. 但是让我们假设已经以某种方式优雅地解决了:-D。

我的问题更多地与与这种情况相关的固有（内部）安全性有关。如果向服务器 A 发出的请求（在上面的 1 和 2 中）是使用 https 发出的，那么可以指望响应的完整性吗？

4

2 回答 2

1

HTTPS 确保消息不能被任何中继方（代理等）读取或篡改，但不能保证数据的来源是可信的。如果另一个服务可以确定另一个 URL 和有线格式，他们可以欺骗对它的请求。这通常是使用共享秘密签名机制的请求签名之类的东西。Twilio 的 API 使用此方法向您证明它们实际上是在调用您的服务器。HTTP Signatures是对执行此操作的标准化方式的提议。

于 2013-08-09T17:24:33.900 回答
1

如果您真的想保护服务器 B，则不能依赖客户端验证。也就是说，您的第二种情况 - 从客户端调用服务器 A 以查看它是否可以访问资源 - 不是一种安全的方法。你需要指望客户端表现得很好，这当然会让你容易受到攻击。

您的第一个场景 - 服务器到服务器调用是一种安全且首选的方法。您仍然需要使用签名或仅传递共享密钥本身来验证呼叫的来源（使用 HTTPS）来保护您的呼叫。

也就是说，有一些方法可以保护通过客户端的流，但它通常涉及对服务器上的数据进行签名，因为你不能让你的客户端对其进行签名（你不能将你的秘密放在客户端中）。

于 2013-08-09T18:49:30.627 回答