Web之困：现代Web应用安全指南

内容简介

《Web之困：现代Web应用安全指南》在Web安全领域有“圣经”的美誉，在世界范围内被安全工作者和Web从业人员广为称道，由来自Google
Chrome浏览器团队的世界黑客、安全专家撰写，是目前深度探索现代Web浏览器安全技术的专著。本书从浏览器设计的角度切入，以探讨浏览器的各主要特性和由此衍生出来的各种安全相关问题为主线，深入剖析了现代Web浏览器的技术原理、安全机制和设计上的安全缺陷，为Web安全工作者和开发工程师们应对各种基于浏览器的安全隐患提供了应对措施。
　　《Web之困：现代Web应用安全指南》开篇回顾了Web的发展历程和安全风险的演化；第一部分解剖了现代浏览器的工作原理，包括URL、HTTP协议、HTML语言、CSS、文档格式、浏览器插件等内容；第二部分从浏览器的设计角度深入分析了各种现代Web浏览器（Firefox、Chrome、IE等）所引入的重点安全机制，例如同源策略、源的继承、窗口和框架的交互、安全边界、内容识别、应对恶意脚本、外围的网站特权等，并分析了这些机制存在的安全缺陷，同时为Web应用开发者提供了如何避免攻击和隐私泄露的应对措施；第三部分对浏览器安全机制的未来趋势进行了展望，包括新的浏览器特性与安全展望、其他值得注意的浏览器、常见的Web安全漏洞等。

目录

译者序
前　言
第1章　Web应用安全
1.1　信息安全速览
1.1.1　正统之道的尴尬
1.1.2　进入风险管理
1.1.3　分类学的启发
1.1.4　实际的解决之道
1.2　Web的简明历史
1.2.1　史前时期的故事： 1945～1994年
1.2.2　第一次浏览器大战：1995～1999年
1.2.3　平淡期：2000～2003年
1.2.4　Web 2.0 和第二次浏览器大战：2004年之后
1.3　风险的演化
1.3.1　用户作为安全风险的一个环节
1.3.2　难以隔离的Web运行环境
1.3.3　缺乏统一的格局
1.3.4　跨浏览器交互：失败的协同
1.3.5　客户端和服务器端界限的日益模糊
第一部分　对Web的解剖分析
第2章　一切从URL开始
2.1　URL的结构
2.1.1　协议名称
2.1.2　层级URL的标记符号
2.1.3　访问资源的身份验证
2.1.4　服务器地址
2.1.5　服务器端口
2.1.6　层级的文件路径
2.1.7　查询字符串
2.1.8　片段ID
2.1.9　把所有的东西整合起来
2.2　保留字符和百分号编码
2.3　常见的 URL协议及功能
2.3.1　浏览器本身支持、与获取文档相关的协议
2.3.2　由第三方应用和插件支持的协议
2.3.3　未封装的伪协议
2.3.4　封装过的伪协议
2.3.5　关于协议检测部分的结语
2.4　相对URL的解析
2.5　安全工程速查表
第3章　HTTP协议
3.1　HTTP 基本语法
3.1.1　支持HTTP0.9的恶果
3.1.2　换行处理带来的各种混乱
3.1.3　经过代理的HTTP请求
3.1.4　对重复或有冲突的头域的解析
3.1.5　以分号作分隔符的头域值
3.1.6　头域里的字符集和编码策略
3.1.7　Referer头域的表现
3.2　HTTP 请求类型
3.2.1　GET
3.2.2　POST
3.2.3　HEAD
3.2.4　OPTIONS
3.2.5　PUT
3.2.6　DELETE
3.2.7　TRACE
3.2.8　CONNECT
3.2.9　其他 HTTP 方法
3.3　服务器响应代码
3.4　持续会话
3.5　分段数据传输
3.6　缓存机制
3.7　HTTP cookie 语义
3.8　HTTP 认证
3.9　协议级别的加密和客户端证书
3.9.1　扩展验证型证书
3.9.2　出错处理的规则
3.10　安全工程速查表
第4章　HTML语言
4.1　HTML文档背后的基本概念
4.1.1　文档解析模式
4.1.2　语义之争
4.2　理解HTML解析器的行为
4.2.1　多重标签之间的交互
4.2.2　显式和隐式的条件判断
4.2.3　HTML解析的生存建议
4.3　HTML实体编码
4.4　HTTPHTML 交互语义
4.5　超链接和内容包含
4.5.1　单纯的链接
4.5.2　表单和表单触发的请求
4.5.3　框架
4.5.4　特定类型的内容包含
4.5.5　关于跨站请求伪造
4.6　安全工程速查表
第5章　层叠样式表
5.1　CSS基本语法
5.1.1　属性定义
5.1.2　@ 指令和XBL绑定
5.1.3　与HTML的交互
5.2　重新同步的风险
5.3　字符编码
5.4　安全工程速查表
第6章　浏览器端脚本
6.1　Javascript的基本特点
6.1.1　脚本处理模型
6.1.2　执行顺序的控制
6.1.3　代码和对象检视功能
6.1.4　修改运行环境
6.1.5　Javascript 对象表示法（JSON）和其他数据序列化
6.1.6　E4X和其他语法扩展
6.2　标准对象层级
6.2.1　文档对象模型
6.2.2　对其他文档的访问
6.3　脚本字符编码
6.4　代码包含模式和嵌入风险
6.5　活死人：Visual Basic
6.6　安全工程速查表
第7章　非HTML类型文档
7.1　纯文本文件
7.2　位图图片
7.3　音频与视频
7.4　各种XML文件
7.4.1　常规XML视图效果
7.4.2　可缩放向量图片
7.4.3　数学标记语言
7.4.4　XML

