的一部分经验分享,伏乞警报

时间:2019-09-27 08:26来源:2020欧洲杯冠军竞猜官方网站
让浏览器不再显示 https 页面中的 http 请求警报 2015/08/26 · 基础技术 ·HTTPS,浏览器 原文出处:李靖(@Barret李靖)    HTTPS 是 HTTP over Secure Socket Layer,以安全为目标的 HTTP 通道,所以在

让浏览器不再显示 https 页面中的 http 请求警报

2015/08/26 · 基础技术 · HTTPS, 浏览器

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

HTTPS 是 HTTP over Secure Socket Layer,以安全为目标的 HTTP 通道,所以在 HTTPS 承载的页面上不允许出现 http 请求,一旦出现就是提示或报错:

Mixed Content: The page at ‘‘ was loaded over HTTPS, but requested an insecure image ‘’. This content should also be served over HTTPS.

HTTPS改造之后,我们可以在很多页面中看到如下警报:

2020欧洲杯冠军竞猜官方网站 1

很多运营对 https 没有技术概念,在填入的数据中不免出现 http 的资源,体系庞大,出现疏忽和漏洞也是不可避免的。

摘要

目前有许多的恶意攻击都是以网站及其用户作为目标,本文将简要介绍在 Web 服务器一侧的安全加固和测试方法。

攻击方式 防护方式 说明
点击劫持(clickjacking) X-Frame-Options Header -----
基于 SSL 的中间人攻击(SSL Man-in-the-middle) HTTP Strict Transport Security -----
跨站脚本(Cross-site scripting,XSS) X-XSS-Protection、Content-Security-Policy、X-Content-Type-Options -----

关于启用 HTTPS 的一些经验分享

2015/12/04 · 基础技术 · HTTP, HTTPS

原文出处: imququ(@屈光宇)   

随着国内网络环境的持续恶化,各种篡改和劫持层出不穷,越来越多的网站选择了全站 HTTPS。就在今天,免费提供证书服务的 Let’s Encrypt 项目也正式开放,HTTPS 很快就会成为 WEB 必选项。HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能,可以有效防止数据被查看或篡改,以及防止中间人冒充。本文分享一些启用 HTTPS 过程中的经验,重点是如何与一些新出的安全规范配合使用。至于 HTTPS 的部署及优化,之前写过很多,本文不重复了。

CSP设置upgrade-insecure-requests

好在 W3C 工作组考虑到了我们升级 HTTPS 的艰难,在 2015 年 4 月份就出了一个 Upgrade Insecure Requests 的草案,他的作用就是让浏览器自动升级请求。

在我们服务器的响应头中加入:

header("Content-Security-Policy: upgrade-insecure-requests");

1
header("Content-Security-Policy: upgrade-insecure-requests");

我们的页面是 https 的,而这个页面中包含了大量的 http 资源(图片、iframe等),页面一旦发现存在上述响应头,会在加载 http 资源时自动替换成 https 请求。可以查看 google 提供的一个 demo2020欧洲杯冠军竞猜官方网站,:

2020欧洲杯冠军竞猜官方网站 2

不过让人不解的是,这个资源发出了两次请求,猜测是浏览器实现的 bug:

2020欧洲杯冠军竞猜官方网站 3

当然,如果我们不方便在服务器/Nginx 上操作,也可以在页面中加入 meta 头:

XHTML

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

1
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

目前支持这个设置的还只有 chrome 43.0,不过我相信,CSP 将成为未来 web 前端安全大力关注和使用的内容。而 upgrade-insecure-requests 草案也会很快进入 RFC 模式。

从 W3C 工作组给出的 example,可以看出,这个设置不会对外域的 a 链接做处理,所以可以放心使用。

1 赞 收藏 评论

2020欧洲杯冠军竞猜官方网站 4

点击劫持(Clickjacking)

点击劫持,clickjacking 是一种在网页中将恶意代码等隐藏在看似无害的内容(如按钮)之下,并诱使用户点击的手段,又被称为界面伪装(UI redressing)。例如用户收到一封包含一段视频的电子邮件,但其中的“播放”按钮并不会真正播放视频,而是被诱骗进入一个购物网站。

2020欧洲杯冠军竞猜官方网站 5

