0


HTTP 请求头安全方案

请求头安全性

1. X-Content-Type-Options(内容嗅探)

过去,浏览器(包括 Internet Explorer)会尝试使用内容嗅探来猜测请求的内容类型。 这允许浏览器通过猜测未指定内容类型的资源上的内容类型来改善用户体验。 例如,如果浏览器遇到未指定内容类型的 JavaScript 文件,它将能够猜测内容类型,然后运行它。
内容嗅探的问题在于,这允许恶意用户使用多语言(即,作为多种内容类型有效的文件)来执行 XSS 攻击。 例如,某些网站可能允许用户向网站提交有效的 postscript 文档并查看它。 恶意用户可能会创建一个 postscript 文档,该文档也是一个有效的 JavaScript 文件,并对其执行 XSS 攻击。

# 关闭内容嗅探X-Content-Type-Options: nosniff
2. Strict-Transport-Security(HSTS)

目前HTTPS网站存在下面弱点:

  1. 当用户在浏览器中输入www.baidu.com,浏览器默认会将访问http://www.baidu.com,而不是https://www.baidu.com。将由服务器将http请求重定向到https,但这将消耗服务器的性能资源。
  2. 当HTTPS网站中使用的是自签名证书(或者不在浏览器的证书信任列表中),浏览器会发出网站存在安全风险警告,但不会中止HTTPS网站访问,并询问用户是否信任该证书,继续访HTTPS网站。

安全风险由用户决定。我们fiddler抓取HTTPS网站时,网站的证书已经被fifdler截获,而此浏览器中显示的证书,为fiddler创建的证书,所以也会报警告(也叫中间人攻击)。
通过设置HSTS可以消除上面的威胁。那HSTS是如何做到的呢?需要服务器和客户端(浏览器)如何配合呢?

参数意思:在172800秒内,浏览器只要再向百度或其子域名发送HTTP请求时,由浏览器自动转成HTTPS来发起连接。这样可以减少服务器重定向的处理和被中间人截获请求的风险。

# 开启HSTS(允许子域)strict-transport-security: max-age=15552000; includeSubDomains
3. X-Frame-Options(点击劫持)

让您的网站添加到框架中可能是一个安全问题。 例如,通过使用巧妙的CSS样式,用户可能会被诱骗点击他们不想要的东西。 例如,登录到其银行的用户可能会单击向其他用户授予访问权限的按钮。 这种攻击被称为点击劫持。

  1. DENY 表示文件無論如何都不能被嵌入到 frame 中,即使是自家網站也不行。
  2. SAMEORIGIN 唯有當符合同源政策下,才能被嵌入到 frame 中。
  3. ALLOW-FROM uri 唯有列表許可的 URI 才能嵌入到 frame 中。

解决点击劫持问题的现在解决方法是使用 X-Frame-Options 标头。 默认情况下:

# 無論如何都不能被嵌入到 frame X-Frame-Options: DENY
4. X-XSS-Protection(xss过滤)

某些浏览器内置支持过滤掉反射的 XSS 攻击。 该过滤器已在主要浏览器中弃用,当前的 OWASP 建议是将标头显式设置为 0。
X-XSS-Protection有四种语法:

  1. X-XSS-Protection : 0 表示禁用 XSS 过滤这个功能
  2. X-XSS-Protection : 1 表示启用 XSS 过滤
  3. X-XSS-Protection : 1; mode=block 如果检测到攻击,浏览器不会像上面的选项一样将不安全的部分删除,而是直接阻止整个页面的加载
  4. X-XSS-Protection : 1; report= 如果检测到跨站脚本攻击,浏览器会清除在页面上检测到的不安全的部分,并使用report-uri的功能 POST 一个 XSS 警报。这个功能只有在 Chrome 中有效果,在 IE 中无效。
# 发现xss攻击停止加载页面x-xss-protection: 1; mode=block
5. Content-Security-Policy(CSP内容安全策略)

内容安全策略 (CSP) 是 Web 应用程序可用于缓解内容注入漏洞(如跨站点脚本 (XSS))的一种机制。 CSP 是一种声明性策略,它为 Web 应用程序作者提供了一种工具,用于声明并最终通知客户端(用户代理)有关 Web 应用程序期望从中加载资源的源。

内容安全策略并非旨在解决所有内容注入漏洞。 相反,您可以使用 CSP 来帮助减少内容注入攻击造成的危害。 作为第一道防线,Web 应用程序作者应验证其输入并对其输出进行编码。

