api - 使用对外部服务器的 HTTP 调用来检查安全性的安全后果是什么？

Question

我正在与一位同事讨论 API 的开发，以下提议让我怀疑它的安全性。

场景:

有一个在服务器 A 上运行的 Web 应用程序(除其他功能外)允许管理员用户指定任意 URL，并在其帐户内为用户指定与每个 URL 相关的安全性。所以基本上:

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

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

这张支票可以有两种形式:

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 上的网络应用程序的最终用户与网络中与该用户关联的用户 ID 相关联服务器 A 上的应用程序。但让我们假设已经以某种方式优雅地解决了 :-D。

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

Answer 1

HTTPS 确保消息不会被任何中继方(代理等)读取或篡改，但它不保证数据源是可信的。如果另一项服务可以确定其他 URL 和有线格式，则它们可以欺骗对它的请求。这通常是请求签名等使用共享 secret 签名机制发挥作用的地方。 Twilio's API uses this method向您证明他们实际上是在调用您的服务器。 HTTP Signatures是对执行此操作的标准化方法的建议。