Question

我正在与同事讨论API的开发，以下提案让我对它的安全性感到疑惑。

情景：

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

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

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

此检查有两种形式：

服务器端HTTP调用（从服务器B到服务器A）在用户请求来自服务器B的URL的上下文中发生，因此看起来像这样：

 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.

从最终用户的客户端直接向服务器A发出AJAX请求并利用JavaScript响应。跨域脚本编写的问题可能存在问题。

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

我的问题更多地涉及与此类情景相关的固有（in）安全性。如果使用https对服务器A（上述1和2中）发出的请求，那么响应的完整性是否可以计算在内？

Answer 1

HTTPS确保消息无法被任何中继方（代理等）读取或篡改，但不保证数据源是可信的。如果另一个服务可以确定其他URL和有线格式，他们可以欺骗对它的请求。这通常是使用共享秘密签名机制发起请求签名之类的事情。 Twilio's API uses this method向您证明他们实际上是在呼叫您的服务器。 HTTP Signatures是一种标准化方法的提案。

Answer 2

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

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

也就是说，有一些方法可以保护通过客户端的流量，但通常会涉及在服务器上签名数据，因为您无法让客户对其进行签名（您无法将密码放入客户）。

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

2 个答案: