为什么你的网页需要 CSP?

内容安全策略(CSP)是一个 HTTP HeaderCSP 通过告诉浏览器一系列规则,严格规定页面中哪些资源允许有哪些来源, 不在指定范围内的统统拒绝。

使用它是防止跨站点脚本(XSS)漏洞的最佳方法。由于难以使用 CSP 对现有网站进行改造(可通过渐进式的方法),因此 CSP 对于所有新网站都是强制性的,强烈建议对所有现有高风险站点进行 CSP 策略配置。

为什么要配置

CSP 的主要好处就是可以全面禁止使用不安全的嵌入式 JavaScript。内联 JavaScript(无论是反射的还是存储的),意味着不正确的转义用户输入都可以被 Web 浏览器解释为 JavaScript 代码。通过使用 CSP 禁用嵌入式 JavaScript,你可以有效消除针对你站点的几乎所有 XSS 攻击。

注意,禁用内联 JavaScript 意味着必须从 src 标记加载所有 JavaScript <script>。直接在标记上使用的事件处理程序(例如 onclick )将无法正常工作,<script>标记内的 JavaScript 也会通过。此外,使用 <style> 标签或 style 属性的内联样式表也将无法加载。因此为了让 CSP 易于实现,在设计站点时必须非常小心。

如何配置?

开启 CSP 很简单, 你只需要配置你的网络服务器返回 Content-Security-Policy 这个 HTTP Header (有时你会看到一些关于X-Content-Security-Policy Header 的提法, 那是旧版本,你无须再如此指定它)。

除此之外,<meta> 元素也可以被用来配置该策略, 例如

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

指令

无论是 header ,还是在 <meta> 标签中指定,其值的格式都是统一的,由一系列 CSP 指令(directive)组合而成。

Content-Security-Policy: <policy-directive>; <policy-directive>

这里 directive,即指令,是 CSP 规范中规定用以详细详述某种资源的来源,比如前面示例中使用的 script-src,指定脚本可以有哪些合法来源,img-src 则指定图片的合法涞源,以下是常用指令:

  • base-uri 限制可出现在页面 <base> 标签中的链接。
  • child-src 列出可用于 worker 及以 frame 形式嵌入的链接。譬如: child-src https://youtube.com 表示只能从 Youtube 嵌入视频资源。
  • connect-src 可发起连接的地址 (通过 XHR, WebSockets 或 EventSource)。
  • font-src 字体来源。譬如,要使用 Google web fonts 则需要添加 font-src https://themes.googleusercontent.com 规则。
  • form-action <form>标签可提交的地址。
  • frame-ancestors 当前页面可被哪些来源所嵌入(与 child-src 正好相反)。作用于 <frame>, <iframe>, <embed><applet>。该指令不能通过 <meta>指定且只对非 HTML文档类型的资源生效。
  • frame-src 该指令已在 level 2 中废弃但会在 level 3 中恢复使用。未指定的情况下回退到 tochild-src 指令。
  • img-src 指定图片来源。
  • media-src 限制音视频资源的来源。
  • object-src Flash 及其他插件的来源。
  • plugin-types 限制页面中可加载的插件类型。
  • report-uri 指定一个可接收 CSP 报告的地址,浏览器会在相应指令不通过时发送报告。不能通过 <meta> 标签来指定。
  • style-src 限制样式文件的来源。
  • upgrade-insecure-requests 指导客户端将页面地址重写,HTTP 转 HTTPS。用于站点中有大量旧地址需要重定向的情形。
  • worker-src CSP Level 3 中的指令,规定可用于 worker, shared worker, 或 service worker 中的地址。

预设值

除了配置指定的涞源以外,这些指令还可以配置一些预定义的值来完成一些默认配置:

  • none 不匹配任何东西。
  • self 匹配当前域,但不包括子域。比如 example.com 可以,api.example.com 则会匹配失败。
  • unsafe-inline 允许内嵌的脚本及样式。是的,没看错,对于页面中内嵌的内容也是有相应限制规则的。
  • unsafe-eval 允许通过字符串动态创建的脚本执行,比如 eval,setTimeout 等。


如果页面中非得用内联的写法,还有种方式。即页面中这些内联的脚本或样式标签,赋值一个加密串,这个加密串由服务器生成,同时这个加密串被添加到页面的响应头里面。

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">

  // 这里放置内联在 HTML 中的代码