针对点击劫持攻击,开放Web应用程序安全项目(Open Web Application Security Project ,OWASP)(非营利组织,其目的是协助个人、企业和机构来发现和使用可信赖软件) 提供了一份指引,《Defending_with_X-Frame-Options_Response_Headers》 。

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 frame 标签 或者 object 标签中展现的标记。网站可以使用此功能,来确保自己网站的内容没有被嵌到别人的网站中去,也从而避免了点击劫持 (clickjacking) 的攻击。DENY:表示该页面不允许在 frame 中展示,即便是在相同域名的页面中嵌套也不允许。SAMEORIGIN:表示该页面可以在相同域名页面的 frame 中展示。ALLOW-FROM uri:表示该页面可以在指定来源的 frame 中展示。配置如下:

//HAProxy
http-response set-header X-Frame-Options:DENY
//Nginx
add_header X-Frame-Options "DENY";
//Java
response.addHeader("x-frame-options","DENY");

理解 Mixed Content

HTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content(混合内容),不同浏览器对 Mixed Content 有不一样的处理规则。

跨站脚本 Cross-site scripting (XSS)

跨站脚本通常指的是通过利用开发时留下的漏洞,注入恶意指令代码(JavaScript/Java/VBScript/ActiveX/Flash/HTML等)到网页,使用户加载并执行攻击者恶意制造的程序。攻击者可能得到更高的权限、私密网页、会话和cookie等各种内容。目前有两种不同的 HTTP 响应头可以用来防止 XSS 攻击,它们是:

  • X-XSS-Protection
  • Content-Security-Policy

早期的 IE

早期的 IE 在发现 Mixed Content 请求时,会弹出「是否只查看安全传送的网页内容?」这样一个模态对话框,一旦用户选择「是」,所有 Mixed Content 资源都不会加载;选择「否」,所有资源都加载。

X-XSS-Protection

HTTP X-XSS-Protection 响应头是Internet Explorer,Chrome和Safari的一个功能,当检测到跨站脚本攻击 (XSS)时,浏览器将停止加载页面。配置选项:0 禁止XSS过滤。1 启用XSS过滤(通常浏览器是默认的)。 如果检测到跨站脚本攻击,浏览器将清除页面(删除不安全的部分)。mode=block 启用XSS过滤, 如果检测到攻击,浏览器将不会清除页面,而是阻止页面加载。report=reporting-URI 启用XSS过滤。 如果检测到跨站脚本攻击,浏览器将清除页面并使用 CSP report-uri 指令的功能发送违规报告。参考文章《The misunderstood X-XSS-Protection》:

//HAProxy
http-response set-header X-XSS-Protection: 1;mode=block
//Nginx
add_header X-Xss-Protection "1; mode=block" always;;

浏览器支持情况:

Chrome Edge Firefox Internet Explorer Opera Safari
(Yes) (Yes) No 8.0 (Yes) (Yes)

比较新的 IE

比较新的 IE 将模态对话框改为页面底部的提示条,没有之前那么干扰用户。而且默认会加载图片类 Mixed Content,其它如 JavaScript、CSS 等资源还是会根据用户选择来决定是否加载。

Content-Security-Policy

内容安全性政策(Content Security Policy,CSP)就是一种白名单制度,明确告诉客户端哪些外部资源(脚本/图片/音视频等)可以加载和执行。浏览器可以拒绝任何不来自预定义位置的任何内容,从而防止外部注入的脚本和其他此类恶意内容。设置 Content-Security-Policy Header:

//HAProxy:
http-response set-header Content-Security-Policy:script-src https://www.google-analytics.com;https://q.quora.com
//Nginx
add_header Content-Security-Policy-Report-Only "script-src https://www.google-analytics.com https://q.quora.com";

现代浏览器

现代浏览器(Chrome、Firefox、Safari、Microsoft Edge),基本上都遵守了 W3C 的 Mixed Content 规范,将 Mixed Content 分为Optionally-blockable 和 Blockable 两类:

Optionally-blockable 类 Mixed Content 包含那些危险较小,即使被中间人篡改也无大碍的资源。现代浏览器默认会加载这类资源,同时会在控制台打印警告信息。这类资源包括:

  • 通过 <img> 标签加载的图片(包括 SVG 图片);
  • 通过 <video> / <audio> 和 <source> 标签加载的视频或音频;
  • 预读的(Prefetched)资源;

