为什么我的两个 Web 应用程序之间使用带查询参数的重定向或自动表单发布交换的数据无法被每个 Web 应用程序信任，即使使用 HTTPS？
笔记：
我理解使用查询参数进行数据交换具有固有的安全性CSRF 等风险、通过浏览器历史记录和访问日志泄露数据， 和auto-form-post 存在固有的 CSRF 安全风险。不过，这不是我们讨论的重点。我们假设我们已经缓解了 CSRF。现在的问题是，“为什么每个 Web 应用程序都不能信任交换的数据，即使使用 HTTPS？”
用例： 考虑运行在https://one.abc.com和https://two.xyz.com。他们都希望交换数据，但无法直接通信。
详细流程： 参观时https://one.abc.com，页面显示一个按钮。单击后，它将提交到https://one.abc.com，然后重定向到https://two.xyz.com。 在https://two.xyz.com，存在另一个按钮，当点击时，提交到https://two.xyz.com并重定向至https://one.abc.com。
由于一切都通过 HTTPS 进行，因此所有元素（包括 URL、查询参数和标头）在重定向期间都会被加密。
通过此设置，可以使用查询参数或自动表单发布实现两个 Web 应用程序之间的数据交换。
但是，为什么每个 Web 应用程序都不能信任交换的数据，即使使用 HTTPS？
简单来说，在第一步中，如果https://one.abc.com使用带有查询参数的重定向或自动表单发布将数据发送到https://two.xyz.com，则即使使用 HTTPS，https://two.xyz.com也不能相信数据确实来自。https://one.abc.com
类似地，在第二步中，如果https://two.xyz.com使用带有查询参数的重定向或自动表单发布将数据发送到https://one.abc.com，则即使使用 HTTPS，也https://one.abc.com不能相信数据确实来自。https://one.abc.com
上述技术在 SAML、OIDC 中用于 SSO。
请告诉我我的以下理解是否正确：
one.abc.com在上述从到two.xyz.com以及返回 的重定向流程中one.abc.com，TLS（传输层安全性）加密是在您的浏览器和所涉及的每个服务器之间单独建立的。让我们分解一下流程：
从one.abc.com到two.xyz.com：
- 当您点击 按钮时，您的浏览器将通过 HTTPS（HTTP over TLS）
one.abc.com发起请求。one.abc.com one.abc.com通过重定向响应（HTTP 302 Found）进行响应，指示您的浏览器转到two.xyz.com。- 然后，您的浏览器会向 发起新的 HTTPS 请求
two.xyz.com，从而在您的浏览器和 之间建立单独的 TLS 连接two.xyz.com。
从two.xyz.com回到one.abc.com：
- 当您点击 按钮时，您的浏览器将通过 HTTPS（HTTP over TLS）
two.xyz.com发起请求。two.xyz.com two.xyz.com通过重定向响应（HTTP 302 Found）进行响应，指示您的浏览器转到one.abc.com。- 然后，您的浏览器会向 发起新的 HTTPS 请求
one.abc.com，从而在您的浏览器和 之间建立单独的 TLS 连接one.abc.com。
这些连接中的每一个（从您的浏览器到two.xyz.com以及从您的浏览器回到one.abc.com）都使用 TLS 单独加密。TLS 加密可确保您的浏览器与每个服务器之间通信的机密性和完整性，从而保护重定向流程期间交换的数据。
two.xyz.com但是，在重定向流程之间和期间没有建立直接的 TLS 连接one.abc.com。相反，HTTPS 连接在每个服务器端点上分别终止和重新建立。
因此，在 SAML 中，IDP 对 进行签名SAML assertion，而在 OIDC 中，OIDC 提供商对 进行签名id_token。
答案1
您不能信任从客户端（潜在攻击者）传递的任何数据。
本质上，重定向会导致客户端更改服务器。根据应用程序的不同，数据可能会转移到由用户。
如果无法验证这些数据，攻击者可能会伪造其中任何数据。同样，您可能用来验证重定向的引荐来源也是另一部分可以毫不费力伪造的数据。
使用 HTTPS 加密不会改变这一点。HTTPS 会加密客户端和服务器之间的数据，但不会验证该数据的来源。攻击者之间客户端和服务器无法读取或更改传递的数据，但如果攻击者是客户端，那么 SSL 就无济于事了。
可靠的方法需要服务器之间进行安全的数据交换或对客户端传递的数据进行加密签名。