在工作中，我们使用为其他应用程序提供基本 SSO 功能的中央门户。除了验证发送的 SSO 数据外，我们所有现有的内部应用程序（供公众使用）还检查引荐来源标头，以确保用户实际上来自我们的中央门户。但是，我们刚刚遇到了一个问题，即中央门户中的 JavaScript 代码更改导致 Internet Explorer 停止转发引荐来源标头，从而导致所有检查该标头的应用程序停止运行。
我的问题是，与仅检查基本 SSO 信息（cookie 中包含的加密用户 ID）相比，检查引荐来源标头是否提供了任何现实世界的安全改进？如果没有，是否有任何文档/研究/等。我可以用来向管理层证明这一点吗？
我还应该提到的是，不幸的是，中央门户是一个第三方应用程序，我们无法对其进行太多控制……因此，加密 cookie 形式的基本 SSO 信息和引荐来源标头信息是我们帮助保护事情的全部。
简短的回答：没有。
长答案：这取决于.
Referer 是由客户端发送和控制的标头。您不能信任来自客户端的未经检查的任何数据。正如其他人指出的那样，它很容易被操纵。它可以包含攻击者想要的任何东西，所以不要依赖它。
如果您的 URL 包含任何加密令牌（http://site.com/x.php?op=1&token=-random-data-），它可能会有点用处。您必须使用会话变量检查令牌以确定标头是否未被篡改。
但即使使用令牌，Referer 检查也只会在新的浏览器/插件/扩展/代理出于隐私原因开始剥离Referer 标头之前起作用。
如果可能，您可以尝试使用绑定到浏览器指纹标头 ( User-Agent, Accept, Accept-Language) 的客户端 IP 地址来获得更多安全层。将这些标头保存在会话变量中，您可以检测是否有人窃取了您的用户的凭据、是否有人试图绕过身份验证以及其他攻击。
它会摘下低垂的果实，但总的来说，恶搞一个标题并不难。我想说，如果它在过去引起了问题，那么很可能不值得为您的业务应用程序冒险。
最好的方法可能是向管理层证明绕过这种安全措施是多么容易。
您可以使用例如 Burp 代理 ( http://portswigger.net/burp/download.html ) 来拦截和修改/添加引用标头。
正如其他人已经解释的那样，引荐来源很容易被欺骗。此外，根据 HTTP 标准，它们完全是可选的。某些浏览器的隐私设置和插件总是抑制引荐来源，并且没有任何恶意。
出于这个原因，我建议您不要将推荐人视为正确的推荐人，并且仅在推荐人明确指向您无法控制的网站时拒绝请求。