如何处理遵循 HTTP 303 的标头

Question

我正在尝试确定客户端在从服务器接收到 303（请参阅其他）时应如何处理标头。具体来说，应该如何处理初始请求中发送的Authorization 标头？

这就是问题所在：客户端向myserver.com 发出请求（此处不涉及HTTP 请求方法），myserver.com 的服务器以 303 响应，Location 标头包含otherserver.com/some_resource/。 Postman 和 curl 等工具将通过在后续请求中将 all the same 标头传递给 otherserver.com 来遵循重定向。我还没有找到让这些工具删除标题的方法。

在我所描述的情况下，将Authorization 标头发送到otherserver.com 似乎存在安全风险：otherserver.com 现在知道我的令牌，并且可能知道它可以在哪个主机上使用，所以现在令牌已被泄露。这也可能导致错误，具体取决于目标主机的配置方式。如果重定向到 same 主机上的另一个资源（即myserver.com），那么Authorization 标头将（可能）需要发送，因为它是同一个主机什么都没有被破坏了。

实际上，在不同的情况下，正确的行为似乎是不同的。 RFC 中的relevant section 没有解决这个问题。在开发自己的 API 时，我编写了文档告诉 API 客户端在重定向到 otherserver.com 时删除 Authorization 标头。但是，基于对 curl 和 Postman 的研究，我不清楚 (a) 典型 HTTP 客户端库的默认行为是什么，或者 (b) HTTP 客户端库是否允许轻松修改 HTTP 标头 before 跟随 303 重定向。因此，我的建议可能不切实际。我也知道服务器无法指示客户端在遵循 303 重定向时应该如何处理标头。

当 HTTP 客户端遵循 303 重定向时，它应该如何处理标头？谁负责决定是否在重定向、HTTP 客户端或服务器上使用相同的标头？

Answer 1

您可以争辩说，在发送带有otherserver.com 位置的303 时，myserver.com 信任otherserver.com 来处理您的令牌。它也可以在后台发送令牌。从客户端的角度来看，客户端信任myserver.com 来处理令牌、安全地存储和验证它等。如果myserver.com 决定将其发送到otherserver.com，客户端是否应该覆盖？在这种情况下当然可以，但总的来说我认为不应该。

由于攻击者无法控制来自合法资源 myserver.com 的响应标头，因此我认为通常默认情况下将令牌发送到它指定的其他服务器是安全的，除非您有充分的理由不这样做到（比如对客户端的明确策略）。