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