新書推薦：
《
麦肯锡原则：成就全球顶级公司的11条经验 （美） 达夫·麦克唐纳
》
售價：NT$
498.0
《
今日宜偏爱（全二册）
》
售價：NT$
447.0
《
氢经济
》
售價：NT$
549.0
《
从中国出发的全球史
》
售價：NT$
2229.0
《
为你沦陷
》
售價：NT$
262.0
《
校园欺凌
》
售價：NT$
279.0
《
培训需求分析与年度计划制订——基于组织战略，做”对的”培训！
》
售價：NT$
386.0
《
这就是心理咨询：全球心理咨询师都在用的45项技术（第3版）
》
售價：NT$
717.0
|
| 編輯推薦： |
《Web之困：现代Web应用安全指南》Web安全领域圣经级著作，唯一深度探索现代Web浏览器安全技术的专著，由来自Google
Chrome浏览器团队的世界顶级黑客、国际一流安全专家撰写。
从浏览器设计角度深入剖析现代浏览器的技术原理、安全机制和设计上的安全缺陷，为Web安全工作者应对基于浏览器的各种安全隐患提供应对措施。
|
| 內容簡介： |
本书在Web安全领域有“圣经”的美誉，在世界范围内被安全工作者和Web从业人员广为称道，由来自Google
Chrome浏览器团队的世界顶级黑客、国际一流安全专家撰写，是目前唯一深度探索现代Web浏览器安全技术的专著。本书从浏览器设计的角度切入，以探讨浏览器的各主要特性和由此衍生出来的各种安全相关问题为主线，深入剖析了现代Web浏览器的技术原理、安全机制和设计上的安全缺陷，为Web安全工作者和开发工程师们应对各种基于浏览器的安全隐患提供了应对措施。
本书开篇回顾了Web的发展历程和安全风险的演化；第一部分解剖了现代浏览器的工作原理，包括URL、HTTP协议、HTML语言、CSS、文档格式、浏览器插件等内容；第二部分从浏览器的设计角度深入分析了各种现代Web浏览器（Firefox、Chrome、IE等）所引入的重点安全机制，例如同源策略、源的继承、窗口和框架的交互、安全边界、内容识别、应对恶意脚本、外围的网站特权等，并分析了这些机制存在的安全缺陷，同时为Web应用开发者提供了如何避免攻击和隐私泄露的应对措施；第三部分对浏览器安全机制的未来趋势进行了展望，包括新的浏览器特性与安全展望、其他值得注意的浏览器、常见的Web安全漏洞等。
|
| 關於作者： |
Michal Zalewski
国际一流信息安全技术专家，被誉为IT安全领域最有影响力的11位黑客之一。曾发现过数以百计的网络安全漏洞，并发表了多篇具有重大影响的研究论文。对现代Web浏览器有非常深入的研究，目前就职于Google，基于其在Web安全方面的丰富经验帮助Google增强包括Chrome浏览器在内的一系列产品的安全性。此外，他还是一位开源软件贡献者，是著名开源软件p0f、skipfish、ratproxy等的开发者。
译者简介
朱筱丹
毕业于华南理工大学无线电系，某信息安全公司工程师。在安全技术领域摸爬滚打多年，热爱读书与美食。
审校者简介
殷钧钧
资深安全架构师，知名白帽子，Web开发者
|
| 目錄：
|
译者序
前 言
第1章 Web应用安全 1
1.1 信息安全速览 1
1.1.1 正统之道的尴尬 2
1.1.2 进入风险管理 4
1.1.3 分类学的启发 5
1.1.4 实际的解决之道 6
1.2 Web的简明历史 7
1.2.1 史前时期的故事： 1945～1994年 8
1.2.2 第一次浏览器大战：1995～1999年 10
1.2.3 平淡期：2000～2003年 11
1.2.4 Web 2.0 和第二次浏览器大战：2004年之后 12
1.3 风险的演化 13
1.3.1 用户作为安全风险的一个环节 14
1.3.2 难以隔离的Web运行环境 14
1.3.3 缺乏统一的格局 15
1.3.4 跨浏览器交互：失败的协同 16
1.3.5 客户端和服务器端界限的日益模糊 17
第一部分 对Web的解剖分析
第2章 一切从URL开始 20
2.1 URL的结构 21
2.1.1 协议名称 21
2.1.2 层级URL的标记符号 22
2.1.3 访问资源的身份验证 22
2.1.4 服务器地址 23
2.1.5 服务器端口 24
2.1.6 层级的文件路径 24
2.1.7 查询字符串 25
2.1.8 片段ID 25
2.1.9 把所有的东西整合起来 26
2.2 保留字符和百分号编码 28
2.3 常见的 URL协议及功能 33
2.3.1 浏览器本身支持、与获取文档相关的协议 33
2.3.2 由第三方应用和插件支持的协议 33
2.3.3 未封装的伪协议 34
2.3.4 封装过的伪协议 34
2.3.5 关于协议检测部分的结语 35
2.4 相对URL的解析 35
2.5 安全工程速查表 37
第3章 HTTP协议 38
3.1 HTTP 基本语法 39
3.1.1 支持HTTP0.9的恶果 40
3.1.2 换行处理带来的各种混乱 41
3.1.3 经过代理的HTTP请求 42
3.1.4 对重复或有冲突的头域的解析 44
3.1.5 以分号作分隔符的头域值 45
3.1.6 头域里的字符集和编码策略 46
3.1.7 Referer头域的表现 48
3.2 HTTP 请求类型 48
3.2.1 GET 49
3.2.2 POST 49
3.2.3 HEAD 49
3.2.4 OPTIONS 50
3.2.5 PUT 50
3.2.6 DELETE 50
3.2.7 TRACE 50
3.2.8 CONNECT 50
3.2.9 其他 HTTP 方法 51
3.3 服务器响应代码 51
3.4 持续会话 53
3.5 分段数据传输 55
3.6 缓存机制 55
3.7 HTTP Cookie 语义 57
3.8 HTTP 认证 60
3.9 协议级别的加密和客户端证书 61
3.9.1 扩展验证型证书 62
3.9.2 出错处理的规则 63
3.10 安全工程速查表 64
第4章 HTML语言 65
4.1 HTML文档背后的基本概念 66
4.1.1 文档解析模式 67
4.1.2 语义之争 68
4.2 理解HTML解析器的行为 69
4.2.1 多重标签之间的交互 70
4.2.2 显式和隐式的条件判断 71
4.2.3 HTML解析的生存建议 71
4.3 HTML实体编码 72
4.4 HTTPHTML 交互语义 73
4.5 超链接和内容包含 75
4.5.1 单纯的链接 75
4.5.2 表单和表单触发的请求 75
4.5.3 框架 77
4.5.4 特定类型的内容包含 78
4.5.5 关于跨站请求伪造 80
4.6 安全工程速查表 81
第5章 层叠样式表 83
5.1 CSS基本语法 84
5.1.1 属性定义 85
5.1.2 @ 指令和XBL绑定 85
5.1.3 与HTML的交互 86
5.2 重新同步的风险 86
5.3 字符编码 87
5.4 安全工程速查表 89
第6章 浏览器端脚本 90
6.1 JavaScript的基本特点 91
6.1.1 脚本处理模型 92
6.1.2 执行顺序的控制 95
6.1.3 代码和对象检视功能 96
6.1.4 修改运行环境 97
6.1.5 JavaScript 对象表示法（JSON）和其他数据序列化 99
6.1.6 E4X和其他语法扩展 101
6.2 标准对象层级 102
6.2.1 文档对象模型 104
6.2.2 对其他文档的访问 106
6.3 脚本字符编码 107
6.4 代码包含模式和嵌入风险 108
6.5 活死人：Visual Basic 109
6.6 安全工程速查表 110
第7章 非HTML类型文档 112
7.1 纯文本文件 112
7.2 位图图片 113
7.3 音频与视频 114
7.4 各种XML文件 114
7.4.1 常规XML视图效果 115
7.4.2 可缩放向量图片 116
7.4.3 数学标记语言 117
7.4.4 XML用户界面语言 117
7.4.5 无线标记语言 118
7.4.6 RSS 和 Atom订阅源 118
7.5 关于不可显示的文件类型 119
7.6 安全工程速查表 120
第8章 浏览器插件产生的内容 121
8.1 对插件的调用 122
8.2 文档显示帮助程序 124
8.3 插件的各种应用框架 125
8.3.1 Adobe Flash 126
8.3.2 Microsoft Silverlight 128
8.3.3 Sun Java 129
8.3.4 XML Browser Applications 129
8.4 ActiveX Controls 130
8.5 其他插件的情况 131
8.6 安全工程速查表 132
第二部分 浏览器安全特性
第9章 内容隔离逻辑 134
9.1 DOM的同源策略 135
9.1.1 document.domain 136
9.1.2 postMessage... 137
9.1.3 与浏览器身份验证的交互 138
9.2 XMLHttpRequest的同源策略 139
9.3 Web Storage 的同源策略 141
9.4 Cookies 的安全策略 142
9.4.1 Cookie对同源策略的影响 144
9.4.2 域名限制带来的问题 145
9.4.3 localhost带来的非一般风险 145
9.4.4 Cookie与“合法”DNS劫持 146
9.5 插件的安全规则 147
9.5.1 Adobe Flash 148
9.5.2 Microsoft Silverlight 151
9.5.3 Java 151
9.6 如何处理格式含糊或意想不到的源信息 152
9.6.1 IP 地址 153
9.6.2 主机名里有额外的点号 153
9.6.3 不完整的主机名 153
9.6.4 本地文件 154
9.6.5 伪URL 155
9.6.6 浏览器扩展和用户界面 155
9.7 源的其他应用 156
9.8 安全工程速查表 157
第10章 源的继承 158
10.1 about:blank页面的源继承 158
10.2 data: URL的继承 160
10.3 javascript:和vbscript: URL对源的继承 162
10.4 关于受限伪URL的一些补充 163
10.5 安全工程速查表 164
第11章 同源策略之外的世界 165
11.1 窗口和框架的交互 166
11.1.1 改变现有页面的地址 166
11.1.2 不请自来的框架 170
11.2 跨域内容包含 172
11.3 与隐私相关的副作用 175
11.4 其他的同源漏洞和应用 177
11.5 安全工程速查表 178
第12章 其他的安全边界 179
12.1 跳转到敏感协议 179
12.2 访问内部网络 180
12.3 禁用的端口 182
12.4 对第三方Cookie的限制 184
12.5 安全工程速查表 186
第13章 内容识别机制 187
13.1 文档类型检测的逻辑 188
13.1.1 格式错误的MIME Type写法 189
13.1.2 特殊的 Content-Type 值 189
13.1.3 无法识别的Content Type类型 191
13.1.4 防御性使用Content-Disposition 193
13.1.5 子资源的内容设置 194
13.1.6 文件下载和其他非HTTP内容 194
13.2 字符集处理 196
13.2.1 字节顺序标记 198
13.2.2 字符集继承和覆盖 199
13.2.3 通过HTML代码设置子资源字符集 199
13.2.4 非HTTP 文件的编码检测 201
13.3 安全工程速查表 202
第14章 应对恶意脚本 203
14.1 拒绝服务攻击 204
14.1.1 执行时间和内存使用的限制 205
14.1.2 连接限制 205
14.1.3 过滤弹出窗口 206
14.1.4 对话框的使用限制 208
14.2 窗口定位和外观问题 209
14.3 用户界面的时差攻击 211
14.4 安全工程速查表 214
第15章 外围的网站特权 215
15.1 浏览器和托管插件的站点权限 216
15.2 表单密码管理 217
15.3 IE浏览器的区域模型 219
15.4 安全工程速查表 222
第三部分 浏览器安全机制的未来趋势
第16章 新的浏览器安全特性与未来展望 224
16.1 安全模型扩展框架 224
16.1.1 跨域请求 225
16.1.2 XDomainRequest 228
16.1.3 Origin 请求头的其他应用 229
16.2 安全模型限制框架 230
16.2.1 内容安全策略 230
16.2.2 沙盒框架 234
16.2.3 严格传输安全 236
16.2.4 隐私浏览模式 237
16.3 其他的一些进展 237
16.3.1 浏览器内置的 HTML净化器 238
16.3.2 XSS 过滤 239
16.4 安全工程速查表 240
第17章 其他值得注意的浏览器机制 241
17.1 URL级别和协议级别的提议 241
17.2 内容相关的特性 243
17.3 IO接口 245
第18章 常见的Web安全漏洞 246
18.1 与Web应用相关的漏洞 246
18.2 Web应用设计时应谨记的问题 248
18.3 服务器端的常见问题 250
后记 252
注释 254
|
| 內容試閱：
|
第1章
Web应用安全
为了给本书后面的技术讨论提供必要的背景知识，我们首先解释清楚安全领域涵盖哪些方面，以及为什么在这个早已被研究得很透彻的领域里，Web应用的安全仍然值得引起额外的关注。那么，让我们开始吧？
1.1 信息安全速览
表面上看来，信息安全领域属于计算机科学里很成熟、明确且硕果累累的一个分支，自以为无所不知的专家们通过展现他们那分类清晰、数量庞大的安全漏洞集来标榜这一领域的重要性。至于那些漏洞的责任嘛，就全都归到那些“安全文盲”的程序员们头上好了，而理论家们则会从旁指点，说只要遵从今年最热门的某某安全方法学，早就能把这些问题都防患于未然了云云。安全问题更是带动了一个产业的繁荣，但对用户来讲，从普通计算机用户到庞大的国际公司等，其实并没有带来什么有效的安全保障。
从根本上来说，过去几十年，我们甚至没能构建出一个哪怕原始但至少还算可用的框架来理解和评估现代软件的安全性。除了几篇出色的论文和一些小范围内取得的经验，甚至无法拿出什么有说服力的真实的成功案例。现在的侧重点几乎都放在一些响应性质的、次要的安全方法上（如漏洞管理、恶意软件和攻击的检测、沙盒技术以及其他），要不就是常常对别人代码里的漏洞指指点点。一个令人不安而又秘而不宣的实情是：如果安全系统是由别人开发的，那我们贡献的价值实际上往往乏善可陈；在现代Web这件事情上则更是如此。
让我们来看看以下几种最瞩目的信息安全之道，并尝试分析一下为什么到目前为止，它们也没能走出这一困境。
1.1.1 正统之道的尴尬
也许开发一个安全程序最直接的途径就是从算法上证明该程序的运行是正确的。从直觉来说，这个简单的假设听起来还蛮有道理的—那为什么此路不通呢？
首先让我们讨论一下作为形容词时“安全”这两字的含义。准确来说，它到底是什么意思呢？安全（Security）听起来很直观，但在计算机领域，就愣是没法给它下一个确切的定义。没错，我们可以用一些很眩目但基本没啥意义的方式来描述安全，例如，在业界经常被引用的一个关于安全的定义如下，但实际上它也是有问题的：
如果系统能按既定的方式完成任务，不做额外的事情，那这套系统就是安全的。
这个定义很简洁，也大致描述了一个抽象的目标，但它几乎没提到要怎么做才能达成这个目标。虽然这句话的主题是关于计算机科学的，但其笼统程度，和维克多·雨果的一句诗倒有异曲同工之妙：
爱情乃灵魂之一部分，就恍如仙气弥漫于天堂一般。
也许有人会反对说，这个棘手的定义不应该求诸于商业界，那好，我们只管把这个问题抛给学术界吧，但他们也只会给出一个差不多的答案。例如，下面这个常见的学术界对安全的定义，它出自20世纪60年代出版的贝尔–拉帕杜拉安全模型（Bell-La
Padula security
model，这套规范是企图规范化安全系统需求的诸多努力之一，这是一套针对国家机器的规范1；当然也是最知名的一套规范。）
当且仅当系统开始于安全的状态，而且一直不会落入非安全状态，它才是安全的。
当然，像这些定义安全的文字从根本上来说都是正确的，用于论文的基调甚至政府规范都毫无问题。但实际上，对真实世界里的软件工程而言，由于以下三个原因，以这些理论为基础建立的模型几乎是没用的。
对一个足够复杂的计算机系统来说，没有办法定义什么是正确的行为。对一个操作系统或者Web浏览器来说，没有一个权威机构能定义什么是“应该的方式”或者“安全的状态”。最终用户、系统所有者、数据提供者、业务流程所有者和软件硬件开发商之间的利益是南辕北辙，并且说变就变—如果公司的股东们可以为所欲为，能够不加掩饰地优先考虑自己的利益，就更是如此了。雪上加霜的是，社会学和博弈论的研究表明，把各方利益做简单的叠加运算，实际上并不能产生互赢的结果。这种两难的困局就叫“公地悲剧”，在日后的互联网发展里它将一直是争论的焦点。
美好的想法无法自动转换成规范的约束条件。即使通过给出系统应包含哪些具体用例，我们能就系统该有的行为达成完美的、高级别的共识，但这些用例几乎不可能与可允许的输入数据、程序的状态和这些状态的转换一一对应起来，而要做正式的系统分析却需要这种对应关系。很简单，譬如，一个很常识性的概念“我不希望别人越权读到我的电子邮件”，却没有办法很好地翻译成数据模型。也许有些剑走偏锋的方法的确能把这种模糊的需求部分地转换成规范化的表达，但对软件开发过程带来严重的限制，并产生比验证算法（Validated
Algorithm）更复杂的许多规则集和模型。并且，这些方法自身的正确性也还需要进一步验证……这样就走进了一个死循环。
很难令人信服地分析软件的行为。在复杂的真实世界的场景里，完全没有办法令人信服地通过对计算机程序的静态分析，证明程序的运行是符合详细设计规范的（当然，在高度受限的环境下或针对一个非常狭义的目标还是有可能办到的）。很多案例在实际环境中是无解的（因为计算的复杂程度），甚至有可能由于停机问题（halting
problem）而完全无法确定其状态。
对安全的这些早期定义既模糊又没用，但令人抓狂的是，尽管几十年过去了，事实上我们取得的进展却非常有限。2001年由Naval
Research
Laboratory发布的一份学术报告回顾了软件安全领域的早期工作，结果也不过是给软件安全提供了一个更随意的枚举式的定义—
而且这个定义还明确否认其自身并不完善和不完整2。
如果系统在处理信息时恰当地保护了数据，使其不会产生未授权的泄漏、未授权的篡改以及能抵抗未授权的大规模压力（也叫拒绝服务，Denial
of
Service），那系统就是安全的。我们说“恰当地”是因为如果不加上这个限制，真实环境里实际上没法达成这一目标；因为安全从根本上来说只是相对的。
这篇论文也回顾和评估了那些早期的安全定义，并指出BLP模型为了保持理论上的纯洁性而做出了无谓的牺牲。
经验显示，一方面，作为公理的Bell-La
Padula模型的限制太多：它禁止了在实际应用中一定会出现的用户操作。另一方面，为了克服某些限制条件，它提供的可信对象机制又变得不够严格……导致的结果是，开发人员不得不为每个系统里受信任过程的合理行为，都要设定一个专门的规范。
最后，不论引入多少这种优雅的彼此竞争的安全模型，它们都期望基于也许注定失败的算法，来理解和评估现实世界里的软件安全性。这让开发人员和安全专家没办法对产品代码的质量进行权威的有预见性的判断。那么，我们还有什么选择呢？
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