除此之外所有的 Mixed Content 都是 Blockable,浏览器必须禁止加载这类资源。所以现代浏览器中,对于 HTTPS 页面中的 JavaScript、CSS 等 HTTP 资源,一律不加载,直接在控制台打印错误信息。

MIME-Sniffing

MIME-Sniffing(主要是Internet Explorer)使用的一种技术,它尝试猜测资源的 MIME 类型(也称为 Content-Type 内容类型)。这意味着浏览器可以忽略由 Web 服务器发送的 Content-Type Header,而不是尝试分析资源(例如将纯文本标记为HTML 标签),按照它认为的资源(HTML)渲染资源而不是服务器的定义(文本)。虽然这是一个非常有用的功能,能够纠正服务器发送的错误的 Content-Type,但是心怀不轨的人可以轻易滥用这一特性,这使得浏览器和用户可能被恶意攻击。例如,如通过精心制作一个图像文件,并在其中嵌入可以被浏览器所展示和执行的HTML和t代码。《Microsoft Developer Network:IE8 Security Part V: Comprehensive Protection》:

Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.

//HAProxy
http-response set-header X-Content-Type-Options: nosniff
//Nginx
add_header X-Content-Type-Options "nosniff" always;

移动浏览器

前面所说都是桌面浏览器的行为,移动端情况比较复杂,当前大部分移动浏览器默认都允许加载 Mixed Content。也就是说,对于移动浏览器来说,HTTPS 中的 HTTP 资源,无论是图片还是 JavaScript、CSS,默认都会加载。

一般选择了全站 HTTPS,就要避免出现 Mixed Content,页面所有资源请求都走 HTTPS 协议才能保证所有平台所有浏览器下都没有问题。

SSL Strip Man-in-The-Middle Attack

中间人攻击中攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。例如,在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者,可以将自己作为一个中间人插入这个网络。强制用户使用HTTP严格传输安全(HTTP Strict Transport Security,HSTS)。 HSTS 是一套由 IETF 发布的互联网安全策略机制。Chrome 和 Firefox 浏览器有一个内置的 HSTS 的主机列表,网站可以选择使用 HSTS 策略强制浏览器使用 HTTPS 协议与网站进行通信,以减少会话劫持风险。

2020欧洲杯冠军竞猜官方网站 6

服务器设置下列选项可以强制所有客户端只能通过 HTTPS 连接:

//HAProxy
http-response set-header Strict-Transport-Security max-age=31536000;includeSubDomains;preload
//Nginx
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload; always;'

合理使用 CSP

CSP,全称是 Content Security Policy,它有非常多的指令,用来实现各种各样与页面内容安全相关的功能。这里只介绍两个与 HTTPS 相关的指令,更多内容可以看我之前写的《Content Security Policy Level 2 介绍》。

暴露 URL (HTTPS > HTTP Sites)

Referrer 信息被广泛用于网络访问流量来源分析,它是众多网站数据统计服务的基础,例如 Google Analytics 和 AWStats,基于Perl的开源日志分析工具。同样的这一特性也会很容易被恶意利用,造成用户敏感信息泄漏,例如将用户 SESSION ID 放在 URL 中,第三方拿到就可能看到别人登录后的页面内容。2014 年,W3C 发布了 Referrer Policy 的新草案,开发者开始有权控制自己网站的 Referrer Policy。但是仅有 Chrome/Firefox 浏览器较新的版本的能够提供支持。

Feature Chrome Firefox Edge、Internet Explorer、 Opera、Safari
Basic Support 56.0 50.0 (No)
same-origin (No)1 52.0 (No)
strict-origin (No)1 52.0 (No)
strict-origin-when-cross-origin (No)1 52.0 (No)

Referrer-Policy选项列表:

  • Referrer-Policy: no-referrer //整个 Referer 首部会被移除。访问来源信息不随着请求一起发送。
  • Referrer-Policy: no-referrer-when-downgrade //默认选项
    //引用页面的地址会被发送(HTTPS->HTTPS),降级的情况不会被发送 (HTTPS->HTTP)
  • Referrer-Policy: origin //在任何情况下,仅发送文件的源作为引用地址
  • Referrer-Policy: origin-when-cross-origin //对于同源的请求,会发送完整的URL作为引用地址,但是对于非同源请求仅发送文件的源
  • Referrer-Policy: same-origin //对于同源的请求会发送引用地址,但是对于非同源请求则不发送引用地址信息。
  • Referrer-Policy: strict-origin //在同等安全级别的情况下,发送文件的源作为引用地址(HTTPS->HTTPS)
  • Referrer-Policy: strict-origin-when-cross-origin //对于同源的请求,会发送完整的URL作为引用地址
  • Referrer-Policy: unsafe-url //无论是否同源请求,都发送完整的 URL(移除参数信息之后)作为引用地址。

