0


如何在Nginx中配置HTTP安全响应头

关于在Nginx中配置HTTP安全响应头

最近在实际开发过程中,需要对项目的http响应头做一些配置,以防止各类XSS攻击、点击劫持等。这些HTTP响应头在我们部署 Nginx 的时候经常会被忽略掉,个人感觉这是一个比较严重的“疏忽”,加上还是很有必要的,现把用到的一些配置记录一下。

1.Strict-Transport-Security (HSTS)

Strict-Transport-Security (通常简称为 HSTS)是一个安全功能,它告诉浏览器只能通过HTTPS访问当前资源,而不是 HTTP。
语法:

1.strict-transport-security: max-age=<expire-time>
2.strict-transport-security: max-age=<expire-time>; includeSubDomains
3.strict-transport-security: max-age=<expire-time>; includeSubDomains; preload

示例:

#add_header  Strict-Transport-Security  "max-age=31536000; includeSubdomains; preload";

释义:

max-age=<expire-time> 设置在浏览器收到这个请求后的 秒的时间内凡是访问这个域名下的请求都使用 HTTPS 请求。
includeSubDomains 可选,如果这个可选的参数被指定,那么说明此规则也适用于该网站的所有子域名。
preload 可选,加入预加载列表
2.Content-Security-Policy(CSP)
CSP

是一个计算机的安全标志,主要用来防止

XSS

、点击劫持、

SQL

注入等攻击;

CSP

通过定义运行加载脚本的位置和内容防止恶意代码的加载。

作用:用于定义页面可以加载哪些资源,减少和上报 XSS 的攻击,防止数据包嗅探攻击。

使用方法:

#add_header Content-Security-Policy  "default-src 'self'"

元素也可以用于配置 CSP:
在这里插入图片描述
指令值可以由下面内容组成:
在这里插入图片描述

3.Referrer-Policy

用来监管哪些访问来源信息——会在

Referer

中发送——应该被包含在生成的请求当中。(注意

Referer

实际上是单词 “

referrer

” 的错误拼写。

Referrer-Policy

这个首部并没有延续这个错误拼写。)

作用:增加隐私保护。
语法:

1.Referrer-Policy:no-referrer2.Referrer-Policy:no-referrer-when-downgrade3.Referrer-Policy:origin4.Referrer-Policy:origin-when-cross-origin5.Referrer-Policy:same-origin6.Referrer-Policy:strict-origin7.Referrer-Policy:strict-origin-when-cross-origin8.Referrer-Policy:unsafe-url

可配置值:

no-referrer

:不允许被记录。

origin

:只记录

origin

,即域名。

strict-origin

:只有在

HTTPS -> HTTPS

之间才会被记录下来。

strict-origin-when-cross-origin

:同源请求会发送完整的

URL

HTTPS->HTTPS

,发送源;降级下不发送此首部。

no-referrer-when-downgrade(default)

:同

strict-origin

origin-when-cross-origin

:对于同源的请求,会发送完整的

URL

作为引用地址,但是对于非同源请求仅发送文件的源。

same-origin

:对于同源请求会发送完整

URL

,非同源请求则不发送

referer

unsafe-url

:无论是同源请求还是非同源请求,都发送完整的

URL

(移除参数信息之后)作为引用地址。(可能会泄漏敏感信息)。

使用方法:

#add_header  Referrer-Policy  "no-referrer-when-downgrade";#大多数浏览器的默认值
4.X-Frame-Option

是否允许一个页面可在 <

frame

、<

iframe

、<

embed

或者 <

object

中展现的标记。(备注:<> 之间没有空格,这里写入 HTML 中会导致文章内容变形)

  • frame 标签:框架标签,放置一个 HTML 文档(页面)
  • iframe 标签:内联框架标签,在一个 HTML 页面中显示(插入)另一个 HTML 页面
  • embed 标签:音频元素标签,插入一个音频元素
  • object 标签:定义外部内容的容器标签

作用:减少/避免点击劫持 (clickjacking) 的攻击。
语法:

  • X-Frame-Options: DENY
  • X-Frame-Options: SAMEORIGIN
  • X-Frame-Options: ALLOW-FROM https://example.com/

响应头支持三种配置:

  • DENY:表示该页面不允许在 frame 中展示,即便是在相同域名的页面中嵌套也不允许。
  • SAMEORIGIN:表示该页面可以在相同域名页面的 frame 中展示。
  • ALLOW-FROM uri:表示该页面可以在指定来源的 frame 中展示。

使用方法:

#add_header X-Frame-Options    "SAMEORIGIN";
5.X-Content-Type-Options
X-Content-Type-Options

HTTP 消息头相当于一个提示标志,被服务器用来提示客户端一定要遵循在

Content-Type

首部中对 MIME 类型 的设定,而不能对其进行修改。这就禁用了客户端的

MIME

类型嗅探行为。

作用:禁用浏览器的

Content-Type

猜测行为。

背景:浏览器通常会根据响应头

Content-Type

字段来分辨资源类型。有些资源的

Content-Type

是错的或者未定义。这时,浏览器会启用

MIME-sniffing

来猜测该资源的类型,解析内容并执行。利用这个特性,攻击者可以让原本应该解析为图片的请求被解析为 JavaScript。

使用方法:

# add_header X-Content-Type-Options  "nosniff";
6.Permissions-Policy(Feature-Policy)
Permissions Policy

由之前的

Feature Policy

更名而来,用法也做了相应的变动。

Feature Policy

是一个新的 http 响应头属性,允许一个站点开启或者禁止一些浏览器属性和 API,来更好的确保站点的安全性和隐私性。有点类似内容安全策略,但是它控制的是浏览器的特征而不是安全行为。

语法:

Feature-Policy:<feature><allowlist>

允许开启或者禁止的浏览器属性和API列表

许开启或者禁止的浏览器属性和API列表还没有完全敲定,具体可参考Features list

示例

禁用摄像头和定位 API,则可以在返回的 response 中传递以下定义 feature policy 的 HTTP 的头部信息:
add-header: “Feature-Policy: camera ‘none’; geolocation ‘none’”

# add_header Feature-Policy  "camera 'none'; geolocation 'none'f";

语法变更:

原有

Feature-Policy

示例:

"Feature-Policy":"camera 'none'; microphone 'none'"
Permissions-Policy

语法变更为:

"Permissions-Policy":"camera=(),microphonee=()"

使用方法:

#反谷歌追踪FLoC
#add_header Permissions-Policy  "interest-cohort=()"

上面只列举了我所用到的HTTP安全标头,实际应用中还有其他一些HTTP安全表头配置,感兴趣的可以参考这篇文章 https://blog.csdn.net/netgc/article/details/110928141

标签: nginx http 安全

本文转载自: https://blog.csdn.net/jie1134514406/article/details/124668625
版权归原作者 等风起也等你乀 所有, 如有侵权,请联系我们删除。

“如何在Nginx中配置HTTP安全响应头”的评论:

还没有评论