摘要与插图

第1章
　　Web应用安全
　　为了给本书后面的技术讨论提供必要的背景知识，我们先解释清楚安全领域涵盖哪些方面，以及为什么在这个早已被研究得很透彻的领域里，Web应用的安全仍然值得引起额外的关注。那么，让我们开始吧？
　　1.1　信息安全速览
　　表面上看来，信息安全领域属于计算机科学里很成熟、明确且硕果累累的一个分支，自以为无所不知的专家们通过展现他们那分类清晰、数量庞大的安全漏洞集来标榜这一领域的重要性。至于那些漏洞的责任嘛，就全都归到那些“安全文盲”的程序员们头上好了，而理论家们则会从旁指点，说只要遵从今年门的某某安全方法学，早就能把这些问题都防患于未然了云云。安全问题更是带动了一个产业的繁荣，但对用户来讲，从普通计算机用户到庞大的公司等，其实并没有带来什么有效的安全保障。
　　从根本上来说，过去几十年，我们甚至没能构建出一个哪怕原始但至少还算可用的框架来理解和评估现代软件的安全性。除了几篇出色的论文和一些小范围内取得的经验，甚至无法拿出什么有说服力的真实的成功案例。现在的侧重点几乎都放在一些响应性质的、次要的安全方法上（如漏洞管理、恶意软件和攻击的检测、沙盒技术以及其他），要不就是常常对别人代码里的漏洞指指点点。一个令人不安而又秘而不宣的实情是：如果安全系统是由别人开发的，那我们贡献的价值实际上往往乏善可陈；在现代Web这件事情上则更是如此。
　　让我们来看看以下几种目的信息安全之道，并尝试分析一下为什么到目前为止，它们也没能走出这一困境。
　　1.1.1　正统之道的尴尬
　　也许开发一个安全程序接的途径就是从算法上证明该程序的运行是正确的。从直觉来说，这个简单的假设听起来还蛮有道理的那为什么此路不通呢？
　　先让我们讨论一下作为形容词时“安全”这两字的含义。准确来说，它到底是什么意思呢？安全（Security）听起来很直观，但在计算机领域，就愣是没法给它下一个确切的定义。没错，我们可以用一些很眩目但基本没啥意义的方式来描述安全，例如，在业界经常被引用的一个关于安全的定义如下，但实际上它也是有问题的：
　　如果系统能按既定的方式完成任务，不做额外的事情，那这套系统就是安全的。
　　这个定义很简洁，也大致描述了一个抽象的目标，但它几乎没提到要怎么做才能达成这个目标。虽然这句话的主题是关于计算机科学的，但其笼统程度，和维克多雨果的一句诗倒有异曲同工之妙：
　　爱情乃灵魂之一部分，就恍如仙气弥漫于天堂一般。
　　也许有人会反对说，这个棘手的定义不应该求诸于商业界，那好，我们只管把这个问题抛给学术界吧，但他们也只会给出一个差不多的答案。例如，下面这个常见的学术界对安全的定义，它出自20世纪60年代出版的贝尔拉帕杜拉安全模型（Bell-La
Padula security
model，这套规范是企图规范化安全系统需求的诸多努力之一，这是一套针对国家机器的规范1；当然也是名的一套规范。）
　　当且仅当系统开始于安全的状态，而且一直不会落入非安全状态，它才是安全的。
　　当然，像这些定义安全的文字从根本上来说都是正确的，用于论文的基调甚至政府规范都毫无问题。但实际上，对真实世界里的软件工程而言，由于以下三个原因，以这些理论为基础建立的模型几乎是没用的。
　　对一个足够复杂的计算机系统来说，没有办法定义什么是正确的行为。对一个操作系统或者Web浏览器来说，没有一个机构能定义什么是“应该的方式”或者“安全的状态”。用户、系统所有者、数据提供者、业务流程所有者和软件硬件开发商之间的利益是南辕北辙，并且