HSTS详解

来源:http://www.sh-fengwen.com 作者: 营养排行 人气:133 发布时间:2019-11-07
摘要:你所不知道的 HSTS 2015/10/24 · HTML5 ·HSTS 原文出处:李靖(@Barret李靖)    很多人听说过也看到过 301、302,但是几乎从来没有看到过 303 和 307的状态码。今天在淘宝首页看到了 307 状态

你所不知道的 HSTS

2015/10/24 · HTML5 · HSTS

原文出处: 李靖(@Barret李靖)   

很多人听说过也看到过 301、302,但是几乎从来没有看到过 303 和 307 的状态码。今天在淘宝首页看到了 307 状态码,于是摸索了一把。

文/马伟

中间人劫持

起因是这样,https 使用的是 443 端口进行数据传输,而浏览器的默认端口是

  1. 劫持者首先劫持用户的 80 端口,当用户向目标页发起请求时,劫持者模拟正常的 https 请求向源服务器获取数据,然后通过 80 端口返回给用户,大概可以看下下面两张图:

图片 1

用户一般不会在地址栏输入   ,而是习惯性输入 taobao.com  ,此时浏览器走的是 http,请求到达服务器之后,服务器告诉浏览器 302 跳转

Location:

1
Location: https://www.taobao.com

然后浏览器重新请求,通过 HTTPS 方式,443 端口通讯。而正因为用户不是直接输入 https:// 链接,劫持者利用这一点:

图片 2

只要能够劫持你的网络,比如路由劫持、DNS劫持,就可以作为中间人注入代码、替换广告。。。(上了 https 也拗不过电信,真是日了够了)

这种劫持出现在两种情况下:

  • 用户没有通过准确的方式访问页面,除非输入 https:// ,否则浏览器默认以 http 方式访问
  • HTTPS 页面的链接中包含 http,这个 http 页面可能被劫持

缘起:启用HTTPS也不够安全

