让浏览器不再显示 https 页面中的 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改换之后,大家得以在广大页面中看见如下警报:

图片 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 —–

CSP设置upgrade-insecure-requests

幸亏 W3C 职业组考虑到了作者们晋级 HTTPS 的孤苦,在 二〇一六 年 5月份就出了一个 Upgrade Insecure Requests 的草案,他的功能正是让浏览器自动进级伏乞。

在大家服务器的响应头中参加:

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

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

我们的页面是 https 的,而那个页面中包蕴了汪洋的 http
能源(图片、iframe等),页面一旦发觉存在上述响应头,会在加载 http
能源时自动替换到 https 伏乞。能够查看 google
提供的二个 demo:

图片 2

可是令人不解的是,那一个财富发出了四遍呼吁,估计是浏览器完毕的 bug:

图片 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 草案也会快速步向猎豹CS6FC 形式。

从 W3C
专门的学问组给出的 example,能够看出,那么些装置不会对别国的
a 链接做拍卖,所以能够放心使用。

1 赞 收藏
评论

图片 4

点击威逼(Clickjacking)

点击威逼,clickjacking
是一种在网页校官恶意代码等掩没在左近无害的内容(如按键)之下,并诱使顾客点击的手法,又被称呼分界面伪装(UI
redressing)。譬喻顾客抽取一封包含一段录像的电子邮件,但里边的“播放”按钮并不会真正播放录制,而是被诈骗步向一个购物网址。

图片 5

本着点击威吓攻击,吐放Web应用程序安全项目(Open Web Application Security
Project
,OWASP)(非营利团体,其目标是帮忙个人、公司和机构来开采和动用可信赖任软件)
提供了一份辅导,《Defending_with_X-Frame-Options_Response_Headers》

X-Frame-Options HTTP 响应头是用来给浏览器指示允许贰个页面可以还是不可以在 frame
标签 可能 object
标签中显现的标记。网址可以应用此作用,来确认保障本身网站的开始和结果尚未被嵌到外人的网址中去,也就此幸免了点击威迫(clickjacking) 的抨击。DENY:表示该页面分歧意在 frame
中展示,即正是在同样域名的页面中嵌套也不允许。SAMEO库罗德IGIN:表示该页面能够在一样域名页面的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");

跨站脚本 Cross-site scripting (XSS)

跨站脚本日常指的是通过运用开拓时预留的纰漏,注入恶意指令代码(JavaScript/Java/VBScript/ActiveX/Flash/HTML等)到网页,使客户加载并实施攻击者恶意创制的主次。攻击者只怕获得越来越高的权力、私密网页、会话和cookie等种种内容。近日有二种分化的
HTTP 响应头能够用来严防 XSS 攻击,它们是:

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

X-XSS-Protection

HTTP X-XSS-Protection 响应头是Internet
Explorer,Chrome和Safari的一个效果,当检查实验到跨站脚本攻击
(XSS)时,浏览器将终止加载页面。配置选项:0 取缔XSS过滤。1
启用XSS过滤(常常浏览器是默许的)。
假设检查测量试验到跨站脚本攻击,浏览器将解决页面(删除不安全的部分)。mode=block
启用XSS过滤,
假如检查评定到攻击,浏览器将不会化解页面,而是阻止页面加载。report=reporting-U福特ExplorerI
启用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)

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";

MIME-Sniffing

MIME-Sniffing(主假如Internet Explorer)使用的一种技能,它尝试推测能源的
MIME 类型(也称之为 Content-Type 内容类型)。那意味着浏览器可以忽略由 Web
服务器发送的 Content-Type
Header,实际不是尝试深入分析财富(比方将纯文本标识为HTML
标签),依据它以为的财富(HTML)渲染财富并非服务器的概念(文本)。固然那是二个卓殊管用的效果与利益,能够校勘服务器发送的错误的
Content-Type,不过心怀不轨的人方可Infiniti制滥用这一特征,那使得浏览器和顾客可能被恶意抨击。举例,如通过精心制作三个图像文件,并在里头嵌入可以被浏览器所展现和施行的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;

SSL Strip Man-in-The-Middle Attack

高级中学档人攻击中攻击者与广播发表的两头分别创立独立的联系,并调换其所吸收接纳的数目,使通信的彼此以为他们正在通过一个私密的连天与对方间接对话,但骨子里整个会话都被攻击者完全调整。例如,在一个未加密的Wi-Fi
有线接入点的接受范围内的中等人攻击者,能够将团结充当三个中档人插入这几个网络。强制客户使用HTTP严峻传输安全(HTTP
Strict Transport
Security,HSTS)。 HSTS 是一套由
IETF
发表的互连网安全计策机制。Chrome 和 Firefox 浏览器有几个平放的 HSTS
的主机列表,网址能够采纳使用 HSTS 战略强制浏览器选取 HTTPS
左券与网址举办通讯,以降低会话威逼风险。

图片 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;'

暴露 URL (HTTPS > HTTP Sites)

Referrer
音讯被布满用于互联网访谈流量来源剖析,它是累累网址数量计算服务的基本功,比方
Google Analytics 和
AWStats,基于Perl的开源日志剖判工具。同样的这一特点也会很轻便被恶心使用,产生客户敏感音讯败露,比如将客商SESSION ID 放在 URAV4L 中,第三方得到就恐怕见到外人登陆后的页面内容。二〇一六年,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
    //对于同源的伸手,会发送完整的U奥迪Q5L作为援引地址,不过对于非同源央浼仅发送文书的源
  • Referrer-Policy: same-origin
    //对于同源的伸手会发送援引地址,可是对于非同源诉求则不发送援引地址新闻。
  • Referrer-Policy: strict-origin
    //在同等安全级其余情事下,发送文书的源作为引用地址(HTTPS->HTTPS)
  • Referrer-Policy: strict-origin-when-cross-origin
    //对于同源的呼吁,会发送完整的UEvoqueL作为援引地址
  • Referrer-Policy: unsafe-url //无论是还是不是同源央求,都发送完整的
    U凯雷德L(移除参数消息之后)作为援引地址。

咱俩亟须确认保证顾客从全 HTTPS 站点跳转到 HTTP
站点的时候,未有中间人能够嗅探出顾客实际的 HTTPS UV12 VantageL,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

测试

平安切磋员 斯科特 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)

加固后

相关文章