此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 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: 0
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 响应添加以下 Headers 来禁用内容嗅探:
X-Content-Type-Options: nosniff
在允许上传内容时,还应该做许多其他事情(例如仅在不同的域中显示文档、确保设置了 Content-Type 标头、清理文档等)。 但是,这些措施超出了 Spring Security 提供的范围。 还需要指出的是,在禁用内容探查时,必须指定内容类型才能正常工作。 |
HTTP 严格传输安全 (HSTS)
当您在银行的网站上输入时,您是输入还是输入 ?
如果省略该协议,则可能容易受到中间人攻击。
即使网站执行重定向到 ,恶意用户也可以拦截初始 HTTP 请求并操纵响应(例如,重定向到并窃取其凭据)。mybank.example.com
https://mybank.example.com
https
https://mybank.example.com
https://mibank.example.com
许多用户省略了协议,这就是创建 HTTP 严格传输安全 (HSTS) 的原因。
添加为 HSTS 主机后,浏览器可以提前知道对 mybank.example.com 的任何请求都应解释为 。
这大大降低了发生中间人攻击的可能性。https
mybank.example.com
https://mybank.example.com
根据 RFC6797,HSTS 标头仅注入到 HTTPS 响应中。 要使浏览器确认标头,浏览器必须首先信任签署用于建立连接的 SSL 证书(而不仅仅是 SSL 证书)的 CA。 |
将站点标记为 HSTS 主机的一种方法是将主机预加载到浏览器中。
另一种方法是将标头添加到响应中。
例如,Spring Security 的默认行为是添加以下 Headers,它指示浏览器将域视为一年的 HSTS 主机(非闰年有 31536000 秒):Strict-Transport-Security
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
optional 指令指示浏览器子域(例如 )也应被视为 HSTS 域。includeSubDomains
secure.mybank.example.com
optional 指令指示浏览器应将域作为 HSTS 域预加载到浏览器中。
有关 HSTS 预加载的更多详细信息,请参阅 hstspreload.org。preload
根据 RFC6797,HSTS 标头仅注入到 HTTPS 响应中。 要使浏览器确认标头,浏览器必须首先信任签署用于建立连接的 SSL 证书(而不仅仅是 SSL 证书)的 CA。 |
HTTP 公钥固定 (HPKP)
为了保持被动,Spring Security 仍然在 servlet 环境中提供对 HPKP 的支持。 但是,由于前面列出的原因,Spring Security 团队不再推荐 HPKP。 |
HTTP 公钥固定 (HPKP) 向 Web 客户端指定与特定 Web 服务器一起使用的公钥,以防止使用伪造证书的中间人 (MITM) 攻击。 如果使用得当,HPKP 可以增加额外的保护层,防止证书被盗用。 但是,由于 HPKP 的复杂性,许多专家不再推荐使用它,Chrome 甚至已经取消了对它的支持。
有关不再推荐 HPKP 的原因的更多详细信息,请阅读 HTTP 公钥固定已失效吗?和我要放弃 HPKP。
为了保持被动,Spring Security 仍然在 servlet 环境中提供对 HPKP 的支持。 但是,由于前面列出的原因,Spring Security 团队不再推荐 HPKP。 |
X 框架选项
将您的网站添加到框架中可能是一个安全问题。 例如,通过使用巧妙的 CSS 样式,用户可能会被诱骗点击他们不想要的内容。 例如,登录到其 SoundBank 的用户可能会单击一个按钮,该按钮可向其他用户授予访问权限。 这种攻击称为点击劫持。
处理点击劫持的另一种现代方法是使用内容安全策略 (CSP)。 |
有多种方法可以缓解点击劫持攻击。 例如,为了保护传统浏览器免受点击劫持攻击,您可以使用断帧代码。 虽然并不完美,但 breaking 代码是您可以为旧版浏览器做的最好的事情。
解决点击劫持的更现代方法是使用 X-Frame-Options 标头。 默认情况下,Spring Security 通过与以下 Headers 一起使用来禁用 iframe 中的渲染页面:
X-Frame-Options: DENY
处理点击劫持的另一种现代方法是使用内容安全策略 (CSP)。 |
X-XSS 保护
某些浏览器内置了对过滤反射型 XSS 攻击的支持。 该过滤器在主要浏览器中已被弃用,当前的 OWASP 建议是将标头显式设置为 0。
默认情况下,Spring Security 使用以下 Headers 阻止内容:
X-XSS-Protection: 0
内容安全策略 (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.io/)捕获。
标头为 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/
如果站点违反了此策略,则通过尝试从 加载脚本,用户代理会将违规报告发送到指令指定的声明的 URL,但仍允许违规资源加载。evil.example.com
report-uri
将内容安全策略应用于 Web 应用程序通常是一项艰巨的任务。 以下资源可以为您的网站制定有效的安全策略提供进一步的帮助:
Content Security Policy 并非旨在解决所有内容注入漏洞。 相反,您可以使用 CSP 来帮助减少内容注入攻击造成的危害。 作为第一道防线,Web 应用程序作者应验证其输入并对其输出进行编码。 |
反向链接策略
反向链接策略是 Web 应用程序可用于管理 反向链接 字段的一种机制,该字段包含最后一个 页面。
Spring Security 的方法是使用 Referrer Policy 标头,它提供不同的策略:
Referrer-Policy: same-origin
Referrer-Policy 响应标头指示浏览器让目标知道用户之前所在的来源。
自定义标头
请参阅相关部分,了解如何配置基于 servlet 的应用程序。 |
Spring Security 具有一些机制,可以方便地将更常见的安全 Headers 添加到您的应用程序中。 但是,它还提供了 hook 来启用添加自定义标头。
请参阅相关部分,了解如何配置基于 servlet 的应用程序。 |