有不少网站只通过HTTPS对外提供服务,但用户在访问某个网站的时候,在浏览器里却往往直接输入网站域名(例如www.example.com),而不是完整的URL(例如https://www.example.com),不过浏览器依然能正确的使用HTTPS发起请求。这背后多亏了服务器和浏览器的协作,如下图所示。

图1:服务器和浏览器在背后帮用户做了很多工作

简单来讲就是,浏览器向网站发起一次HTTP请求,在得到一个重定向响应后,发起一次HTTPS请求并得到最终的响应内容。所有的这一切对用户而言是完全透明的,所以在用户看来,在浏览器里直接输入域名却依然可以用HTTPS协议和网站进行安全的通信,是个不错的用户体验。

一切看上去都是那么的完美,但其实不然,由于在建立起HTTPS连接之前存在一次明文的HTTP请求和重定向(上图中的第1、2步),使得攻击者可以以中间人的方式劫持这次请求,从而进行后续的攻击,例如窃听数据、篡改请求和响应、跳转到钓鱼网站等。

以劫持请求并跳转到钓鱼网站为例,其大致做法如下图所示:

图2:劫持HTTP请求,阻止HTTPS连接,并进行钓鱼攻击

  • 第1步:浏览器发起一次明文HTTP请求,但实际上会被攻击者拦截下来
  • 第2步:攻击者作为代理,把当前请求转发给钓鱼网站
  • 第3步:钓鱼网站返回假冒的网页内容
  • 第4步:攻击者把假冒的网页内容返回给浏览器

这个攻击的精妙之处在于,攻击者直接劫持了HTTP请求,并返回了内容给浏览器,根本不给浏览器同真实网站建立HTTPS连接的机会,因此浏览器会误以为真实网站通过HTTP对外提供服务,自然也就不会向用户报告当前的连接不安全。于是乎攻击者几乎可以神不知鬼不觉的对请求和响应动手脚。

启用 HSTS

HSTS,HTTP Strict Transport Security,简单说就是强制客户端使用 HTTPS 访问页面。其原理就是:

  • 在服务器响应头中添加  Strict-Transport-Security ,可以设置  max-age
  • 用户访问时,服务器种下这个头
  • 下次如果使用 http 访问,只要 max-age 未过期,客户端会进行内部跳转,可以看到 307 Redirect Internel 的响应码
  • 变成 https 访问源服务器

这个过程有效避免了中间人对 80 端口的劫持。但是这里存在一个问题:如果用户在劫持状态,并且没有访问过源服务器,那么源服务器是没有办法给客户端种下 Strict-Transport-Security  响应头的(都被中间人挡下来了)。

启用 HSTS 不仅仅可以有效防范中间人攻击,同时也为浏览器节省来一次 302/301 的跳转请求,收益还是很高的。我们的很多页面,难以避免地出现 http 的链接,比如 help 中的链接、运营填写的链接等,这些链接的请求都会经历一次 302,对于用户也是一样,收藏夹中的链接保存的可能也是 http 的。

解决之道:使用HSTS

既然建立HTTPS连接之前的这一次HTTP明文请求和重定向有可能被攻击者劫持,那么解决这一问题的思路自然就变成了如何避免出现这样的HTTP请求。我们期望的浏览器行为是,当用户让浏览器发起HTTP请求的时候,浏览器将其转换为HTTPS请求,直接略过上述的HTTP请求和重定向,从而使得中间人攻击失效,以规避风险。其大致流程如下:

图3:略过HTTP请求和重定向,直接发送HTTPS请求

  • 第1步:用户在浏览器地址栏里输入网站域名,浏览器得知该域名应该使用HTTPS进行通信
  • 第2步:浏览器直接向网站发起HTTPS请求
  • 第3步:网站返回相应的内容

那么问题来了,浏览器是如何做到这一点的呢?它怎么知道哪个网站应该发HTTPS请求,哪个网站应该用HTTP请求呢?此时就该HSTS闪亮登场了。

307 状态码

在 GET、HEAD 这些幂等的请求方式上,302、303、307 没啥区别,而对于 POST 就不同了,大部分浏览器 都会302 会将 POST 请求转为 GET,而 303 是规范强制规定将 POST 转为 GET 请求,请求地址为 header 头中的 Location,307 则不一样,规范要求浏览器继续向 Location 的地址 POST 内容。

而在 HSTS 中,307 可以被缓存,缓存时间根据 max-age 而定,一般建议缓存 1 年甚至更长。

HSTS

HSTS的全称是HTTP Strict-Transport-Security,它是一个Web安全策略机制(web security policy mechanism)。

HSTS最早于2015年被纳入到ThoughtWorks技术雷达,并且在2016年的最新一期技术雷达里,它直接从“评估(Trial)”阶段进入到了“采用(Adopt)“阶段,这意味着ThoughtWorks强烈主张业界积极采用这项安全防御措施,并且ThoughtWorks已经将其应用于自己的项目。

HSTS最为核心的是一个HTTP响应头(HTTP Response Header)。正是它可以让浏览器得知,在接下来的一段时间内,当前域名只能通过HTTPS进行访问,并且在浏览器发现当前连接不安全的情况下,强制拒绝用户的后续访问要求。

HSTS Header的语法如下:

Strict-Transport-Security: <max-age=>[; includeSubDomains][; preload]

其中:

  • max-age是必选参数,是一个以秒为单位的数值,它代表着HSTS Header的过期时间,通常设置为1年,即31536000秒。
  • includeSubDomains是可选参数,如果包含它,则意味着当前域名及其子域名均开启HSTS保护。
  • preload是可选参数,只有当你申请将自己的域名加入到浏览器内置列表的时候才需要使用到它。关于浏览器内置列表,下文有详细介绍。

HSTS 存在的坑

  • 纯 IP 的请求,HSTS 没法处理,比如 http://2.2.2.2 , 即便响应头中设置了 STS,浏览器也不会理会(未测试)
  • HSTS 只能在 80 和 443 端口之间切换,如果服务是 8080 端口,即便设置了 STS,也无效(未测试)
  • 如果浏览器证书错误,一般情况会提醒存在安全风险,然是依然给一个链接进入目标页,而 HSTS 则没有目标页入口,所以一旦证书配置错误,就是很大的故障了
  • 如果服务器的 HTTPS 没有配置好就开启了 STS 的响应头,并且还设置了很长的过期时间,那么在你服务器 HTTPS 配置好之前,用户都是没办法连接到你的服务器的,除非 max-age 过期了。
  • HSTS 能让你的网站在 ssllab 上到 A+(这不是坑)

让浏览器直接发起HTTPS请求

只要在服务器返回给浏览器的响应头中,增加Strict-Transport-Security这个HTTP Header(下文简称HSTS Header),例如:

Strict-Transport-Security: max-age=31536000; includeSubDomains

就可以告诉浏览器,在接下来的31536000秒(1年)内,对于当前域名及其子域名的后续通信应该强制性的只使用HTTPS,直到超过有效期为止。

完整的流程如下图所示:

图4:完整的HSTS流程

只要是在有效期内,浏览器都将直接强制性的发起HTTPS请求,但是问题又来了,有效期过了怎么办?其实不用为此过多担心,因为HSTS Header存在于每个响应中,随着用户和网站的交互,这个有效时间时刻都在刷新,再加上有效期通常都被设置成了1年,所以只要用户的前后两次请求之间的时间间隔没有超过1年,则基本上不会出现安全风险。更何况,就算超过了有效期,只要用户和网站再进行一次新的交互,用户的浏览器又将开启有效期为1年的HSTS保护。

本文由美高梅游戏平台网站发布于 营养排行,转载请注明出处:HSTS详解

关键词:

最火资讯