《Web之困：现代Web应用安全指南》在Web安全领域有“”的美誉，在世界范围内被安全工作者和Web从业人员广为称道，由来自GoogleChrome浏览器团队的世界黑客、安全专家撰写，是目前深度探索现代Web浏览器安全技术的专著。
内容简介《web之困：现代web应用安全指南》在web安全领域有“圣经”的美誉，在世界范围内被安全工作者和web从业人员广为称道，由来自google chrome浏览器团队的世界顶级黑客、国际一流安全专家撰写，是目前唯一深度探索现代web浏览器安全技术的专著。本书从浏览器设计的角度切入，以探讨浏览器的各主要特性和由此衍生出来的各种安全相关问题为主线，深入剖析了现代web浏览器的技术原理、安全机制和设计上的安全缺陷，为web安全工作者和开发工程师们应对各种基于浏览器的安全隐患提供了应对措施。
《Web之困：现代Web应用安全指南》开篇回顾了Web的发展历程和安全风险的演化；第一部分解剖了现代浏览器的工作原理，包括URL、HTTP协议、HTML语言、CSS、文档格式、浏览器插件等内容；第二部分从浏览器的设计角度深入分析了各种现代Web浏览器（Firefox、Chrome、IE等）所引入的重点安全机制，例如同源策略、源的继承、窗口和框架的交互、安全边界、内容识别、应对恶意脚本、外围的网站特权等，并分析了这些机制存在的安全缺陷，同时为Web应用开发者提供了如何避免攻击和隐私泄露的应对措施；第三部分对浏览器安全机制的未来趋势进行了展望，包括新的浏览器特性与安全展望、其他值得注意的浏览器、常见的Web安全漏洞等。
作者简介国际一流信息安全技术专家，被誉为IT安全领域最有影响力的11位黑客之一。曾发现过数以百计的网络安全漏洞，并发表了多篇具有重大影响的研究论文。对现代Web浏览器有非常深入的研究，目前就职于Google，基于其在Web安全方面的丰富经验帮助Google增强包括Chrome浏览器在内的一系列产品的安全性。此外，他还是一位开源软件贡献者，是著名开源软件p0f、skipfish、ratproxy等的开发者。
译者简介
朱筱丹，毕业于华南理工大学无线电系，某信息安全公司工程师。在安全技术领域摸爬滚打多年，热爱读书与美食。
原文书摘有这么件传闻逸事(但很可能是真事)，说的是一位名叫John Breckman的网站管理员的悲剧。故事里说，John的网站无意中被搜索引擎的爬虫全删了。仅仅是因为这个爬虫无意中访问到一个不需要授权的页面，里面是John自己做的一个基于GET方法的管理页面...爬虫就高高兴兴地把页面所有的“删除”链接都爬了一遍，然后？然后就没有然后了。
WEB之困现代WEB应用安全指南pdf预览
目录译者序
前 言
第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 支持http/0.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 http/html 交互语义 / 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 i/o接口 / 245
第18章 常见的web安全漏洞 / 246
18.1 与web应用相关的漏洞 / 246
18.2 web应用设计时应谨记的问题 / 248
18.3 服务器端的常见问题 / 250
后记 / 252
注释 / 254
精彩试读1.1.1正统之道的尴尬
也许开发一个安全程序最直接的途径就是从算法上证明该程序的运行是正确的。从直觉来说,这个简单的假设听起来还蛮有道理的-那为什么此路不通呢?
首先让我们讨论一下作为形容词时“安全”这两字的含义。准确来说,它到底是什么意思呢?安全( Security)听起来很直观,但在计算机领域,就愣是没法给它下一个确切的定义。没错,我们可以用一些很眩目但基本没啥意义的方式来描述安全,例如,在业界经常被引用的一个关于安全的定义如下,但实际上它也是有问题的:
如果系统能按既定的方式完成任务,不傚頷外的事情,那这套系统就是安全的。
这个定义很简洁,也大致描述了一个抽象的目标,但它几乎没提到要怎么做才能达成这个目标。虽然这句话的主题是关于计算机科学的,但其笼统程度,和维克多·雨果的一句诗倒有异曲同工之妙:
爱情乃灵魂之一部分,就恍如仙气弥漫于天堂一般也许有人会反对说,这个棘手的定义不应该求诸于商业界,那好,我们只管把这个问题抛给学术界吧,但他们也只会给出一个差不多的答案。例如,下面这个常见的学术界对安全的定义,它出自20世纪60年代出版的贝尔一拉帕杜拉安全模型( Bell-La Padulasecurity model,这套规范是企图规范化安全系统需求的诸多努力之一,这是一套针对国家机器°的规范;当然也是最知名的一套规范。)当且仅当系统开始于安全的状态,而且一直不会落入非安全状态,它才是安全的。
当然,像这些定义安全的文字从根本上来说都是正确的,用于论文的基调甚至政府规范都毫无问题。但实际上,对真实世界里的软件工程而言,由于以下三个原因,以这些理论为基础建立的模型几乎是没用的。
对一个足够复杂的计算机系统来说,没有办法定义什么是正确的行为。对一个操作系统或者Web浏览器来说,没有一个权威机构能定义什么是“应该的方式”或者“安全的状态”。最终用户、系统所有者、数据提供者、业务流程所有者和软件硬件开发商之间的利益是南辕北辙,并且说变就变一如果公司的股东们可以为所欲为,能够不加掩饰地优先考虑自己的利益,就更是如此了。雪上加霜的是,社会学和博弈论的研究表明,把各方利益做简单的叠加运算,实际上并不能产生互赢的结果。这种两难的困局就叫“公地悲剧”,在日后的互联网发展里它将直是争论的焦点。
美好的想法无法自动转换成规范的约束条件。即使通过给出系统应包含哪些具体用例,我们能就系统该有的行为达成完美的、高级别的共识,但这些用例几乎不可能与可允许的输入数据、程序的状态和这些状态的转换一一对应起来,而要做正式的系统分析却需要这种对应关系。很简单,譬如,一个很常识性的概念“我不希望别人越杈读到我的电子邮件”,却没有办法很好地翻译成数据模型。也许有些剑走偏锋的方法的确能把这种模糊的需求部分地转换成规范化的表达,但对软件开发过程带来严重的限制,并产生比验证算法( Validated Algorithm)更复杂的许多规则集和模型。并且,这些方法自身的正确性也还需要进一步验证……这样就走进了一个死循环。
很难令人信服地分析软件的行为。在复杂的真实世界的场景里,完全没有办法令人信服地通过对计算机程序的静态分析,证明程序的运行是符合详细设计规范的i然,在高度受限的环境下或针对一个非常狭义的目标还是有可能办到的)很多案例在实际环境中是无解的(因为计算的复杂程度),甚至有可能由于停机问题halting problem)而完全无法确定其状态。
发表于 2021-8-17 16:12:36
[/url]
[/url]
[/url]
[/url]
[/url]
[/url]