第 1 章 浏览器安全概述

第 1 章 浏览器安全概述

天生低调的浏览器却肩负着保护用户安全的重任。浏览器的工作机制,就是向整个互联网请求指令,请求到以后几乎不加任何质疑地去执行。浏览器之所以为浏览器,就是要忠实地汇聚远程获取的内容,把它们组织成人类可以辨识的形式,同时还要支持今天所谓的Web 2.0应有的丰富功能。

但是作为一款软件,浏览器又是如此重要:它不仅要帮你维护社交网络,还要替你完成在线银行的交易。这个软件有义务保证你在网络世界中的安全,无论你冒险闯入的是什么胡同街巷。这个软件有义务支持你在一个标签页里不知深浅的探险,同时又在另一个标签页里进行重大涉密交易。很多人把自己的浏览器当成装甲车,认为自己能坐在里面安全舒适地观察外面的世界,而不用担心泄漏任何个人隐私,或者遭受任何威胁。等把这本书全看完,你就会明白这个假设是否成立了。

这款“无所不能”的神奇软件的开发团队,必须确保其庞大身躯的每个角落、每道接缝,都不给黑客留下可乘之机。不管你是否这么想过,实际上你每次使用浏览器,都默认信任了从未谋面(很可能这辈子永远也不会见面)的一群人,相信这群人能够保障你的重要信息不会被互联网上的黑客窃取。

本章介绍Web浏览器攻防相关的方法论。我们会讨论浏览器在Web生态系统中扮演的角色,包括它与Web服务器之间的互动关系。此外,本章还会介绍一些浏览器安全基础知识,为本书后续各章的内容提供脉络。

1.1 首要问题

请大家暂时忘掉浏览器,只想着眼前有一块空白的安全画布。假设你身处这么一种境况:你要对一家公司的安全负责,必须作出某些决策。你在决定部署某个软件时,会不会考虑它可能面临的风险有多大?这个软件必须在标准运行环境(Standard Operating Environment,SOE)中无差异地安装到公司内的几乎所有机器上。人们要通过它来存取最敏感的数据,执行最敏感的操作。这个软件几乎是公司每个员工的日常工具,包括CEO、董事会成员、系统管理员、财务、人力资源,甚至你们的客户。鉴于它对公司的核心业务数据拥有如此高的权限,毫无疑问会成为黑客的理想攻击目标,因而面临极大风险。

这个软件的设计规格大致是这样的。

  • 它要向互联网请求指令,然后执行获取的指令。

    • 防御者无法控制这些指令。

    • 某些指令会要求这个软件从以下来源再次请求其他指令:

      • 互联网的其他地方;

      • 内部网的其他地方;

      • 非标准的HTTP和HTTPS TCP端口。

  • 某些指令会要求这个软件通过TCP发送数据。这可能会造成对其他联网设备的攻击。

  • 它会与互联网中任意服务器进行加密通信。防御者无法看到通信内容。

  • 它会不断向攻击者暴露攻击目标。它会在后台静默更新。

  • 它经常会依赖插件获得某些功能。没有统一的机制更新这些插件。

此外,对这个软件的相关研究表明:

  • 插件一般来说都不如核心软件本身安全;

  • 这个软件的每个变体都有文档载明的漏洞;

  • 一份安全情报报告(Security Intelligence Report)1得出结论,说这个软件是企业最大的威胁2

1Microsoft. (2013). Security Intelligence Report (SIR) Vol. 15. Retrieved December 12, 2013 from http://www.microsoft.com/security/sir/default.aspx

2Antone Gonsalves. (2013). Browsers pose the greatest threat to enterprise, Microsoft reports. Retrieved December 12, 2013 from http://www.networkworld.com/news/2013/041913-browsers-pose-the-greatest-threat-268914.html

显然,根据以上描述,你一定知道我们说的就是浏览器。不过,再次请你忘掉这些,以及相关的历史事件,回到我们那张空白的安全画布面前。想一想,就这种软件的部署量居然如此之高,真的都禁不住要怀疑人类的智商了。不论通过它获取数据有多方便,仅从其设计规格来看,它所面临的安全风险就是极其巨大的。

不过,回到现实当中,以上所有说法都是纯理论的探讨。实际上,我们已经走上了一条不归路。如今互联网上网站多如繁星,谁敢因为浏览器有重大安全隐患,就勒令所有员工卸载它?或许你知道,浏览器的装机量要以十亿计。不让员工装浏览器,无疑会降低其工作效率。更不用说这个措施多难让人接受,会被认为是开历史倒车了!

浏览器达到了前所未有的使用量,取决于个人的使用情况,也暴露出了各种各样的问题和安全挑战。对很多不搞技术的人来说,无处不在的浏览器就意味着“互联网”。浏览器只能展示IP协议(Internet Protocol)所能理解的数据。在互联网时代,浏览器在人们日常生活中的地位是不可动摇的,IT行业的发展也与它密不可分。

放眼四望,浏览器在网络中几乎无孔不入。用户网中有它,客户服务网中有它,甚至安全禁区(DMZ)中都有它的身影。不要忘了,很多情况下用户管理员必须使用浏览器来管理自己负责的网络设备。网络设备厂商都在顺应Web大潮,努力利用浏览器无所不在的现实,而不会考虑重新发明轮子。

人们对通过浏览器上网的依赖是毫无疑问的。实际上,与其问自己在哪里能看到浏览器,倒不如问自己在哪里看不到它。

1.2 揭密浏览器

你在上网的时候,网也会接触你。事实上,无论你是否能意识到,应该说每次都是你主动邀请它跟你亲密接触的。正是你,带着它穿过那些旨在保护你的网络安全的重重关卡,并执行那些只有你的最高权限才能控制的指令,一切都以渲染网页为名,把根本就不了解甚至不能信任的内容呈现于屏幕之上。

浏览器需要从操作系统获得一些特权才能运行,这一点与用户空间中的其他程序一样。这些特权都是由你——也就是所谓的用户——亲自授予的!用户输入是什么?不就是你向当前程序发出的一些指令嘛,而这个程序可能是Windows的资源管理器,也可能是UNIX的命令行客户端。用户输入和其他来源输入的唯一差别,就是程序在接收该输入时所体现的不同方式。

同样的认识可以应用到浏览器上。浏览器的主要功能就是从外部世界的任意位置获取并执行指令,而与它的这一行为相关的潜在风险是显而易见的。

1.2.1 与Web应用休戚与共

Web所采用的客户端—服务器模型发端于20世纪70年代3。客户端与服务器通信使用的是请求—响应4的方式,即浏览器负责发送请求,服务器负责给出响应。

3Wikipedia. (2013). Client-server model. Retrieved December 12, 2013 from http://en.wikipedia.org/wiki/Client-server_model

4Wikipedia. (2013). Request-response. Retrieved December 12, 2013 from http://en.wikipedia.org/wiki/Request-response

