配置响应头 提高网页安全性 让跑分达到A+!

AI 摘要
配置安全响应头可以有效防止客户端被入侵。文章介绍了几个常用的安全响应头,并提供了相关配置和使用示例。其中包括HTTP严格传输安全、X-Frame-Options、X-Content-Type-Options、X-XSS-Protection、Permissions Policy和内容安全策略(CSP)。通过正确配置这些响应头,可以增强网站的安全性并防止多种攻击手段的利用。最后,通过相关网站可以对响应头进行检测评分,以确保安全性。
警告
本文最后更新于 2023-02-18,文中内容可能已过时。

配置安全响应头可以有效地防止客户端被入侵

Security Headers

Mozilla Observatory

http是明文传输,完全没有任何加密,这意味着任何人都可以从传输数据中获取浏览器到服务器间的所有内容。所以https使用的TLS加密十分值得推崇。然而,除非特殊指定https,否则每次用域名访问时,都会首先向服务器发送http请求,再由服务器发送重定向到浏览器,接着浏览器才会升级为https。

HSTS就是解决这一问题的方法。

当浏览器接收到https站点发送的Strict-Transport-Security头,浏览器便会遵守参数规定的时间执行https访问,当浏览器再次访问该站且未过规定时间时,浏览器便不会再发出HTTP请求,而是直接转用https连接,这防止了SSL剥离等针对尚未升级为https连接的攻击。

e.g.

1
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

该头具有三个参数:max-age=63072000includeSubDomainspreload

  • max-age=表明保持HTTPS连接的时间,后跟秒数,如max-age=31536000含义为一年内仅使用https连接
  • includeSubDomains表示该域名下所有子域名皆使用https访问

HSTS很好,但最原始最开始的那次连接始终是http,如果有个图谋已久的脚本小子渗透专家始终盯着一举一动,那该怎么办?

preload参数便是用于解决这一问题。浏览器会从ChromeFirefox预加载列表里获取应直接使用https连接的站点。该列表可在HSTSpreload主动提交

该列表可用chrome://net-internals/#hsts在本地Chrome上查询和删改

建议使用CSP参数代替
Content-Security-Policy 响应头有一个 frame-ancestors 参数可以完美替代X-Frame-Options响应头且具有更多特性

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame><iframe><embed> 或者 <object> 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面,从而避免点击劫持攻击。

e.g.

1
X-Frame-Options: SAMEORIGIN

该头仅有两个参数,SAMEORIGINDENY

  • SAMEORIGIN表明该页面只允许同源域名展示frame
  • DENY表明完全不允许任何frame

该头的主要作用是要求客户端严格遵守响应头Content-Type中规定的文件MIME类型。否则浏览器会使用MIME-sniffing猜测返回文件的内容并执行

如果该头没有被配置,那么隐藏在图片或其他媒体文件中的javascriptcss就可能被攻击者利用来渗透系统

e.g.

1
X-Content-Type-Options: nosniff

该头仅有nosniff一个参数来提示客户端

  • nosniff将阻止请求与MIME类型不符的情况发生。
浏览器兼容性
目前仅Safari浏览器仍支持 该头可被完全配置的CSP头取代

该头的作用和其名字一样一目了然,基于浏览器防护XSS攻击,因此不属于任何规范和草案中。

e.g.

1
X-XSS-Protection: 1; mode=block

该头有四个参数~引用自Mdn~

  • 0 禁止 XSS 过滤。

  • 1 表明启用 XSS 过滤。如果检测到跨站脚本攻击,浏览器将清除页面(删除不安全的部分)。

  • 1;mode=block 表明启用 XSS 过滤。如果检测到攻击,浏览器将不会清除页面,而是阻止页面加载。

  • 1; report=<reporting-URI> 仅chrome 4-77版本支持。该参数表明启用 XSS 过滤。如果检测到跨站脚本攻击,浏览器将清除页面并使用 CSP report-uri 的功能发送违规报告。

该头可用来控制页面可访问的浏览器功能,这可以让站点先一步为自身划定可能使用权限范围

e.g.

1
Permissions-Policy: geolocation=()

该头具有很多个参数,参数语法为<directive>=<allowlist>,前半部分表示权限,后半部分表示允许的白名单。

权限列表
  1. document-domain

是否允许设置document.domain

  1. encrypted-media

是否允许使用加密媒体扩展API (EME)

  1. execution-while-not-rendered

任务在未呈现时是否应在框架中执行

  1. execution-while-out-of-viewport

任务在可见视口之外时是否应在帧中执行

  1. fullscreen

是否允许使用Element.requestFullscreen()

  1. gamepad

是否允许使用Gamepad API

  1. geolocation

是否允许使用Geolocation API

  1. gyroscope

是否允许通过界面收集有关设备方向的信息

  1. hid

是否允许使用WebHID API连接到不常见或奇异的人机界面设备,例如备用键盘或游戏手柄。

  1. idle-detection

是否允许使用空闲检测 API来检测用户何时与他们的设备交互

  1. local-fonts

是否允许收集有关用户本地安装字体的数据

  1. magnetometer

是否允许通过界面收集有关设备方向的信息

  1. microphone

是否允许使用音频输入设备

  1. midi

是否允许使用Web MIDI API

  1. payment

是否允许使用Payment Request API

  1. picture-in-picture

是否允许通过相应的API以画中画模式播放视频。

  1. publickey-credentials-get

是否允许使用Web Authentication API来检索已存储的公钥凭据

  1. screen-wake-lock

是否允许使用屏幕唤醒锁定 API来指示设备不应关闭或调暗屏幕

  1. serial

是否允许使用Web Serial API与串行设备通信,通过串行端口直接连接,或通过 USB 或蓝牙设备模拟串行端口

  1. speaker-selection

是否允许使用音频输出设备 API来列出和选择扬声器

  1. usb

是否允许使用Web USB API

  1. web-share

是否允许使用Navigator.share(), Web Share API 将文本、链接、图像和其他内容共享到用户选择的任意目的地,例如移动应用程序

  1. xr-spatial-tracking

是否允许使用WebXR 设备 API与 WebXR 会话进行交互

  1. accelerometer

是否允许收集有关设备加速度信息

  1. ambient-light-sensor

是否允许收集有关设备周围环境中的亮度信息

  1. autoplay

是否允许自动播放通过HTMLMediaElement请求的媒体。

  1. battery

是否允许使用电池状态 API

  1. camera

是否允许使用视频输入设备

  1. display-capture

是否允许使用该getDisplayMedia()方法捕获屏幕内容

白名单则具有三种值:

  • *: 允许当前页面及所有呈现在页面中的内容使用该功能
  • (): 不允许使用该功能
  • (self "https://example.org"): 该种参数允许使用通配符,每个允许站点间以空格 隔开,self表示本页面

该头定义了哪些内容允许被该页面使用并执行。

CSP配置很复杂,详情可以看看阮一峰老师的博客 Content Security Policy 入门教程

我可不想重造轮子绝不是因为懒得写

配置好CSP头后也可以使用Google提供的CSP Evaluator检测一下自己的CSP策略是否强力

最上面的两个检测网址均可对响应头进行检测,Securityheaders的检测没有Mozilla家的那么严苛,一般来讲检测如果能达到A+就表明安全性响应头配置得差不多了。

Security Headers 检测 A+

相关内容