</script> 

页面 HTTP 响应头的 Content-Security-Policy配置中包含相同的加密串:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

配置示例

示例 1

所有内容均来自站点的同一个源 (不包括其子域名)

Content-Security-Policy: default-src 'self'

示例 2

允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)

Content-Security-Policy: default-src 'self' *.trusted.com

示例 3

允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得),所有脚本必须从特定主机服务器获取可信的代码.

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

在这里,各种内容默认仅允许从文档所在的源获取, 但存在如下例外:

  • 图片可以从任何地方加载(注意 "*" 通配符)。
  • 多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)。
  • 可运行脚本仅允许来自于userscripts.example.com。

示例 4

一个线上银行网站的管理者想要确保网站的所有内容都要通过SSL方式获取,以避免攻击者窃听用户发出的请求。

Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

该服务器仅允许通过HTTPS方式并仅从onlinebanking.jumbobank.com域名来访问文档。

示例 5

一个在线邮箱的管理者想要允许在邮件里包含HTML,同样图片允许从任何地方加载,但不允许JavaScript或者其他潜在的危险内容(从任意位置加载)。

Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

注意这个示例并未指定script-src。在此CSP示例中,站点通过 default-src 指令的对其进行配置,这也同样意味着脚本文件仅允许从原始服务器获取。

上报你的数据

当检测到非法资源时,除了控制台看到的报错信息,也可以让浏览器将日志发送到服务器以供后续分析使用。接收报告的地址可在 Content-Security-Policy 响应头中通过 report-uri指令来配置。当然,服务端需要编写相应的服务来接收该数据。