服务器和客户端必须相互依赖,才能发挥自己最大的潜能。可以说,它们俩完全是一个“命运共同体”:没有服务器,浏览器什么也看不到,而没有浏览器,服务器的内容也不知道要交给谁。这种共生的关系是Web上不计其数的复杂关系的源头。

这两个Web组件之间的紧密关系,同样也带来了安全问题。Web浏览器的安全会影响Web应用的安全,反之亦然。某些组件在独立的情况下可以保证安全,但更多的时候则要视另外一方的情况而定。一般来说,浏览器与应用之间的联结点是最需要保护的;从攻击者角度说,这些联结点也是主要攻击目标。举个例子,服务器在设定某个特定来源的cookie时,它希望浏览器能尊重该指令,而不要向其他来源泄露这个(可能比较敏感的)cookie。

浏览器与Web应用关联所带来的安全问题需要全面的认识。很多情况下,我们的讨论都必须涉及这两大组件之间的交互。而利用它们之间的关系,正是本书接下来所有章的使命。

当然,我们也鼓励大家不要就此止步,还应该进一步探索Web应用可能遭遇的种种威胁。在这里向初学者和有经验的安全专业人士推荐一本书,《黑客攻防技术宝典:Web实战篇(第2版)》5

5此书已由人民邮电出版社出版。——编者注

1.2.2 同源策略

浏览器中最重要的安全措施就是同源策略(Same Origin Policy,SOP)。同源策略用于限制不同来源的资源之间的交互。

同源策略的含义就是对于不同的页面,如果它们的主机名、协议和端口都相同,那它们就是同一来源的。如果上述三个属性中有任何一个不一样,那就不能算是同源了。而同一来源的资源,即主机名、协议和端口都相同的资源之间的交互,是不受限制的。

最初,同源策略只适用于外部资源,后来才扩展到包含其他来源的资源。比如,使用file://协议访问本地文件,使用chrome://协议访问浏览器相关的资源等。除了这两个协议之外,现在的浏览器还支持其他一些协议。

1.2.3 HTTP首部

可以把HTTP首部想象成写在信封上的地址和其他相关说明,它们描述的是它们封装的包应该发往何处,以及接收方该如何处理包中的内容。

在邮政包裹上,我们常常可以看到这样的说明:“易碎物品,小心轻放”“此面朝上”“危险品,易爆炸!”。HTTP数据包前头的HTTP首部与此类似。HTTP首部是HTTP协议定义的原初指令,用于指示接收方怎么处理其后的内容。Web客户端要在所有请求的开头提供HTTP首部,而Web服务器也要在任何响应的开头附上HTTP首部。

首部内容决定了接收方(可能是服务器,也可能是浏览器)如何处理被发送的内容。对于特定的交互而言,有些首部字段是必需的,有些首部字段是可选的,而另外一些首部字段则纯粹是为了提供额外信息用的。

1.2.4 标记语言

标记语言是一种描述如何显示内容的方式。具体来说,标记语言为在同一文档中创建数据占位符以及数据相关注释的占位符给出了标准的方式。我们目力所及的几乎任何一个网页都可能使用了标记语言,而标记语言负责告诉浏览器怎么把页面显示给我们。

标记语言也分很多种。有些标记语言应用很广,有些则没有那么通用,但每种标记语言都有自己擅长和不擅长的使用场景。不用说大家也知道,Web浏览器使用的标记语言是HTML。

1. HTML

HTML,即HyperText Markup Language(超文本标记语言),是一种常用的编程语言,主要用于告诉浏览器如何显示网页。HTML源于SGML(Standard Generalized Markup Language,标准通用标记语言),经过多年发展,已经有了非常大的变化。

对标记语言(数据与注释或指令并存)的依赖,是一些重要、持久和系统的安全问题的根源所在。本书后面还会详细讲到HTML,以及它的众多特性。

2. XML

XML与HTML的关系非常密切。如果你熟悉HTML,那么掌握XML不会太难。虽然在人类眼里,它们谁也长得不怎么好看,但它们却非常擅长表示复杂的数据。XML也是Web上常用的一种标记语言,最常用的情形是把它作为Web服务之间(或者通过远程过程调用)交换数据的标准格式。

1.2.5 CSS

CSS,即cascading style sheets(层叠样式表),是浏览器为网页内容指定样式的主要方法。注意,不是XSS。XSS指的是cross-site scripting,即跨站点脚本攻击。

CSS提供了一种把网页内容与样式分离的机制。CSS能干什么?举个简单的例子,它可以把一段话显示为粗体。当然,CSS的功能远比这要强大多了,通过它可以实现各种复杂的样式。

1.2.6 脚本

Web脚本语言是一门值得学习的艺术。如果你想搞Web技术,那迟早要掌握脚本语言。总体来说,脚本编程是在浏览器中实现Web开发必备的技能。

本书后面会讲到攻击者使用脚本利用浏览器的各种漏洞,包括XSS。因此,你必须对脚本编程有所了解。

1. JavaScript

JavaScript支持函数式编程和面向对象编程。与强类型的Java语言不同,JavaScript是弱类型的。JavaScript在Web开发的当下和可见未来,都是统治性的语言。所有浏览器默认的脚本语言都是JavaScript。

作为本书读者,你必须有JavaScript编程经验,因为书中大部分代码示例都是用它写的。使用JavaScript编写的攻击脚本,也是可以跨浏览器运行的(但不排除会受个别浏览器奇怪特性的影响)。不管怎么说,JavaScript都是探查浏览器漏洞必备的语言。

2. VBScript

VBScript只有微软的浏览器才支持,而且在真正的Web开发中几乎没人用了。这主要是因为不是所有浏览器都支持它,而它也是微软早期为了与网景公司的JavaScript抗衡才开发出来的。

VBScript的很多功能都可以使用JavaScript完成。显然,有人就会问了,VBScript还有必要存在吗?确实如此,即便微软还继续支持它,那也只能把它作为对IE过去辉煌的一种缅怀而已。

1.2.7 DOM

DOM,即document object model(文档对象模型),是浏览器中的一个基础性概念。DOM是在浏览器中操作HTML或XML文档的API,使用脚本语言可以通过DOM提供的对象操作HTML元素。

DOM是为JavaScript这样的脚本语言而定义的。DOM规范定义了通过脚本操作实时文档的方法,即浏览器中运行的脚本可以动态读取或修改网页内容。这样一来,网页可以不经过服务器就更新自己的内容,而且也不用用户参与。

1.2.8 渲染引擎

渲染引擎(rendering engine)在浏览器里有很多不同的称呼,比如布局引擎(layout engine)或浏览器引擎(web browser engine)6。本书不区分这些名字,将它们视为意思相同。

6Wikipedia. (2013). Web browser engine. Retrieved December 15, 2013 from http://en.wikipedia.org/wiki/Layout_engine

