JASIG CAS CORS 当 Origin == "null" 时会发生什么？
JASIG CAS CORS what should happen when Origin == "null"?
我正在使用 CAS 服务器来保护我的 Spring 应用程序，其中包括 REST 和 HttpInvoker API。
当应用程序重定向到不同域中的 CAS 服务器时，我们得到 CORS
'issues'。我已将 eBay Cors-Filter https://github.com/eBay/cors-filter 添加到应用程序和 CAS 服务器。
然而...
当应用程序重定向到 CAS 服务器进行身份验证时，Origin header 更改为 'null'。这是由于 CORS 规范（第 14 页，第 7.3 节）中注明的 "privacy-sensitive" 上下文。
...现在终于...问题了！
如果服务器收到 'null' 的 Origin header 是否可以正常进行，只是在 Access-Control-Allow-Origin header 中返回 'null'?
这会破坏什么吗？
不安全吗？
干杯
是的，我相信你可以 return null 或通配符 * 允许任何来源。
Does this break anything?
如果收到 Origin: null 时您只是 returning null 那么它应该不会影响任何其他内容。
Is it unsafe?
我对 CAS 不熟悉，但是只要你不发送 Access-Control-Allow-Credentials，并且你的 CAS 不受 IP 限制或仅在本地网络上，那么这不会比匿名访问更能打开您的系统。有关技术详细信息，请参阅 this answer。
如果您是，则设置 Access-Control-Allow-Origin 将允许其他域和源从用户访问的 CORS 读取数据，使用他们的 cookie 进行 CAS。
允许 null 个来源 不安全。 This blog post 很好地分解了原因。简短的版本是，它启用了一种 CSRF 形式。 null 的允许来源表示 "any page that redirects to me"（或来自 file:/// URL 的任何代码 运行，但这是另一个话题）。
假设您在 app.example.com 的应用使用 service.example.com 的服务，在 auth.example.com 受 CAS 保护。此外，假设您使用 Access-Control-Allow-Origin: null 设置了 service，这样您就可以从指向 auth 的 app 进行提取，并重定向到 service。明白了吗？很好，你为 auth.example.com/cas/login?service=service.example.com 获取数据，登录发生（session cookie 设置在 auth.example.com 上），重定向发生（session cookie 设置在 service.example.com 上），app 从 service 获取数据。由于您的 Access-Control headers，浏览器允许您的应用读取响应。
现在，假设您访问了一个知道您的服务的恶意页面 (evil.com/hello)。他们 运行 evil.com/redir 上的一个 302 页面指向 service.example.com。现在，此恶意代码可以使用 credentials="include" 获取 evil.com/redir。浏览器将请求重定向页面，得到 302 with ACA-Origin=https://evil.com and ACA-Credentials=true, Location of service.example.com。浏览器遵循 302，请求 service.example.com 并包括相关的 session cookie。在此请求中，Origin 设置为 null 但您已将该值列入白名单，因此您的服务发送 null 的 ACA-Origin 值并且浏览器允许（恶意）请求代码查看响应。您刚刚将经过身份验证的数据从您的服务泄漏到注入的脚本，该脚本可以将其发送给攻击者。
我正在使用 CAS 服务器来保护我的 Spring 应用程序，其中包括 REST 和 HttpInvoker API。
当应用程序重定向到不同域中的 CAS 服务器时，我们得到 CORS 'issues'。我已将 eBay Cors-Filter https://github.com/eBay/cors-filter 添加到应用程序和 CAS 服务器。
然而...
当应用程序重定向到 CAS 服务器进行身份验证时，Origin header 更改为 'null'。这是由于 CORS 规范（第 14 页，第 7.3 节）中注明的 "privacy-sensitive" 上下文。
...现在终于...问题了！
如果服务器收到 'null' 的 Origin header 是否可以正常进行，只是在 Access-Control-Allow-Origin header 中返回 'null'?
这会破坏什么吗？
不安全吗？
干杯
是的，我相信你可以 return null 或通配符 * 允许任何来源。
Does this break anything?
如果收到 Origin: null 时您只是 returning null 那么它应该不会影响任何其他内容。
Is it unsafe?
我对 CAS 不熟悉，但是只要你不发送 Access-Control-Allow-Credentials，并且你的 CAS 不受 IP 限制或仅在本地网络上，那么这不会比匿名访问更能打开您的系统。有关技术详细信息，请参阅 this answer。
如果您是，则设置 Access-Control-Allow-Origin 将允许其他域和源从用户访问的 CORS 读取数据，使用他们的 cookie 进行 CAS。
允许 null 个来源 不安全。 This blog post 很好地分解了原因。简短的版本是，它启用了一种 CSRF 形式。 null 的允许来源表示 "any page that redirects to me"（或来自 file:/// URL 的任何代码 运行，但这是另一个话题）。
假设您在 app.example.com 的应用使用 service.example.com 的服务，在 auth.example.com 受 CAS 保护。此外，假设您使用 Access-Control-Allow-Origin: null 设置了 service，这样您就可以从指向 auth 的 app 进行提取，并重定向到 service。明白了吗？很好，你为 auth.example.com/cas/login?service=service.example.com 获取数据，登录发生（session cookie 设置在 auth.example.com 上），重定向发生（session cookie 设置在 service.example.com 上），app 从 service 获取数据。由于您的 Access-Control headers，浏览器允许您的应用读取响应。
现在，假设您访问了一个知道您的服务的恶意页面 (evil.com/hello)。他们 运行 evil.com/redir 上的一个 302 页面指向 service.example.com。现在，此恶意代码可以使用 credentials="include" 获取 evil.com/redir。浏览器将请求重定向页面，得到 302 with ACA-Origin=https://evil.com and ACA-Credentials=true, Location of service.example.com。浏览器遵循 302，请求 service.example.com 并包括相关的 session cookie。在此请求中，Origin 设置为 null 但您已将该值列入白名单，因此您的服务发送 null 的 ACA-Origin 值并且浏览器允许（恶意）请求代码查看响应。您刚刚将经过身份验证的数据从您的服务泄漏到注入的脚本，该脚本可以将其发送给攻击者。