Web 应用程序可以通过在响应中包含以下 HTTP 标头之一来使用 CSP:
script-src

# 不检查该域名下的脚本资源Content-Security-Policy: script-src https://trustedscripts.example.com

report-uri

# report-uri: 发现异常加载资源后调用report-uri接口提供异常调用数据(json格式)Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/

Content-Security-Policy-Report-Only

# 如果站点违反此策略,则会将违规报告发送到指令指定的声明 URL,但仍允许加载违规资源Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/
6. Referrer-Policy(来历政策)

引荐来源网址策略是 Web 应用程序可用于管理来源网址字段的一种机制,其中包含最后一个用户所在的页面。
参考文档
协议描述no-referrer最简单的策略是no-referrer(无引用者),它指定不会将来源信息与来自任何源的特定信息请求客户端。referrer 将是完全省略。no-referrer-when-downgrade会发送完整的网址以及来自受TLS保护的环境设置的请求配置 ,以及来自不受 TLS 保护的客户端对任何源的请求。另一方面,从受 TLS 保护的客户端到非潜在可信 URL的请求将不包含 referrer 信息。HTTP 请求头Referersame-origin指定 完整的 URL(剥离以用作referrer来源网址)将作为 从特定客户端发出同源请求时的referrer信息。另一方面,跨源请求将不包含 referrer信息。HTTP 请求头不会带有referrerorigin指定仅将请求客户端源的 ASCII 序列化作为引用信息发送,在从特定客户端发出同源请求和跨源请求时。strict-origin从受 TLS 保护的环境设置对象到可能可信的 URL,以及从不受 TLS 保护的环境设置对象到 任何来源,会发送。从受 TLS 保护的请求客户端到非潜在可信 URL 的请求将不包含 referrer 人信息。HTTP 请求头referrerorigin-when-cross-origin指定完整的 URL(剥离以用作引荐来源网址)将作为 从特定请求客户端发出同源请求时的引荐来源信息,并且从特定客户端发出跨源请求时,仅将请求客户端源的 ASCII 序列化作为引荐来源信息发送 。strict-origin-when-cross-origin指定 完整的 URL(剥离以用作引荐来源网址)将作为 从特定请求客户端发出同源请求时的引用信息,以及发出跨源请求时仅请求客户端源的 ASCII 序列化:从受 TLS 保护的环境设置对象到可能可信的 URL,以及从不受 TLS 保护的环境设置对象到 任何来源。另一方面,从受 TLS 保护的客户端到非潜在可信 URL的请求将不包含 推荐人信息unsafe-url指定将发送一个完整的网址(剥离以用作引荐来源网址)与 跨源请求和同源请求均来自 特定客户端。

# 如果站点违反此策略,则会将违规报告发送到指令指定的声明 URL,但仍允许加载违规资源Referrer-Policy: same-origin
7. Feature-Policy(功能策略)

功能策略是一种机制,允许 Web 开发人员有选择地启用、禁用和修改浏览器中某些 API 和 Web 功能的行为。

# 定位功能限制Feature-Policy: geolocation 'self'

借助功能策略,开发人员可以选择加入一组“策略”,以便浏览器对整个网站中使用的特定功能强制执行。 这些策略限制站点可以访问哪些 API,或修改浏览器对某些功能的默认行为。

8. Permissions-Policy(权限策略)

权限策略是一种机制,允许 Web 开发人员有选择地启用、禁用和修改浏览器中某些 API 和 Web 功能的行为。

# 定位功能限制Permissions-Policy: geolocation=(self)

借助权限策略,开发人员可以选择加入一组“策略”,以便浏览器对整个网站中使用的特定功能强制执行。 这些策略限制站点可以访问哪些 API,或修改浏览器对某些功能的默认行为。

9. Clear-Site-Data(清除站点数据)

清除站点数据是一种机制,当 HTTP 响应包含以下标头时,可以通过该机制删除任何浏览器端数据(cookie、本地存储等):

# 清空数据Clear-Site-Data:"cache","cookies","storage","executionContexts"

这是一个很好的清理操作,可以在注销时执行。

标签: http 安全 https

本文转载自: https://blog.csdn.net/qq_35040959/article/details/128664777
版权归原作者 不学会Ⅳ 所有, 如有侵权,请联系我们删除。

“HTTP 请求头安全方案”的评论:

还没有评论