搜索
高级检索
高级搜索
书       名 :
著       者 :
出  版  社 :
I  S  B  N:
文献来源:
出版时间 :
Web之困:现代Web应用安全指南:a guide to securing modern web applications
0.00    
图书来源: 浙江图书馆(由图书馆配书)
  • 配送范围:
    全国(除港澳台地区)
  • ISBN:
    9787111439462
  • 作      者:
    (美)Michal Zalewski著
  • 出 版 社 :
    机械工业出版社
  • 出版日期:
    2013
收藏
编辑推荐
  

  《Web之困:现代Web应用安全指南》Web安全领域圣经级著作,深度探索现代Web浏览器安全技术的专著,由来自Google Chrome浏览器团队的世界拔尖黑客、国际一流安全专家撰写。
  从浏览器设计角度深入剖析现代浏览器的技术原理、安全机制和设计上的安全缺陷,为Web安全工作者应对基于浏览器的各种安全隐患提供应对措施。
  

  

海报:

  

展开
作者简介
  Michal Zalewski,国际一流信息安全技术专家,被誉为IT安全领域最有影响力的11位黑客之一。曾发现过数以百计的网络安全漏洞,并发表了多篇具有重大影响的研究论文。对现代Web浏览器有非常深入的研究,目前就职于Google,基于其在Web安全方面的丰富经验帮助Google增强包括Chrome浏览器在内的一系列产品的安全性。此外,他还是一位开源软件贡献者,是著名开源软件p0f、skipfish、ratproxy等的开发者。

  译者简介
  朱筱丹,毕业于华南理工大学无线电系,某信息安全公司工程师。在安全技术领域摸爬滚打多年,热爱读书与美食。
展开
内容介绍
  《Web之困:现代Web应用安全指南》在Web安全领域有“圣经”的美誉,在世界范围内被安全工作者和Web从业人员广为称道,由来自Google Chrome浏览器团队的世界顶级黑客、国际一流安全专家撰写,是目前唯一深度探索现代Web浏览器安全技术的专著。本书从浏览器设计的角度切入,以探讨浏览器的各主要特性和由此衍生出来的各种安全相关问题为主线,深入剖析了现代Web浏览器的技术原理、安全机制和设计上的安全缺陷,为Web安全工作者和开发工程师们应对各种基于浏览器的安全隐患提供了应对措施。
  《Web之困:现代Web应用安全指南》开篇回顾了Web的发展历程和安全风险的演化;第一部分解剖了现代浏览器的工作原理,包括URL、HTTP协议、HTML语言、CSS、文档格式、浏览器插件等内容;第二部分从浏览器的设计角度深入分析了各种现代Web浏览器(Firefox、Chrome、IE等)所引入的重点安全机制,例如同源策略、源的继承、窗口和框架的交互、安全边界、内容识别、应对恶意脚本、外围的网站特权等,并分析了这些机制存在的安全缺陷,同时为Web应用开发者提供了如何避免攻击和隐私泄露的应对措施;第三部分对浏览器安全机制的未来趋势进行了展望,包括新的浏览器特性与安全展望、其他值得注意的浏览器、常见的Web安全漏洞等。
展开
精彩书摘
  第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模型的限制太多:它禁止了在实际应用中一定会出现的用户操作。另一方面,为了克服某些限制条件,它提供的可信对象机制又变得不够严格……导致的结果是,开发人员不得不为每个系统里受信任过程的合理行为,都要设定一个专门的规范。
  最后,不论引入多少这种优雅的彼此竞争的安全模型,它们都期望基于也许注定失败的算法,来理解和评估现实世界里的软件安全性。这让开发人员和安全专家没办法对产品代码的质量进行权威的有预见性的判断。那么,我们还有什么选择呢?
展开
目录
译者序
前 言

第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用户界面语言
7.4.5 无线标记语言
7.4.6 RSS 和 Atom订阅源
7.5 关于不可显示的文件类型
7.6 安全工程速查表

