为什么使用带有查询参数的重定向或自动表单发布在两个 Web 应用程序之间交换的数据不能被每个 Web 应用程序信任,即使使用 HTTPS 也是如此?
笔记:
据我了解,使用查询参数进行数据交换具有固有的安全风险,例如 CSRF、通过浏览器历史记录和访问日志泄露数据,而自动表单发布具有固有的 CSRF 安全风险。不过,这不是这里讨论的重点。假设我们减轻了 CSRF。当前的问题是,“为什么每个 Web 应用程序都不能信任交换的数据,即使使用 HTTPS 也是如此?”
用例:考虑在https://one.abc.com和https://two.xyz.com 上运行的两个 Web 应用程序。他们都希望交换数据但无法直接通信。
详细流程: 访问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://two.xyz.com
则无法相信数据确实源自https://one.abc.com
,即使使用 HTTPS 也是如此。
同样,在第二步中,如果https://two.xyz.com
使用带有查询参数的重定向或自动表单发布将数据发送到https://one.abc.com
,https://one.abc.com
则无法相信数据确实源自https://one.abc.com
,即使使用 HTTPS 也是如此。
上述技术用于 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
但是,重定向流之间以及one.abc.com
重定向流期间没有建立直接的 TLS 连接。相反,HTTPS 连接在每个服务器端点处单独终止和重新建立。
因此,在 SAML 中,IDP 签署SAML assertion
,而在 OIDC 中,OIDC 提供商签署id_token
。