渲染引擎是浏览器的核心组件,负责把数据转换为用户在屏幕上可以看到的样式。浏览器可以把HTML、图片和CSS综合起来,共同决定用户在浏览器中看到的最终产品是什么样子。正是这些引擎让用户能够看到图形。说到图形,实际上也有只解析文本的渲染引擎,比如Lynx和W3M。

Web上的渲染引擎有很多种7。本书涉及的图形渲染引擎包括WebKit、Blink、Trident和Gecko。

7Wikipedia. (2013). List of layout engines. Retrieved December 15, 2013 from http://en.wikipedia.org/wiki/List_of_web_browser_engines

1. WebKit

WebKit是最受欢迎的渲染引擎,很多浏览器都在用。最著名的是苹果的Safari,还有以前的谷歌Chrome也用过它。应该说,WebKit是当今最流行的渲染引擎之一8

8Wikipedia. (2013). WebKit. Retrieved December 15, 2013 from http://en.wikipedia.org/wiki/WebKit

WebKit是一个开源项目,它的目标是成为通用的软件应用程序交互与展示引擎9。除了在浏览器中使用,还有邮件客户端和即时通信系统也在使用它。

9WebKit Open Source Project. (2013). The WebKit Open Source Project - WebKit Project Goals. Retrieved December 15, 2013 from http://www.webkit.org/projects/goals.html

2. Trident

Trident是微软开发的渲染引擎,也叫MSHTML。IE使用的Trident是闭源的,这一点不难想见。Trident算是第二流行的渲染引擎。

与WebKit类似,Trident也被用于浏览器之外的软件中,比如Google Talk。软件可以通过调用Windows系统中的mshtml.dll动态链接库来使用这个引擎。

Trident首次出现在Internet Explorer的第四个版本中,一直非常稳定。微软最新的IE至今还使用Trident作为核心渲染引擎。

3. Gecko

Firefox是使用Gecko开源渲染引擎的最主要的软件。Gecko应该是排在WebKit和Trident之后位居第三的渲染引擎。

Gecko是网景公司20世纪90年代为其浏览器Netscape Navigator开发的一个渲染引擎。目前,Gecko主要用在Mozilla基金会和Mozilla公司开发的一些应用中,最主要的就是Firefox浏览器。

4. Presto

Presto(在本书写作时)是Opera的渲染引擎。但Opera团队在2013年宣布将很快放弃其自家的Presto,迁移至WebKit Chromium10。WebKit Chromium后来改名为Blink(后面会介绍)。

10Bruce Lawson. (2013). 300 million users and move to WebKit. Retrieved December 15, 2013 from http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit

一个主流浏览器如此巨大地切换路线,应该说是前所未有的。而且,这样一来,Presto注定会消亡,成为浏览器大战的牺牲品。

5. Blink

2013年,谷歌宣布从WebKit分支出来,创建了新的Blink渲染引擎。Blink最初致力于更好地支持Chrome的多进程架构,降低该浏览器的内部复杂度。这个渲染引擎能否像WebKit那样走向辉煌,我们可以拭目以待。但谷歌关于削减其不必要功能的提议,确实是一个好兆头。

1.2.9 Geolocation

Geolocation API是为移动和桌面浏览器访问设备地理位置信息而开发的。该API可以通过GPS、蜂窝小区三角测量、IP地理定位和本地Wi-Fi热点取得地理位置信息。

现实世界中有很多滥用地理位置信息的例子。为此,浏览器也增加了很多严密的安全措施,使得攻击的主要方法只剩社会工程了。后面几章还会继续讨论这个话题。

1.2.10 Web 存储

Web 存储(Web storage)又称DOM 存储(DOM storage),原来是HTML5规范的一部分,现在已经剥离出来。可以把Web存储看成超级cookie。

与cookie类似,Web 存储有两种存储机制:一种可以将数据持久保存在本地,另一种只在会话期间保存数据。具体来说,本地存储(local storage)负责存储持久数据,用户多次访问都可以存取;会话存储(session storage)负责存储会话数据,只在创建该数据的标签页内有效。

cookie与Web存储的一个主要区别,就是只有JavaScript可以创建Web存储,HTTP首部不行了,而且Web存储中的数据也不会随请求发送给服务器。Web存储的数据量也比以往的cookie多得多,但也因浏览器而异,不过至少也有5 MB。另一个主要区别就是本地存储没有所谓的路径限制。

会话存储

下面是一个使用Web 存储 API的简单例子。在浏览器JavaScript控制台中运行以下命令,就可以在当前标签页的会话存储中保存一个"BHH"值:

sessionStorage.setItem("BHH", "http://browserhacker.com");
sessionStorage.getItem("BHH");

同源策略也适用于本地存储,而且每个来源都会分开。其他来源的资源不能访问当前的本地存储,子域也不行11

11Doug DePerry. (2012). HTML5 Security. The Modern Web Browser Perspective. Retrieved December 15, 2013 from https://www.isecpartners.com/media/18610/html5modernwebbrowserperspectivefinal.pdf

1.2.11 跨域资源共享

跨域资源共享,即CORS(cross-origin resource sharing),是一个让来源忽略同源策略的规范。在最宽松的配置下,Web应用可以通过XMLHttpRequest跨域访问任何资源。服务器通过HTTP首部通知浏览器它是否接受访问。

CORS的一项核心内容就是给Web服务器的HTTP响应首部增加了以下字段:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET

如果浏览器向某服务器发送了跨域XMLHttpRequest请求,而该服务器的响应首部并不包含以上字段,则这个跨域请求就会失败,即不能访问该服务器响应的内容。这其实就是与同源策略一致。然而,如果Web服务器返回了前面的首部,那么现代浏览器就会遵循CORS规范,允许对该来源响应内容的访问。

1.2.12 HTML5

HTML5是未来,其实更应该说是现在。虽然这个标准还在发展,但现代浏览器已经实现其核心功能。你现在使用的浏览器很可能已经支持HTML5的很多功能了。

HTML5是HTML的新版本,大幅增强了原有功能,进而增强了用户体验。

从安全角度来说,最明显的变化就是攻击面增大了。HTML5新增的很多方法暴露了HTML4没有暴露过的漏洞。当然,这样一样可用的功能也增多了。结果就是被成功攻击的风险也增大了。但这是任何技术进步都不可避免的,不能成为HTML停滞不前的理由。

本书会涵盖HTML5的一些新功能,但不完整。本节后面会简单介绍攻击中可以利用的新功能。

1. WebSocket

WebSocket是一种浏览器技术,利用它可以在浏览器与服务器之间打开一条即时响应的全双工信道。这样一来,不使用服务器轮询也可以实现高标准的事件驱动系统。

WebSocket替代了Comet12等基于Ajax的服务器端推送技术。但Comet需要客户端库,WebSocket API则完全是现代浏览器中的本地技术。包括IE10在内的所有现代浏览器都原生支持WebSocket,只有Opera Mini和安卓的原生浏览器例外。