我们必须确保用户从全 HTTPS 站点跳转到 HTTP 站点的时候,没有中间人可以嗅探出用户实际的 HTTPS URL,Referrer Policy 设置如下:

//HAProxy
http-response set-header Referrer-Policy no-referrer-when-downgrade
//Nginx
add_header Referrer-Policy: no-referrer-when-downgrade
Source Destination Referrer (Policy :no-referrer-when-downgrade)
https://test.com/blog1/ http://test.com/blog2/ NULL
https://test.com/blog1/ https://test.com/blog2/ https://test.com/blog1/
http://test.com/blog1/ http://test.com/blog2/ http://test.com/blog1/
http://test.com/blog1/ http://example.com http://test.com/blog1/
http://test.com/blog1/ https://example.com http://test.com/blog1/
https://test.com/blog1/ http://example.com NULL

block-all-mixed-content

前面说过,对于 HTTPS 中的图片等 Optionally-blockable 类 HTTP 资源,现代浏览器默认会加载。图片类资源被劫持,通常不会有太大的问题,但也有一些风险,例如很多网页按钮是用图片实现的,中间人把这些图片改掉,也会干扰用户使用。

通过 CSP 的 block-all-mixed-content 指令,可以让页面进入对混合内容的严格检测(Strict Mixed Content Checking)模式。在这种模式下,所有非 HTTPS 资源都不允许加载。跟其它所有 CSP 规则一样,可以通过以下两种方式启用这个指令:

HTTP 响应头方式:

JavaScript

Content-Security-Policy: block-all-mixed-content

1
Content-Security-Policy: block-all-mixed-content

<meta> 标签方式:

XHTML

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

1
<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

测试

