我使用CAS服务器保护我的Spring应用程序，包括REST和HttpInvoker API。
当应用程序重定向到不同域中的CAS服务器时，我们会获得CORS “问题”。我已将eBay Cors-Filter https://github.com/eBay/cors-filter添加到应用程序和CAS服务器。
...然而
当应用程序重定向到CAS服务器进行身份验证时，Origin标头将更改为“null”。这是由于CORS规范（第14页，第7.3节）中提到的“隐私敏感”背景。
......而且，现在终于......问题了！
如果服务器收到一个'null'的Origin头，它可以正常进行，只是在Access-Control-Allow-Origin头中返回'null'吗？
这会破坏什么吗？
不安全吗？
干杯
答案 0 :(得分：1)
允许null来源 是不安全的。 This blog post在分解原因方面做得很好。简短的版本是，它启用了一种CSRF形式。允许的来源null表示“任何重定向到我的页面”（或从file:/// URL运行的任何代码，但这是另一个主题）。
比方说，您在app.example.com处的应用使用了service.example.com处的一项服务，并受auth.example.com上的CAS保护。另外，假设您使用service设置了Access-Control-Allow-Origin: null，以便可以从app进行抓取并指向auth，并重定向到service。知道了吗好的，您为auth.example.com/cas/login?service=service.example.com进行抓取，发生登录（在auth.example.com上设置了会话cookie），发生了重定向（在service.example.com上设置了会话cookie），app从{ {1}}。由于有了service标头，浏览器可以让您的应用读取响应。
现在，假设您访问了一个了解您的服务的恶意页面（Access-Control）。他们在evil.com/hello上运行302页面，该页面指向evil.com/redir。现在，该恶意代码可以使用service.example.com来获取evil.com/redir。浏览器将请求重定向页面，并获得一个credentials="include"，其ACA-Origin = 302和ACA-Credentials = true，https://evil.com中的Location。浏览器跟随302，请求service.example.com并包括相关的会话cookie。在此请求中，service.example.com设置为Origin，但是您将该值列入了白名单，因此您的服务将发送null的ACA-Origin值，并且浏览器允许（恶意）请求代码看到回应。您只是将经过身份验证的数据从服务泄漏到了注入的脚本中，该脚本可以将其发送给攻击者。
答案 1 :(得分：0)
是的，我相信您可以返回null或通配符*以允许任何来源。
这会破坏什么吗？
如果您在收到null后才返回Origin: null，那么它不会影响其他任何内容。
不安全吗？
我不熟悉CAS，但只要您不发送Access-Control-Allow-Credentials，并且您的CAS不受IP或仅限本地网络的限制，那么除了匿名访问之外，这不会打开你的系统。有关技术详情，请参阅this answer。
如果您是，那么设置Access-Control-Allow-Origin将允许其他域和来源使用他们的CAS用于CAS读取来自CORS的数据。