12Alex Russell. (2006). Comet: Low Latency Data for the Browser. Retrieved March 8, 2013 from http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/

2. Web Worker

Web Worker之前的JavaScript代码都是单线程执行的。而要想实现并发,开发者就要依赖setTimeout()setInterval()

HTML5新增了Web Worker,可以看作在浏览器后台运行的线程。有两种Web Worker:一种可以在同一来源的资源间共享,另一种只能与创建它的函数通信。

虽然这个API也有一些局限,但仍然给开发人员提供了更多的灵活性。当然,攻击者因此也有了更多方式对浏览器发起攻击。

3. 操作历史

本书也会讨论很多种针对Web浏览器历史功能发起的攻击。历史功能随着浏览器的变化,也在不断发展变化。

以前,浏览器只要跟踪用户点了哪个链接才跳到新页面就行了。今天,点击链接可能会导致脚本执行并渲染页面,而这被视为用户体验的一个重要里程碑。

HTML5提供了操作历史记录的很多方法。使用历史对象,脚本可以添加或删除位置,也可以在历史链中向前或向后移动当前页面。

4. WebRTC

WebRTC,即Web Real-Time Communication(Web实时通信),是HTML5运用JavaScript能力的一个进步。使用WebRTC可以实现浏览器之间的互相通信,而且延迟很低,但要实现富媒体的实时交互,必须有高带宽支持。

在本书写作时,支持WebRTC的浏览器有最新版本的Chrome、Firefox和Opera,这些浏览器都原生支持WebRTC。WebRTC的功能包括直接访问相机和音频设备(用来支持视频会议)。这种实用但很容易被侵入的技术显然也会面临很多潜在的安全威胁。好在WebRTC是一个开源的标准,要想实现透明分析并不困难。

1.2.13 隐患

“隐患”(vulnerability)这个词指代一个抽象因而又很复杂的主题。不难想见,我们之所以写作出版这本书,正是因为浏览器有所谓的“隐患”存在。可是,什么是隐患,什么又不是,三言两语也讲不清楚。有时候,隐患原本是一个规规矩矩的功能,但后来却有人发现这个功能权限太宽松,于是这项功能就成了隐患。

更让人摸不着头脑的是,某些隐患有很多叫法,叫来叫去,非常容易混淆。为了清晰起见,本书所说的隐患指的都是容易被人攻击的意思。

关于利用编译后代码中的隐患,也有很多相关图书。本书内容与这些书不一样,主要关注浏览器安全这个主题。但浏览器安全这个话题,一本书很难面面俱到,甚至一书架书恐怕都难以穷尽!

如果有读者对利用编译后代码中的隐患感兴趣,可以找一本《黑客攻防技术宝典:系统实战篇(第2版)》看看。另外,所有对黑客攻防感兴趣的读者,都应该涉足源代码利用技术,因为这个领域实在太有意思了。

1.3 发展的压力

在IT领域,Web浏览器经历过的巨变非常激动人心。今天的浏览器在性能、安全和开发等方面都应用了最先进的技术,在极为激烈的竞争中面临着生与死的考验。

浏览器过去一度属于比较简单的软件。第一个浏览器的用途只有一个:显示萌芽时期的Web和跟踪超链接。而今,它们已经支持扩展、插件、相机、话筒和地理定位了。无需多言,浏览器已经发展成为一款极度复杂的软件。

在浏览器五彩斑斓的历史长河中,总是你方唱罢我登场,热闹非凡。有赢家,也有输家,有小众的最爱,也有大众的选择,而且各家浏览器的声望也是此起彼伏。网景公司是浏览器战争的早期阵亡者,但它的失败却催生了Mozilla以及Firefox。曾经雄霸浏览器市场并击败网景的老资格的IE,如今也江河日下,先是被开源浏览器重创,后来又被谷歌Chrome和苹果Safari等商业产品攻城掠地。然而,由于仍然不断进步,加上财大气粗的微软极力扶持,IE还在生存和发展。可以说,浏览器之争远远没有到落幕的时候。

战场已经转移,浏览器纷纷开辟新的疆土。互相竞争的一个结果,就是浏览器提供商意识到安全对用户的重要性,使得攻击浏览器的难度与日俱增。这主要表现在防御技术的不断进步上。

接下来,我们简要介绍一些当今浏览器在强化防御方面的安全特性。

1.3.1 HTTP首部

HTTP首部增加了很多安全特性。因为关于请求和响应的指令都放在HTTP首部,所以服务器通过它来指示浏览器加强安全防卫是自然而然的。

1. 内容安全策略

关于XSS的内容将在第2章详细讨论,这里为了解释清楚CSP(Content Security Policy,内容安全策略),需要简单提及它。CSP是为了降低XSS隐患而诞生的,为此它定义了指令与内容的差别。

服务器会发送CSP HTTP首部Content-Security-Policy或X-Content-Security-Policy,以规定可以从哪里加载脚本,同时还规定了对这些脚本的限制,比如是否允许执行JavaScript的eval()函数。

2. 安全cookie标志

过去,HTTP和HTTPS都可以发送cookie,不会加以区分。但这样有可能影响与浏览器建立的会话的安全性。通过HTTPS建立的安全会话暗号(token)有可能被攻击者通过标准HTTP请求获取。

这就是secure cookie标志希望一蹴而就解决的问题。这个标志的主要目的就是告诉浏览器不要通过任何不安全的渠道发送cookie,从而确保敏感的会话暗号无论何时何地都处于安全保护之中。

3. HttpOnly cookie标志

HttpOnly是另一个应用给cookie的标志,而且所有现代浏览器都支持它。HttpOnly标志的用途是指示浏览器禁止任何脚本访问cookie内容,这样就可以降低通过JavaScript发起的XSS攻击(详见第2章)偷取cookie的风险。

4. X-Content-Type-Options

浏览器可以使用各种检测技术判断服务器返回了什么类型的内容。然后,浏览器会执行一些与该内容类型相关的操作。而nosniff指令可以禁用浏览器的上述行为,强制浏览器按照Content-type首部来渲染内容。

举个例子,如果服务器给一个script标签返回的响应中带有nosniff指令,那么除非响应的MIME类型是application/javascript(或其他几个字符串),否则浏览器会忽略响应内容。对Wikipedia之类(允许上传)的网站来说,能做到这一点非常重要。

假如响应不包含这个指令,而且有人上传了一个特殊的文件,后来该文件又被人下载的话,可能就会造成威胁。此时,浏览器可能就会按照惯例错误地解释文件的MIME类型,例如把JPEG当作脚本来解释。从浏览器安全角度来看,很可能有人会利用这一点控制浏览器。比如,这个人上传一种允许上传的文件(看起来似乎很安全),而浏览器随后却以另一种比较危险和易变的方式去解释它。

5. Strict-Transport-Security

这个HTTP首部指示浏览器必须通过有效的HTTPS通道与网站通信。如果是一个不安全的连接,用户不可能接受HTTPS错误并继续浏览网站。相反,浏览器会解释错误,并且不允许用户继续浏览。