配置 report-uri

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;`

服务端收到请求:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

Report Only

CSP 提供了一种报告模式,该模式下资源不会真的被限制加载,只会对检测到的问题进行上报 ,以 JSON 数据的形式发送到 report-uri 指定的地方。

通过指定 Content-Security-Policy-Report-Only 而不是 Content-Security-Policy,则开启了报告模式。

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

当然,你也可以同时指定两种响应头,各自里的规则还会正常执行,不会互相影响。比如:

Content-Security-Policy: img-src *;

Content-Security-Policy-Report-Only: img-src ‘none’; report-uri http://reportcollector.example.com/collector.cgi

这里图片还是会正常加载,但是 img-src ‘none’ 也会检测到并且发送报告。

报告模式对于测试非常有用。在开启 CSP 之前肯定需要对整站做全面的测试,将发现的问题及时修复后再真正开启,比如上面提到的对内联代码的改造。

如何检验配置成功了?

在Network中可以看到配置成功的header:

下面是 Twitter 的一个配置示例,非常完善:


在控制台可以看到资源 block 报错:


Network中可以看到Block资源上报:

Chrome 81 正式发布 !消灭混合内容最后一步~

Chrome 81 于前天正式发布了,这个版本其实最初是计划在 3 月 17 号 发布的,但由于冠状病毒(COVID-19)爆发而导致推迟到了现在。Chrome 81 的延迟也扰乱了 Google 正常的六周发布时间表。因此 Google 此前也宣布,下一个版本将直接跳过 Chrome 82 ,直接发布 Chrome 83。 下面我就来带大家看看 Chrome 81 有哪些重要的更新。

发布于:1月以前  |  104次阅读  |  详细内容 »

当浏览器全面禁用三方 Cookie

苹果公司前不久对 Safari 浏览器进行一次重大更新,这次更新完全禁用了第三方 Cookie,这意味着,默认情况下,各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie,但是由于这些浏览器市场份额较小,并没有给市场带来巨大的冲击。

发布于:1月以前  |  91次阅读  |  详细内容 »

H5 直播的疯狂点赞动画是如何实现的?

直播有一个很重要的互动:点赞。 为了烘托直播间的氛围,直播相对于普通视频或者文本内容,点赞通常有两个特殊需求: 点赞动作无限次,引导用户疯狂点赞 直播间的所有疯狂点赞,都需要在所有用户界面都动画展现出来(广播用户使用websocket消息)

发布于:1月以前  |  89次阅读  |  详细内容 »

探索 Serverless 中的前端开发模式

最近关于 Serverless 的讨论越来越多。看似与前端关系不大的 Serverless,其实早已和前端有了渊源,并且将对前端开发模式产生变革性的影响。本文主要就根据个人理解和总结,从前端开发模式的演进、基于 Serverless 的前端开发案例以及 Serverless 开发最佳实践等方面,与大家探讨 Serverless 中的前端开发模式。本人也有幸在 QCon2019 分享了这一主题。

发布于:1月以前  |  115次阅读  |  详细内容 »

前端需要了解的9种设计模式

设计模式是对软件设计开发过程中反复出现的某类问题的通用解决方案。设计模式更多的是指导思想和方法论,而不是现成的代码,当然每种设计模式都有每种语言中的具体实现方式。学习设计模式更多的是理解各种模式的内在思想和解决的问题,毕竟这是前人无数经验总结成的最佳实践,而代码实现则是对加深理解的辅助。

发布于:1月以前  |  96次阅读  |  详细内容 »

为什么你的网页需要 CSP?

内容安全策略(CSP)是一个 HTTP Header,CSP 通过告诉浏览器一系列规则,严格规定页面中哪些资源允许有哪些来源, 不在指定范围内的统统拒绝。

发布于:1月以前  |  87次阅读  |  详细内容 »

10 种跨域解决方案(附终极方案)

嗯。又来了,又说到跨域了,这是一个老生常谈的话题,以前我觉得这种基础文章没有什么好写的,会想着你去了解底层啊,不是很简单吗。但是最近在开发一个 「vscode 插件」 发现,当你刚入门一样东西的时候,你不会想这么多,因为你对他不熟悉,当你遇到不会的东西,你就是想先找到解决方案,然后通过这个解决方案再去深入理解。

发布于:1月以前  |  140次阅读  |  详细内容 »

移动 Web 最佳实践(干货长文,建议收藏)

笔者在公司用 web 技术开发移动端应用已经有一年多的时间了,开始主要以 vue 技术栈配合 native 为主,目前演进成 vue + react native 技术架构,vue 主要负责开发 OA 业务,比如报销、出差、crm 等等,react native 主要负责即时通信部分,是在 mattermost-mobile的基础上修改的(mattermost 是一个开源的即时通讯方案)。

发布于:1月以前  |  100次阅读  |  详细内容 »

不可错过的实用前端工具

给大家整理了 25 个前端相关的学习网站和一些靠谱的小工具,包括一些小游戏、教程、社区网站和博客,以及一些资源网站,希望可以帮助到大家!

发布于:1月以前  |  92次阅读  |  详细内容 »

理解 WebView

我们通常使用 Chrome, Firefox, Safari, Internet Explorer 和 Edge 等浏览器来浏览网页。你也许正在使用其中一种浏览器阅读本文!虽然浏览器对于访问互联网内容的任务来说非常流行,它们还有一些我们从未过多关注过的竞争对手。这些竞争对手以 WebView 的形式被我们所熟知。这片文章将讲解 WebView 的神秘之处以及为什么它这么棒。

发布于:1月以前  |  94次阅读  |  详细内容 »

Facebook 前端技术栈重构分享

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对Facebook(我们已知的)所有期望的功能,我们现有的技术栈无法支持我们所需要的类似于桌面应用的感觉和性能。

发布于:1月以前  |  95次阅读  |  详细内容 »

最多阅读

为Electron程序添加运行时日志 1年以前  |  4813次阅读
初探 React 组件 1年以前  |  2169次阅读
wordpress标签页的制作 1年以前  |  2056次阅读
Node.js下通过配置host访问URL 1年以前  |  1995次阅读
js动态创建类和实例化 1年以前  |  1975次阅读
500行PHP代码搞定富文本安全过滤 1年以前  |  1954次阅读
22个HTML5的初级技巧 1年以前  |  1902次阅读
使用 SRI 增强 localStorage 代码安全 1年以前  |  1901次阅读
浅谈浏览器的原生拖拽事件 1年以前  |  1869次阅读
第三版主题上线 1年以前  |  1859次阅读
CSS清除浮动 1年以前  |  1855次阅读
2014年度总结 1年以前  |  1805次阅读
【译】V8 团队眼中的 ES6、ES7及未来 1年以前  |  1799次阅读
利用服务器返回header来传输数据 1年以前  |  1788次阅读
获取元素的计算的样式 1年以前  |  1784次阅读