第8章 浏览器插件产生的内容
8.1 对插件的调用
8.2 文档显示帮助程序
8.3 插件的各种应用框架
8.3.1 Adobe Flash
8.3.2 Microsoft Silverlight
8.3.3 Sun Java
8.3.4 XML Browser Applications
8.4 ActiveX Controls
8.5 其他插件的情况
8.6 安全工程速查表

第二部分 浏览器安全特性

第9章 内容隔离逻辑
9.1 DOM的同源策略
9.1.1 document.domain
9.1.2 postMessage(...)
9.1.3 与浏览器身份验证的交互
9.2 XMLHttpRequest的同源策略
9.3 Web Storage 的同源策略
9.4 Cookies 的安全策略
9.4.1 Cookie对同源策略的影响
9.4.2 域名限制带来的问题
9.4.3 localhost带来的非一般风险
9.4.4 Cookie与"合法"DNS劫持
9.5 插件的安全规则
9.5.1 Adobe Flash
9.5.2 Microsoft Silverlight
9.5.3 Java
9.6 如何处理格式含糊或意想不到的源信息
9.6.1 IP 地址
9.6.2 主机名里有额外的点号
9.6.3 不完整的主机名
9.6.4 本地文件
9.6.5 伪URL
9.6.6 浏览器扩展和用户界面
9.7 源的其他应用
9.8 安全工程速查表

第10章 源的继承
10.1 about:blank页面的源继承
10.2 data: URL的继承
10.3 javascript:和vbscript: URL对源的继承
10.4 关于受限伪URL的一些补充
10.5 安全工程速查表

第11章 同源策略之外的世界
11.1 窗口和框架的交互
11.1.1 改变现有页面的地址
11.1.2 不请自来的框架
11.2 跨域内容包含
11.3 与隐私相关的副作用
11.4 其他的同源漏洞和应用
11.5 安全工程速查表

第12章 其他的安全边界
12.1 跳转到敏感协议
12.2 访问内部网络
12.3 禁用的端口
12.4 对第三方Cookie的限制
12.5 安全工程速查表

第13章 内容识别机制
13.1 文档类型检测的逻辑
13.1.1 格式错误的MIME Type写法
13.1.2 特殊的 Content-Type 值
13.1.3 无法识别的Content Type类型
13.1.4 防御性使用Content-Disposition
13.1.5 子资源的内容设置
13.1.6 文件下载和其他非HTTP内容
13.2 字符集处理
13.2.1 字节顺序标记
13.2.2 字符集继承和覆盖
13.2.3 通过HTML代码设置子资源字符集
13.2.4 非HTTP 文件的编码检测
13.3 安全工程速查表

第14章 应对恶意脚本
14.1 拒绝服务攻击
14.1.1 执行时间和内存使用的限制
14.1.2 连接限制
14.1.3 过滤弹出窗口
14.1.4 对话框的使用限制
14.2 窗口定位和外观问题
14.3 用户界面的时差攻击
14.4 安全工程速查表

第15章 外围的网站特权
15.1 浏览器和托管插件的站点权限
15.2 表单密码管理
15.3 IE浏览器的区域模型
15.4 安全工程速查表

第三部分 浏览器安全机制的未来趋势

第16章 新的浏览器安全特性与未来展望
16.1 安全模型扩展框架
16.1.1 跨域请求
16.1.2 XDomainRequest
16.1.3 Origin 请求头的其他应用
16.2 安全模型限制框架
16.2.1 内容安全策略
16.2.2 沙盒框架
16.2.3 严格传输安全
16.2.4 隐私浏览模式
16.3 其他的一些进展
16.3.1 浏览器内置的 HTML净化器
16.3.2 XSS 过滤
16.4 安全工程速查表

第17章 其他值得注意的浏览器机制
17.1 URL级别和协议级别的提议
17.2 内容相关的特性
17.3 IO接口

第18章 常见的Web安全漏洞
18.1 与Web应用相关的漏洞
18.2 Web应用设计时应谨记的问题
18.3 服务器端的常见问题
后记
注释
展开
加入书架成功!
收藏图书成功!
我知道了(3)
发表书评
读者登录

请选择您读者所在的图书馆

选择图书馆
浙江图书馆
点击获取验证码
登录
没有读者证?在线办证