6. X-Frame-Options

X-Frame-Options HTTP首部用于阻止浏览器中的页面内嵌框架。浏览器在看到这个首部后,应该保证不把接收到的页面显示在一个IFrame中。

制定这个首部的目的是防止发生界面伪装(UI redressing)攻击,其中之一就是点击劫持(clickjacking)。这种攻击是把诱导页面放到一个完全透明的前景框架窗口中,而用户以为自己点击的是下方不透明的(被攻击的)页面,实际上点击的却是透明的前景(诱导)页面。

X-Frame-Options首部可以防止一部分界面伪装攻击,关于这类攻击,第4章将详细讨论。

1.3.2 反射型XSS过滤

这个浏览器安全特性试图检测、清除和阻止第2章将会介绍的反射型XSS(Reflected XSS)。浏览器会尝试被动地发现已经成功的反射型XSS攻击,然后尝试清除响应中的脚本,更多的时候是阻止它们执行。

1.3.3 沙箱

沙箱(sandbox)是一个解决现实问题的折中方案。基本前提是浏览器会遭受威胁,并且可能被攻击者控制。这还用说吗?!最简单也最实际的说法,就是开发者不可避免地会写出隐患代码来。

很多人都认为,软件产品中不可避免地会包含隐患代码。尽管安全社区的人会为此对开发人员说三道四,但事实如此,也不必隐讳。沙箱就是解决这个普遍性问题一个很好的尝试。

显然,开发人员多大程度上符合这个假设(即写出隐患代码),取决于很多复杂的因素,甚至包括睡眠不足或者咖啡豆质量不过关。沙箱本质上不过是缓兵之计,它把浏览器的高危区域封装在安全围墙之下,把注意力吸引到较小的攻击面上。对浏览器安全团队而言,这种风险与回报之比是很划算的。

沙箱并不是一个新点子,其他软件开发领域也有这个思想。比如,Sun公司对可信Solaris采取区域划分措施,而FreeBSD有Jails。对资源访问的限制取决于进程权限。

1. 浏览器沙箱

很多层面都可以使用沙箱机制。比如,可以应用在内核级别,把不同用户隔离开;可以应用在硬件级别,实现内核与用户空间的权限分离。

浏览器沙箱属于用户空间程序中最高层次的沙箱,它隔离的是操作系统赋予浏览器的权限和在浏览器中运行的子进程的权限。

要想完全拿下浏览器,至少要两步。第一步是找到浏览器功能上的漏洞,第二步就是突破沙箱。后者也叫绕开沙箱(sandbox bypass)。

在有的浏览器中,沙箱策略体现在用不同的进程打开不同的网站,让恶意网站很难影响其他网站乃至操作系统。这种沙箱同样也应用于插件和扩展,比如把PDF渲染进程独立出来。

绕开沙箱能够得逞,通常是因为编译后的代码种类庞杂,而且攻击者企图破坏整个进程。这种情况下沙箱有效性的标志就是它能否通过检验,即能否阻止被破坏的执行路径取得全部进程的权限。

2. IFrame沙箱

作为一种机制,可以使用IFrame显示来自不同来源不被信任的内容,有时候也可以用于显示来自相同来源但不被信任的内容。比如,Facebook的社交媒体部件13就是一个例子。利用IFrame干坏事并不新鲜,浏览器厂商很长时间以来一直致力于设置各种防范措施,降低这个家伙对浏览器造成的威胁。

13Facebook. (2013). Getting Started for Websites - Facebook developers. Retrieved December 15, 2013 from https://developers.facebook.com/docs/guides/web/

HTML5规范也提出了一个IFrame沙箱建议,而且已经被现代浏览器支持。开发者对它只有最低限度的权限。沙箱IFrame指的是给这个嵌入的帧添加一个HTML5属性。

添加这个属性后,就不能在其中使用表单、执行脚本,也不能导航到顶层页面,而且只能限于与一个来源通信。施加于每一个父框架的限制,都会被嵌在其中的子框架自动继承。

1.3.4 反网络钓鱼和反恶意软件

通过伪造在线内容(包括电子邮件)窃取证书等个人信息的行为,一般称为网络钓鱼(phishing)。很多组织都会公布钓鱼网站的信息,而现代浏览器可以利用这些信息。

浏览器会在访问网站时,将其与恶意站点名单进行对照。如果检测到要访问的网站是一个钓鱼网站,浏览器就会采取措施。相关内容将在第2章介绍。

类似地,服务器也可能在所有者未察觉的情况下被利用,或者有人专门运行这种服务器,托管着一些利用浏览器的隐患内容。这些网站会诱惑用户手工下载和执行软件,从而绕过浏览器防御措施。

关于托管有恶意代码的恶意网站,有很多组织都提供了相应的黑名单。浏览器可以直接引用,以便实时检测14

14StopBadware. (2013). Firefox Website Warning | StopBadware. Retrieved December 15, 2013 from https://www.stopbadware.org/firefox

1.3.5 混入内容

所谓混入内容(mixed content)网站,是指某个来源使用HTTPS协议,然后又通过HTTP请求内容。换句话说,所有页面内容都不是通过HTTPS发送的。

不通过HTTPS传输的内容有可能被修改,使得任何加密数据的措施形同虚设。如果通过未加密的通道传输的是脚本,那么攻击者就可能在数据流中注入指令,进而破坏浏览器与服务器间的交互。

1.4 核心安全问题

浏览器安全特性的一度扩张,奠定了如今既广阔又复杂的局面。传统网络安全一般依赖外围或边界防御设施的部署与维护,比如防火墙。随着时间推移,这些设备似乎要把除了基本流量之外的一切都过滤掉。

对网络的管控虽然越来越严密,但访问信息的需求一点没有减少,投入实际使用的Web技术(相当多流量走的都是80或443端口)也越来越多。实际上,防火墙非常有效地起到了限流的作用,而只给我们剩下了HTTP流量。日益增多的SSL VPN技术取代过去的IPSEC VPN的应用就是一个很好的例子。

当然,防火墙所做的就是把所有网络流量都归总到两个端口上:80和443。这样的流量迁移极大依赖于浏览器的安全模型。

接下来我们讨论一下浏览器安全的基本情况,以及攻防之中的有利和不利因素构成的复杂局面。特别地,我们会专注于为什么Web流量没有被限制住,反而为各种攻击提供了可能性。

1.4.1 攻击面

攻击面(attack surface)不是个新概念,它指的是浏览器容易遭受未信任来源攻击影响的范围。这样说来,最小的情况下,浏览器的渲染引擎就是问题所在。浏览器的攻击面是越来越大了,毕竟大量的API和各种存取数据的抽象功能也在与日俱增。

相反,网络的攻击面很大程度上已经受到了严密控制。接入点和受控流量的概念已经深入人心,而改变控制流程,结果就会不一样。比如,访问防火墙不同端口流量可以通过人们熟悉的方法得到轻易验证和限制。