安全研究员 Scott Helme 贡献了一个非常棒的网站 [https://securityheaders.io/],可以分析自己站点的Header(报文头),并提出改进安全性的建议。示例如下(环境参数,Operating System: CentOS 7 ; haproxy 1.5.14 ; nginx 1.12.0)。

  • 加固前的检测结果
![](https://upload-images.jianshu.io/upload_images/1037849-af2f51678e583572.png)

加固前
  • 加固后的检测结果
![](https://upload-images.jianshu.io/upload_images/1037849-3d4af6ce7042c7b9.png)

加固后

upgrade-insecure-requests

历史悠久的大站在往 HTTPS 迁移的过程中,工作量往往非常巨大,尤其是将所有资源都替换为 HTTPS 这一步,很容易产生疏漏。即使所有代码都确认没有问题,很可能某些从数据库读取的字段中还存在 HTTP 链接。

而通过 upgrade-insecure-requests 这个 CSP 指令,可以让浏览器帮忙做这个转换。启用这个策略后,有两个变化:

  • 页面所有 HTTP 资源,会被替换为 HTTPS 地址再发起请求;
  • 页面所有站内链接,点击后会被替换为 HTTPS 地址再跳转;

跟其它所有 CSP 规则一样,这个指令也有两种方式来启用,具体格式请参考上一节。需要注意的是 upgrade-insecure-requests 只替换协议部分,所以只适用于 HTTP/HTTPS 域名和路径完全一致的场景。

合理使用 HSTS

在网站全站 HTTPS 后,如果用户手动敲入网站的 HTTP 地址,或者从其它地方点击了网站的 HTTP 链接,依赖于服务端 301/302 跳转才能使用 HTTPS 服务。而第一次的 HTTP 请求就有可能被劫持,导致请求无法到达服务器,从而构成 HTTPS 降级劫持。

HSTS 基本使用

这个问题可以通过 HSTS(HTTP Strict Transport Security,RFC6797)来解决。HSTS 是一个响应头,格式如下:

JavaScript

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

1
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age,单位是秒,用来告诉浏览器在指定时间内,这个网站必须通过 HTTPS 协议来访问。也就是对于这个网站的 HTTP 地址,浏览器需要先在本地替换为 HTTPS 之后再发送请求。

includeSubDomains,可选参数,如果指定这个参数,表明这个网站所有子域名也必须通过 HTTPS 协议来访问。

preload,可选参数,后面再介绍它的作用。

HSTS 这个响应头只能用于 HTTPS 响应;网站必须使用默认的 443 端口;必须使用域名,不能是 IP。而且启用 HSTS 之后,一旦网站证书错误,用户无法选择忽略。

HSTS Preload List

可以看到 HSTS 可以很好的解决 HTTPS 降级攻击,但是对于 HSTS 生效前的首次 HTTP 请求,依然无法避免被劫持。浏览器厂商们为了解决这个问题,提出了 HSTS Preload List 方案:内置一份列表,对于列表中的域名,即使用户之前没有访问过,也会使用 HTTPS 协议;列表可以定期更新。

目前这个 Preload List 由 Google Chrome 维护,Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加进这个列表,首先需要满足以下条件:

  • 拥有合法的证书(如果使用 SHA-1 证书,过期时间必须早于 2016 年);
  • 将所有 HTTP 流量重定向到 HTTPS;
  • 确保所有子域名都启用了 HTTPS;
  • 输出 HSTS 响应头:
    • max-age 不能低于 18 周(10886400 秒);
    • 必须指定 includeSubdomains 参数;
    • 必须指定 preload 参数;

即便满足了上述所有条件,也不一定能进入 HSTS Preload List,更多信息可以看这里。通过 Chrome 的 chrome://net-internals/#hsts工具,可以查询某个网站是否在 Preload List 之中,还可以手动把某个域名加到本机 Preload List。

对于 HSTS 以及 HSTS Preload List,我的建议是只要你不能确保永远提供 HTTPS 服务,就不要启用。因为一旦 HSTS 生效,你再想把网站重定向为 HTTP,之前的老用户会被无限重定向,唯一的办法是换新域名。

CDN 安全

对于大站来说,全站迁移到 HTTPS 后还是得用 CDN,只是必须选择支持 HTTPS 的 CDN 了。如果使用第三方 CDN,安全方面有一些需要考虑的地方。

合理使用 SRI

HTTPS 可以防止数据在传输中被篡改,合法的证书也可以起到验证服务器身份的作用,但是如果 CDN 服务器被入侵,导致静态文件在服务器上被篡改,HTTPS 也无能为力。

W3C 的 SRI(Subresource Integrity)规范可以用来解决这个问题。SRI 通过在页面引用资源时指定资源的摘要签名,来实现让浏览器验证资源是否被篡改的目的。只要页面不被篡改,SRI 策略就是可靠的。

有关 SRI 的更多说明请看我之前写的《Subresource Integrity 介绍》。SRI 并不是 HTTPS 专用,但如果主页面被劫持,攻击者可以轻松去掉资源摘要,从而失去浏览器的 SRI 校验机制。

了解 Keyless SSL

另外一个问题是,在使用第三方 CDN 的 HTTPS 服务时,如果要使用自己的域名,需要把对应的证书私钥给第三方,这也是一件风险很高的事情。

CloudFlare 公司针对这种场景研发了 Keyless SSL 技术。你可以不把证书私钥给第三方,改为提供一台实时计算的 Key Server 即可。CDN 要用到私钥时,通过加密通道将必要的参数传给 Key Server,由 Key Server 算出结果并返回即可。整个过程中,私钥都保管在自己的 Key Server 之中,不会暴露给第三方。

CloudFlare 的这套机制已经开源,如需了解详情,可以查看他们官方博客的这篇文章:Keyless SSL: The Nitty Gritty Technical Details。

好了,本文先就写到这里,需要注意的是本文提到的 CSP、HSTS 以及 SRI 等策略都只有最新的浏览器才支持,详细的支持度可以去CanIUse 查。切换到 HTTPS 之后,在性能优化上有很多新工作要做,这部分内容我在之前的博客中写过很多,这里不再重复,只说最重要的一点:既然都 HTTPS 了,赶紧上 HTTP/2 才是正道。

1 赞 4 收藏 评论

2020欧洲杯冠军竞猜官方网站 7

编辑:2020欧洲杯冠军竞猜官方网站 本文来源:的一部分经验分享,伏乞警报

关键词: 欧洲杯竞猜