此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Security 6.3.3! |
此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Security 6.3.3! |
有许多 HTTP 响应标头可用于提高 Web 应用程序的安全性。 本节专门介绍 Spring Security 为其提供显式支持的各种 HTTP 响应标头。 如有必要,还可以将 Spring Security 配置为提供自定义 Headers。
默认安全标头
Spring Security 提供了一组与安全相关的默认 HTTP 响应 Headers 来提供安全的默认值。
Spring Security 的默认值是包含以下 Headers:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Strict-Transport-Security 仅在 HTTPS 请求上添加 |
如果默认值不能满足您的需求,您可以轻松地从这些默认值中删除、修改或添加标头。 有关每个标头的其他详细信息,请参阅相应的部分:
Strict-Transport-Security 仅在 HTTPS 请求上添加 |
缓存控制
Spring Security 的默认设置是禁用缓存以保护用户的内容。
如果用户通过身份验证查看敏感信息,然后注销,我们不希望恶意用户能够单击后退按钮来查看敏感信息。 默认情况下发送的缓存控制标头为:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
为了在默认情况下是安全的,Spring Security 默认添加这些 Headers。 但是,如果您的应用程序提供自己的缓存控制 Headers,则 Spring Security 将退出。 这允许应用程序确保可以缓存 CSS 和 JavaScript 等静态资源。
内容类型选项
过去,浏览器(包括 Internet Explorer)会尝试使用内容探查来猜测请求的内容类型。 这允许浏览器通过猜测未指定内容类型的资源上的内容类型来改善用户体验。 例如,如果浏览器遇到未指定内容类型的 JavaScript 文件,它将能够猜测内容类型,然后运行它。
在允许上传内容时,还应该做许多其他事情(即仅在不同的域中显示文档、确保设置了 Content-Type 标头、清理文档等)。 但是,这些措施超出了 Spring Security 提供的范围。 同样重要的是要指出,在禁用内容探查时,您必须指定内容类型才能正常工作。 |
内容嗅探的问题在于,这允许恶意用户使用多语言(即作为多种内容类型有效的文件)来执行 XSS 攻击。 例如,某些站点可能允许用户向网站提交有效的 postscript 文档并查看该文档。 恶意用户可能会创建一个 postscript 文档,该文档也是一个有效的 JavaScript 文件,并使用它执行 XSS 攻击。
Spring Security 通过向 HTTP 响应添加以下标头来默认禁用内容嗅探:
X-Content-Type-Options: nosniff
在允许上传内容时,还应该做许多其他事情(即仅在不同的域中显示文档、确保设置了 Content-Type 标头、清理文档等)。 但是,这些措施超出了 Spring Security 提供的范围。 同样重要的是要指出,在禁用内容探查时,您必须指定内容类型才能正常工作。 |
HTTP 严格传输安全 (HSTS)
当您在银行的网站上输入时,您是输入 mybank.example.com 还是输入 mybank.example.com? 如果您省略 https 协议,则可能容易受到 Man in the Middle 攻击。 即使网站执行重定向以 mybank.example.com 恶意用户也可以拦截初始 HTTP 请求并操纵响应(例如重定向到 mibank.example.com 并窃取他们的凭据)。
许多用户省略了 https 协议,这就是创建 HTTP 严格传输安全 (HSTS) 的原因。 将 mybank.example.com 添加为 HSTS 主机后,浏览器可以提前知道对 mybank.example.com 的任何请求都应解释为 mybank.example.com。 这大大降低了 Man in the Middle 攻击发生的可能性。
根据 RFC6797,HSTS 标头仅注入到 HTTPS 响应中。 为了让浏览器确认标头,浏览器必须首先信任签署用于建立连接的 SSL 证书(而不仅仅是 SSL 证书)的 CA。 |
将站点标记为 HSTS 主机的一种方法是将主机预加载到浏览器中。
另一种方法是将标头添加到响应中。
例如,Spring Security 的默认行为是添加以下 Headers,该 Headers 指示浏览器将域视为一年的 HSTS 主机(一年大约有 31536000 秒):Strict-Transport-Security
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
optional 指令指示浏览器子域(例如 secure.mybank.example.com)也应被视为 HSTS 域。includeSubDomains
optional 指令指示浏览器应将 domain 作为 HSTS domain 预加载到浏览器中。
有关 HSTS 预加载的更多详细信息,请参阅 hstspreload.org。preload
根据 RFC6797,HSTS 标头仅注入到 HTTPS 响应中。 为了让浏览器确认标头,浏览器必须首先信任签署用于建立连接的 SSL 证书(而不仅仅是 SSL 证书)的 CA。 |
HTTP 公钥固定 (HPKP)
为了保持被动, Spring Security 仍然在 servlet 环境中提供对 HPKP 的支持,但是由于上面列出的原因,安全团队不再推荐 HPKP。 |
HTTP 公钥固定 (HPKP) 向 Web 客户端指定与特定 Web 服务器一起使用的公钥,以防止使用伪造证书的中间人 (MITM) 攻击。 如果使用得当,HPKP 可以增加额外的保护层,防止证书被盗用。 但是,由于 HPKP 的复杂性,许多专家不再推荐使用它,Chrome 甚至取消了对它的支持。
有关不再推荐 HPKP 的原因的更多详细信息,请阅读 HTTP Public Key Pinning Dead 了吗?和我要放弃 HPKP。
为了保持被动, Spring Security 仍然在 servlet 环境中提供对 HPKP 的支持,但是由于上面列出的原因,安全团队不再推荐 HPKP。 |
X 框架选项
允许将您的网站添加到框架中可能存在安全问题。 例如,使用聪明的 CSS 样式可能会欺骗用户点击他们不想要的内容。 例如,登录到其 SoundBank 的用户可能会单击一个按钮,该按钮可向其他用户授予访问权限。 这种攻击称为点击劫持。
处理点击劫持的另一种现代方法是使用内容安全策略 (CSP)。 |
有多种方法可以缓解点击劫持攻击。 例如,为了保护传统浏览器免受点击劫持攻击,您可以使用断帧代码。 虽然并不完美,但 breaking 代码是您可以为旧版浏览器做的最好的事情。
解决点击劫持的更现代方法是使用 X-Frame-Options 标头。 默认情况下,Spring Security 使用以下 Headers 在 iframe 中禁用渲染页面:
X-Frame-Options: DENY
处理点击劫持的另一种现代方法是使用内容安全策略 (CSP)。 |
X-XSS 保护
内容安全策略 (CSP)
内容安全策略 (CSP) 是 Web 应用程序可以用来缓解内容注入漏洞的一种机制,例如跨站点脚本 (XSS)。 CSP 是一种声明性策略,它为 Web 应用程序作者提供了一种工具,用于声明并最终通知客户端 (用户代理) Web 应用程序希望从中加载资源的源。
Content Security Policy 并非旨在解决所有内容注入漏洞。 相反,可以利用 CSP 来帮助减少内容注入攻击造成的危害。 作为第一道防线,Web 应用程序作者应验证其输入并对其输出进行编码。 |
Web 应用程序可以通过在响应中包含以下 HTTP 标头之一来使用 CSP:
-
Content-Security-Policy
-
Content-Security-Policy-Report-Only
这些标头中的每一个都用作向客户端提供安全策略的机制。 安全策略包含一组安全策略指令,每个指令负责声明特定资源表示的限制。
例如,Web 应用程序可以通过在响应中包含以下标头来声明它希望从特定的可信源加载脚本:
Content-Security-Policy: script-src https://trustedscripts.example.com
尝试从指令中声明的来源以外的其他来源加载脚本将被 user-agent 阻止。
此外,如果在安全策略中声明了 report-uri 指令,则 user-agent 会将冲突报告给声明的 URL。script-src
例如,如果 Web 应用程序违反了声明的安全策略,则以下响应标头将指示用户代理将违规报告发送到策略指令中指定的 URL。report-uri
Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/
违规报告是标准的 JSON 结构,可由 Web 应用程序自己的 API 或公开托管的 CSP 违规报告服务(如 report-uri.com/)捕获。
标头为 Web 应用程序作者和管理员提供了监视安全策略的功能,而不是强制实施它们。
在试验和/或为站点开发安全策略时,通常使用此标头。
当策略被视为有效时,可以改用 header 字段来强制实施该策略。Content-Security-Policy-Report-Only
Content-Security-Policy
给定以下响应标头,该策略声明可以从两个可能的来源之一加载脚本。
Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/
如果站点违反了此策略,则通过尝试从 evil.com 加载脚本,用户代理将向 report-uri 指令指定的声明 URL 发送违规报告,但仍允许加载违规资源。
将内容安全策略应用于 Web 应用程序通常是一项艰巨的任务。 以下资源可能会为您的网站制定有效的安全策略提供进一步的帮助。
Content Security Policy 并非旨在解决所有内容注入漏洞。 相反,可以利用 CSP 来帮助减少内容注入攻击造成的危害。 作为第一道防线,Web 应用程序作者应验证其输入并对其输出进行编码。 |
反向链接策略
反向链接策略是 Web 应用程序可以用来管理 referrer 字段的一种机制,其中包含最后一个 页面。
Spring Security 的方法是使用 Referrer Policy 标头,它提供不同的策略:
Referrer-Policy: same-origin
Referrer-Policy 响应标头指示浏览器让目标知道用户之前所在的来源。
跨域策略
Spring Security 为一些重要的跨域策略 Headers 提供支持。 这些标头是:
Cross-Origin-Opener-Policy
(COOP) 允许顶级文档断开其窗口与浏览上下文组中任何其他窗口之间的关联(例如,弹出窗口和打开器之间),从而阻止它们之间的任何直接 DOM 访问。
启用 (COEP) 可防止文档加载任何未明确授予文档加载权限的非同源资源。Cross-Origin-Embedder-Policy
的 (CORP) 标头允许您控制有权包含资源的源集。它是抵御 Spectre 等攻击的强大防御措施,因为它允许浏览器在给定响应进入攻击者的进程之前阻止它。Cross-Origin-Resource-Policy
自定义标头
请参阅相关部分,了解如何配置基于 servlet 的应用程序。 |
Spring Security 具有一些机制,可以方便地将更常见的安全 Headers 添加到您的应用程序中。 但是,它还提供了 hook 来启用添加自定义标头。
请参阅相关部分,了解如何配置基于 servlet 的应用程序。 |