很少听说浏览器厂商会删减浏览器功能的,倒是经常会听到宣传说某某浏览器又增加了什么功能之类的。与多数产品一样,削弱功能的同时还要维护向后兼容并没有什么可以预见的好处。而随着功能不断增多,攻击面势必也越来越大。

现代浏览器的更新都采用后台自动和静默方式。有时候,攻击面的变化是防御者意识不到的。某些情况下,这是一个好现象。可是,对一个成熟和可靠的安全团队而言,这样往往会造成更多麻烦,而不是带来更多好处。

然而,也很少有哪个组织,其安全团队成员敢说自己在浏览器防御方面非常有经验。即使这个软件是最值得信任的软件之一,它也仍然对互联网暴露着自己最大的攻击面。

1. 升级速度

浏览器安全团队不一定会与组织的步调一致。更常见的情况是,希望维持自己安全形象的厂商却无力修复浏览器的问题。

修复浏览器的安全bug常常被开发者排在最低优先级,这与安全社区的期望恰恰相反。2013年1月,随着Firefox 18.0的发布,Mozilla吹嘘15自己修复了一个混入内容的问题,也就是说,使浏览器在来源使用HTTPS协议时,不能加载HTTP内容。如果我告诉你Firefox的这个bug早在2000年12月就被人发现了16,你会作何感想?也许这是一个极端的例子,但浏览器安全bug被漠视的情况由此可见一斑。

15Mozilla. (2013). Firefox Notes - Desktop. Retrieved December 15, 2013 from http://www.mozilla.org/en-US/firefox/18.0/releasenotes/

16Mozilla. (2013). 62178 - implement mechanism to prevent sending insecure requests from a secure context. Retrieved December 15, 2013 from https://bugzilla.mozilla.org/show_bug.cgi?id=62178

从终端用户对浏览器安全升级没有发言权这一点来说,浏览器与其他软件也没有什么差别。可是,任何组织也不可能因为浏览器有安全问题,就宣传停止所有浏览器的使用,就地等候一个重要的安全补丁发布。这么说来,从浏览器安全bug被爆出之日起到这个bug被修复的这段时间内,大多数组织的浏览器都处于容易被攻击的状态。

2. 静默更新

静默的后台更新,虽然会增大受攻击的可能性,但应该说也能给用户带来很大的价值。为保证可用更新的快速应用,一些开发人员也开始实现自己的静默机制。

比如,谷歌就给自己的Chrome浏览器实现了一个静默更新功能17。用户无权禁用这个功能,以此保证及时提供所有更新,而不会被用户阻断。

17Thomas Duebendorfer and Stefan Frei. (2009). Why Silent Updates Boost Security. Retrieved December 15, 2013 from http://research.google.com/pubs/pub35246.html

这方面一个明显的例子,就是谷歌在Chrome中部署自己的PDF渲染引擎取代Adobe Reader。这确保了每个自动更新的Chrome都不再受制于这个第三方插件的更新进程。

这里面的确有问题。如果浏览器在后台更新和新增功能时出现问题,就可能增大每个浏览器的攻击面。这样所有组织的安全团队都不得不在某种程度上依赖浏览器的开发者,而在浏览器开发者对终端用户组织的需求还不够关注的情况下,这种依赖着实令人懊恼。

3. 扩展

扩展可以增强浏览器功能,而又不需要单独开发一款软件。但扩展可以影响浏览器加载的每一个页面,反过来,每个页面又会影响扩展。

每个扩展都可能成为攻击者的目标,因而它们会增大浏览器的攻击面。有时候,常见的XSS隐患也会通过扩展进入浏览器。关于扩展及其隐患,将在第7章讨论。

4. 插件

一般来说,插件就是能够独立于浏览器运行的软件。与扩展不同,浏览器只会在Web应用通过对象标签或Content-type首部包含它们的情况下,才会运行插件。

有些互联网功能离不开合适的插件,这也是浏览器支持增强插件功能的原因。比如,浏览器在访问Juniper等VPN网关时,就要使用Java小程序。

很多公司的业务都依赖于一批主流的浏览器插件,而有些插件以往就暴露出了一些隐患。在这种情况下,防御者要么选择使用包含隐患的插件,要么选择停办一些公司业务。

大部分插件都没有集中更新的机制。这意味着在某些情况下必须手工确保它们的使用安全,从而给防御带来了不可避免的负担和复杂性。

很多安全媒体都对插件给予负面的评价。由于一些固有的隐患,安全专家甚至建议组织清除所有这些插件。操作系统厂商也在采取措施,通过自己的自动更新机制禁用不安全的插件,禁用时间为不确定,或者至安全警报解除为止。

插件会大幅度增加攻击面。它们既能增强浏览器功能,又为黑客提供了攻击目标。第8章将深入探讨插件。

1.4.2 放弃控制

浏览器从互联网上的任意地点请求指令,其主要功能是把内容呈现于屏幕之上,为用户与内容交互提供界面,而且会严格按照作者设计的方式呈现。作为这个核心功能的实施结果,浏览器必须将很大一部分控制权让渡给服务器。浏览器必须执行收到的命令,否则就有可能无法正确渲染页面。对现代的Web应用而言,页面中包含大量其他来源的脚本和资源是很正常的。如果要正常显示页面,这些资源也必须正确处理和运行。

以前,浏览器接收到的指令很简单,类似于“把文本放在这儿,把图片放在这儿”。而现代Web应用和浏览器可能会发出类似这样的请求:“我要打开你的麦克风,然后异步把数据发送给那边的服务器。”

这种带有攻击性的功能随时会引发一个问题:是否能保证所有用户只浏览非恶意网站。答案是:几乎在任何情况下都不可能!浏览器不安全以及容易受攻击,正是因为无法实时保证来自远程服务器的内容神圣不可侵犯。

1.4.3 TCP协议控制

服务器—客户端模型并没有提供太多灵活性,比如使用哪个端口与客户端通信,客户端可以使用哪个IP地址交换数据。

这对攻击者来说是非常有用的,因为对他们而言,几乎可以不受限制地攻击HTTP协议或特定系统。再加上其他相关因素,就可能构成不同的攻击。第10章将讨论协议内攻击。

1.4.4 加密通信

为了保证加密信息的完整性和机密性,可以使用SSL和TLS与受信任的组织通信,而同样的技术也可以用于与攻击者进行安全的通信。

浏览器与服务器间加密通信的目标,是保护通信双方传输的数据安全。这就给防御者带来了问题,因为他们没有机会检查到恶意数据。浏览器支持的加密通信可以为攻击者所用,让他们私藏恶意指令,并且安全地转移战利品。

1.4.5 同源策略

SOP在不同浏览器技术中具有不一致的应用方式,恐怕是最令人迷惑的一个概念了。如前所述,SOP的用意是在浏览器中隔离资源,以防同一浏览器中来自不同来源之间的资源纠缠不清。本质上说,这也是一个沙箱。

这个特殊的沙箱是浏览器安全的重要保障机制。考虑到在网络活动中的首要地位,浏览器实际上是连接互联网上不同资源区域的事实标准,因此也应该承担着维护和平的使命。为满足每个区域的需求,准许访问不同来源的自治功能相应泛滥。如果这些功能违背SOP,那么本来合法的功能就可能成为敌人,因为它们会穿越安全区。

理解SOP,不能仅仅满足于它在浏览器中的实现。SOP的实现在不同浏览器、不同浏览器版本,以及它们的插件中,往往有很大差别。第4章将深入探讨SOP的各种实现方式,以及绕过其限制的花样繁多的方式。这些方式得益于Java、Adobe Reader、Silverlight及各种浏览器实现中的不同手法。

1.4.6 谬论

以往很多有用的经验之谈在当前全球浏览器面临威胁的大背景下已经不适用了。下面这些错误的说法很容易把人拖入泥潭。遗憾的是,其中不少说法至今还在很多善意的人群中大行其道。

1. 健壮性法则谬论

所谓健壮性法则18,也叫伯斯塔尔法则(Postel's Law),告诫程序员“发送时要保守,接收时要开放”。这句话在安全实践中站不住脚。

18Andrew Gregory. (2008). Andrew Gregory - The Myth of the Robustness Principle. Retrieved December 15, 2013 from http://my.opera.com/AndrewGregoryScss/blog/2008/05/27/the-myth-of-the-robustness-principle http://my.opera.com/Andrew%20Gregory/blog/2008/05/27/the-myth-of-the-robustness-principle

浏览器对自己要渲染的内容是极其开放的。这也是XSS为何难以根除的原因。浏览器给开发安全过滤器和编码器带来了困难,因为它允许以各种方式执行指令。

为了鼓励开发人员遵循安全编码规范,健壮性法则应该修正为“发送时要保守,接收时要更加保守”。如果下一代开发人员都潜移默化地接受这个观念,那黑客的好日子就要到头了!

2. 外围安全防线谬论

很多组织都喜欢把自己的安全领域想象成一个城堡外加护城河。他们会想象着用几道高墙防御外部攻击,保护自己的重要资产。这种假设的前提是洋葱皮似的层层包围的防护机制是最安全的,可惜这个前提并不成立,因为复杂的网络不是中世纪的欧洲!

这种防御观的问题在于,它假设攻击者会由外而内一层一层攻破防线。这种假设背离现实的程度之大,就像好莱坞大片背离真正的历史一样。

一个组织的内部网是一个经常要与攻击者玩打地鼠游戏的地方。现实情况是,浏览器提供了很多洞洞,就像直接在高高的围墙上面打开了很多口子。

防护围墙因此会被间接攻破,难以阻拦浏览器带到围墙内的敌人。防御资源应该投放给封装重要资源的微安全防线(Micro Security Perimeter)。今天的网络防御必须针对设备,无论敌友,防患未然。

现实中,安全资源总是有限的,而正是这些有限的资源却要用于守护最有价值的资产。

1.5 浏览器攻防方法

本章到此,希望读者已经了解了浏览器所面临挑战的复杂性。保证Web安全不容易,其中很多精力都要花在浏览器上面。浏览器是一道重要的阻击线。

在一个假想的末日后的高科技世界里,每一个站点都失陷成为恶意站点,而理想的浏览器在这种情况下应该依然能保证你的计算机安全。而要达到这个安全乌托邦,我们仍然任重道远。

接下来该解释一下浏览器攻防的含义了。我们可以把这个过程分解为几个阶段,而不只满足于消除现有弱点或者苟延残喘。为此,我们找到了一套方法,希望能够保证现有地带的持久安全。

下面我们就介绍这个方法,以及相关手段适用的情形,如图1-1所示,其中包含一个攻防流程和相应的路径。

图 1-1 本书的攻防方法

这套方法的目标是涵盖浏览器攻防的各个方面,而本书也完全按照这套方法的主要阶段组织各章内容。每一章围绕一个阶段深入阐述相关的技术细节。一章一章地往后看,你会逐步加深对这套方法的理解。

对某些目标而言,这套方法中给出的路径可能比较简单,因为有很多免费安全工具可以自动完成相应过程。但另外一些情况下,可能就要具体问题具体分析了。

浏览器攻防方法由三部分构成,在图1-1中用三个大的虚线框表示。这样从最高层面来说,整个攻击过程就分三个阶段,首先是初始化,然后是持久化,最后是攻击。

第一个阶段是初始化,是整个过程的第一步。然后是持久化,考验你对浏览器的理解。这一步要在目标浏览器或浏览器所在设备上筑起防御工事,也是浏览器陷落的初始阶段。

真正的挑战来自于下一阶段。攻击阶段包含七大攻击方法,下面会简单介绍,余下几章会分别详细介绍。在介绍不同的方法时,我们会展示浏览器不同的侧面和可以利用的弱点。其中一些攻击技术的运用可能会在其他浏览器中表现为初始化阶段,从而导致攻击的循环,以及受害范围扩大。

1.5.1 初始化

初始化只有一个阶段。这个看似无关痛痒的阶段却是浏览器攻防中第一个阶段,也是最为紧要的阶段。没有这个阶段,任何攻击都不可能发生,目标浏览器也不会进入攻击者的视野。

初始控制

每次攻击都以在浏览器中运行指令为开端。为此,浏览器必须遇到(并执行)你控制的指令。

这是第2章的主题,里面会讨论一些方法,给浏览器布下陷阱,诱使、欺骗或者强迫浏览器遇到你的指令,然后更重要的是执行任意代码。

1.5.2 持久化

成功初始化攻击后,怎么扩大你对目标的控制范围?你要保持对浏览器的控制,而且要能够发动进一步攻击。

持久化控制

听说过一个精灵和三个愿望的故事吗?就是你遇到一个精灵,它会答应你三个愿望。狡黠的人会对精灵说出自己的愿望,而且最后一个愿望是希望能许下更多愿望。这对精灵来说,不啻为一个压力测试啊!

再说回与被害浏览器保持通信吧。你的初始代码要让浏览器不断向你询问下一个愿望。你在纠缠阶段放出精灵,控制住浏览器让它不断答应你的愿望。

就像精灵会在一阵烟雾中消失一样,这种状态也可能不会永远维持。想要不断地许愿,还得看用户后续的操作。用户可能会一下子关闭发动攻击的标签页,或者又用它打开了另一个网站。这样的话,JavaScript就会被清除,通信渠道也就关闭了。

在得意忘形地想要发动下一次攻击之前,明智的做法是耐心等待,而不是对浏览器过分施加影响。这个阶段,你要尽量降低失去浏览器控制权的可能,不让用户切换网址,或者关闭浏览器。

实现持续控制的目标也分几个不同的层面。最重要的是要有耐心,尽可能完全地利用这个阶段,为下一个阶段做好准备。这是因为你控制浏览器的时候越长,追究出来的攻击面就越广,你的攻击就越具有可控性。

还要注意的是,有时候在发起后续攻击期间,成功的攻击会揭示出巩固阵地的方法,从而提升控制水平。正因为如此,图1-1中这两个阶段之间才画了一个双向箭头。经验会告诉你什么时候应该巩固控制渠道而非发起攻击,什么时候发起攻击有助于控制渠道的灵活性和持久性。

1.5.3 攻击

在这个阶段,就要利用对浏览器的控制,以当前情势为基础,探索攻击的可能性。攻击形式有很多,包括对浏览器的“本地”攻击,对浏览器所在操作系统的攻击,以及对任意位置的远程系统的攻击。

细心的读者可能会发现,在这一阶段的方法中,绕过同源策略处于首位,而且高高在上。这是为什么呢?因为这个方法在攻击的每一步都用得着,是其他攻击阶段必须绕过和利用的安全措施。

另一个同样比较明显的地方就是攻击方法中心位置的循环箭头。倒不是说一定会循环起来,重要的是其中一个环节的成功攻击,很可能成为另一个环节成功攻击的先兆。从这个意义上说,这个阶段应该经常权衡利弊,什么方法最有效,回报最丰厚,就采用什么方法。

这里给出了七种可以对浏览器发起的核心攻击方法。至于到底应该采取哪种方法,要根据很多因素来决定。最主要的有渗透的范围、期望的目标以及被害浏览器的能力。

1. 绕过同源策略

可以把SOP看成浏览器的一个重要沙箱。如果你能绕过它,那只要访问之前被浏览器封死的另一个来源,即可自动地成功实现攻击。绕过SOP,就可以使用后续一系列可用的攻击方法对新出现的来源进行攻击。

关于SOP的深入解释将在第4章进行。只要你绕过它,就可以进行多种攻击,又不会发生干扰。第4章将介绍一些矛盾点,以及如何利用浏览器基本安全组件中的这些漏洞。

2. 攻击用户

浏览器黑客方法中的第一个选项是攻击用户,具体将在第5章讨论。这一章涵盖涉及浏览器用户的攻击技术,以及他们对攻击者所控制环境的潜在信任。

使用浏览器提供的手段,以及你控制页面的能力,可以创造一个受控的环境,让用户输入敏感信息,以便捕获和利用。

可以给用户布下陷阱,让他们在不知不觉中让渡权限,并触发其他操作,比如运行任意程序或者授权访问本地资源。可以生成隐藏的对话框和透明的框架,或者控制鼠标事件以辅助实现以上目的,向用户展示一个假象以掩盖用户界面的真实功能。

3. 攻击浏览器

攻击浏览器就是直接攻击浏览器的核心。第6章会带你探索指纹方法和全面利用。

浏览器是一个巨大的攻击面,它有着众多API和各种存储和取得数据的抽象机制。毫不奇怪,浏览器很多年来一直被自身这样或那样的隐患所困扰。更加令人惊讶的是,浏览器开发人员每次解决问题都做得不赖。

4. 攻击扩展

如果你攻击核心浏览器失败了,那就等于正门关闭了。此时,可以考虑攻击它所安装的外部程序(可能会很多)。

相关内容会在第7章介绍,主题就是攻击扩展。这一章将讨论扩展变体及特殊扩展实现。

你会看到很多种扩展的隐患,利用这些隐患,可以实现跨域请求,甚至执行操作命令。

5. 攻击插件

插件一直是浏览器隐患多发区。插件与扩展不同,它属于第三方组件,由它服务的网页独立初始化(而非一直整合到浏览器中)。

攻击插件的方法将在第8章介绍,包括攻击Java和Flash等普遍存在的插件。相关内容还有如何检测浏览器安装了哪些插件,了解该领域的研究者已经发现了哪些可以利用的弱点,以及哪些旨在保护插件安全的手段被滥用因而可以绕过,等等。

6. 攻击Web应用

浏览器就是为了使用Web而生的,因此攻击Web应用就是自然而然的了。这个话题包括使用浏览器的标准功能攻击Web应用,将在第9章详细介绍。

想象一下,很多组织的内部网都可以访问大量应用。如果另一个标签页中的外部网站能访问这些内部应用会怎么样?你会发现受到防火墙保护的内部应用在外部攻击面前居然形同虚设。

7. 攻击网络

你会发现居然有浏览器连接到了非标准的端口,而且这种情况相当普遍。很多服务器安装的应用都随意指定端口,而互联网上的有些网站甚至不使用80和443端口发布内容。

如果浏览器根本没有连接服务器怎么办呢?如果浏览器连接到了一个目的完全不同而且还使用了完全不同协议的服务呢?这种情况不会违反SOP,而且在多数情况下,从浏览器安全控件角度看都是合法的。改变这些浏览器的行为可以达到深度攻击的目的。

攻击网络的方法会涉及OSI网络模型的底层。第10章将讲解这些技术,一视同仁地将它们应用到攻击任意TCP/IP网络。

1.6 小结

毫无疑问,浏览器是21世纪这十多年来最重要的一种软件。软件厂商很少为自己的应用开发定制的客户端软件,更多的是使用Web技术开发一个应用界面:不仅仅是传统的在线Web应用,还包含部署在局域网内的本地应用。在服务器-客户端模型中,浏览器占据着不可动摇的统治地位。

浏览器在几乎所有类型的网络应用中都有一席之地,虽然很多组织试图禁用它,但这个愿望只是个泡影。任何组织都不可能放弃浏览器,唯一的选择是在自己的网络中使用它。

黑客攻击浏览器通常会伪装成非恶意的服务器,向浏览器发送有效的通信请求。多数情况下,浏览器不会知晓自己正与一个骗子服务器通信,因此就会执行骗子服务器发来的所有指令,而且还以为自己在防火墙的保护下万无一失呢。

接下来的几章将重点介绍浏览器攻防的方法,教给大家如何利用浏览器及其可以访问的设备。

1.7 问题

(1) 浏览器中的DOM都有哪些功能?

(2) 为什么说一个安全的浏览器抵得过全副武装的安全措施?

(3) 说说JavaScript和VBScript有哪些不同。

(4) 说出服务器可能降低浏览器安全性的三种方式。

(5) 什么是浏览器的攻击面?

(6) 描述一下你理解的沙箱。

(7) 浏览器在使用HTTPS通信时,代理可以看到通信内容吗?

(8) 说出三个与安全相关的HTTP首部。

(9) 为什么安全专家不认可健壮性法则?

(10) 只有IE有,而其他现代浏览器没有的脚本语言是什么?

要查看问题答案,请访问本书网站https://browserhacker.com/answers,或者Wiley的网站http://www.wiley.com/go/browserhackershandbook

目录