注册 | 登录读书好,好读书,读好书!
读书网-DuShu.com
当前位置: 首页出版图书科学技术计算机/网络信息安全编写安全的代码

编写安全的代码

编写安全的代码

定 价:¥49.00

作 者: (美)Michael Howard,(美)David LeBlanc著;程永敬[等]译;程永敬译
出版社: 机械工业出版社
丛编项: 微软公司核心技术书库
标 签: 综合 安全与加密 计算机与互联网

购买这本书可以去


ISBN: 9787111102854 出版时间: 2002-08-01 包装: 平装
开本: 24cm+光盘1片 页数: 345 字数:  

内容简介

  对于“是否有这个必要”的疑问,在书中(第1章)作者是如此回答的:首先,时代在变,从“World Wide Web”(万维网)到“Wild Wild Web”(混乱无序的网)绝非文字游戏。在如今这个充满了敌意的网络环境里面,编写的代码必须经得起考验,而再用旧的思维模式去思考新的问题是非常危险的。其次,安全的产品同时也是高质量的产品,安全是高质量产品的一个子集。再次,媒体和竞争对手都喜欢在安全问题上大做文章,这些都是能上头条新闻的信息,屡屡成为牺牲品的公司不厌其烦,微软即是一个典型的例子。最后一点就是,修补安全漏洞的代价是十分高昂的。除了直接的人力和误工等损失之外,还包括改善公共关系和客户信任度的降低的损失,我把它称之为“商誉”上的损失。这四点从企业的角度对此做出了回答。对于个人而言,也有着种种的不解(附录D):①没有人会做那事!②我们从来没有受到过攻击。③我们使用了密码、ACL和防火墙,所以安全。④检查过代码,没有安全bug。对这些问题,作者显然有着丰富的实践经验:①当苦口婆心地告诉某个开发小组一定要做缓冲溢出测试时,大家显然不相信。于是作者现场编写了一个Perl的小脚本,它神奇地生成了一个伪造的包,发送给产品打开的Socket后,轻易地就击溃了他们的服务器。②作者与一个产品开发组工作之时,对方信誓旦旦地说他们从来没有受到过攻击,没有问题。然而就在他们被第一次攻击之时,突然就涌现了另外的数个安全漏洞。黑客的嗜好就是发现漏洞,然后广而告之,然后继续探查你的其他漏洞,问题迅速扩大化。③作者告诫大家要避免以下错误:自创“加密”算法;不安全地存储密码;使用“任何人”的ACL。防火墙只是安全体系的一环,并非全部。例如,很多攻击都是通过HTTP,也就是一个通常开放的端口来进行的。④如果不知道安全bug是什么样子,当然就没有那个问题了。正如书中前言所提到的那样,《编写安全的代码》一书“教你以安全的方式设计、编写和测试应用程序是本书惟一的目的”,始终围绕着应用程序安全的话题进行讨论,从实践的角度对代码安全进行了全程的指导。同时,这也是“第一本指导程序员从内部加强软件安全的书籍”,是一本主要面向程序员,涉及各种攻击漏洞的安全分析,并指导人们从开发阶段即开始加强软件安全的书。在此,我把它推荐给所有关心代码安全的朋友们阅读。

作者简介

  Michael Howard:《Design Secure Web-Based Applications for Microsoft Windows 2000》一书的主要作者。从1992年就开始从事Windows NT安全方面的研究。现在在微软的Windows XP小组中负责安全方面的设计、编程和测试。他每年都要帮助全球上百家公司以保证他们的应用的安全。David LeBlanc:微软高信度计算安全性小组高级安全技术专家,安全技术方面的先锋,他的职责是保卫微软网站免受黑客攻击,一直从事安全领域方面的工作,曾因其在Internet安全系统方面的突出贡献而获得ISS安全产品奖。

图书目录

译者序

前言
第一部分 现代安全
第1章 对安全系统的需求 
1.1 “Wild Wild Web”上的应用程序 
1.2 让每个人都参与进来 
1.2.1 利用机智使整个组织认识到安全的重要性 
1.2.2 使用搞破坏的方法 
1.3 用来灌输安全文化的一些思想 
1.3.1 让老板发一封电子邮件 
1.3.2 任命安全宣传员 
第2章 设计安全的系统 
2.1 两个常见的安全性错误 
2.2 赖以生存的安全策略 
2.2.1 建立一个安全步骤 
2.2.2 定义产品的安全目标 
2.2.3 将安全性看做是产品的一个功能 
2.2.4 从错误中吸取教训 
2.2.5 使用最小权限 
2.2.6 使用纵深防御 
2.2.7 假设外部系统是不安全的 
2.2.8 做好失效时的计划 
2.2.9 失效时进入安全模式 
2.2.10 选择安全的默认值
2.2.11 请记住安全性功能不等于安全的功能 
2.2.12 不要将安全建立在模糊信息上 
2.2.13 最后三个观点 
2.3 用威胁模型做安全设计 
2.3.1 集体讨论已经知道的对系统的威胁 
2.3.2 以风险递减的顺序给威胁排序 
2.3.3 选择对威胁做何种反应 
2.3.4 选择技术来缓解威胁 
2.4 安全方法 
2.4.1 认证 
2.4.2 授权 
2.4.3 抗篡改和加强保密的方法 
2.4.4 保护秘密,更好的办法是不存储秘密 
2.4.5 加密、散列、MAC和数字签名 
2.4.6 审核 
2.4.7 过滤、扼杀和服务质量 
2.4.8 最小权限 
2.5 回到工资应用程序范例 
2.6 丰富的威胁和解决方案 
第二部分 安全的编码技术
第3章 头号公敌:缓冲区溢出 
3.1 静态缓冲区溢出 
3.2 堆溢出 
3.3 数组索引错误 
3.4 格式化字符串bug 
3.5 Unicode和ANSI的缓冲区大小不匹配 
3.6 防止缓冲区溢出 
3.7 好消息 
第4章 确定有效的访问控制 
4.1 ACL为什么如此重要 
4.2 ACL由哪些部分组成 
4.3 选择一种有效的ACL方法 
4.4 创建ACL
4.4.1 在Windows NT 4中创建ACL
4.4.2 在Windows 2000中创建ACL 
4.4.3 使用活动模板库创建ACL 
4.5 空的DACL以及其他危险的ACE类型 
4.5.1 空的DACL及审核
4.5.2 危险的ACE类型
4.5.3 如果不能改变空DACL的话应该怎么办
4.6 其他访问控制机制
4.6.1 IP限制
4.6.2 COM+角色
4.6.3 SQL Server触发器和权限
4.6.4 一个医疗上的实例
4.6.5 关于访问控制机制的一点重要说明 
第5章 使用最低权限运行
5.1 在实际中的最低权限
5.1.1 病毒和木马
5.1.2 破坏Web服务
5.2 访问控制概述
5.3 权限概述
5.3.1 SeBackupPrivilege问题
5.3.2 SeDebugPrivilege问题
5.3.3 SeTcbPrivilege问题
5.3.4 SeAssignPrimaryTokenPrivilege和SeIncreaseQuotaPrivilege问题
5.4 对令牌的简短回顾
5.5 令牌、权限、SID、ACL以及相关进程
5.6 确定使用恰当权限的过程 
5.6.1 步骤1:找出应用程序所使用的资源 
5.6.2 步骤2:找出应用程序所使用的有特权的API 
5.6.3 步骤3:需要哪个账号
5.6.4 步骤4:获取令牌的内容
5.6.5 步骤5:是否所有的SID和权限都需要 
5.6.6 步骤6:调整令牌 
5.6.7 何时使用限定令牌 
5.7 Windows XP和Windows.NET Server中的低权限服务账号 
5.8 调试的最低权限问题 
5.8.1 为什么以普通用户运行的程序会失败 
5.8.2 如何确定为什么程序会失败 
第6章 密码的缺陷 
6.1 使用拙劣的随机数 
6.1.1 问题:rand函数 
6.1.2 一种补救方法:CryptGenRandom 
6.2 用口令衍生出加密密钥 
6.3 糟糕的密钥管理 
6.4 使用你自己的加密函数 
6.5 使用相同的流密码对密钥加密 
6.5.1 人们为什么要用流密码 
6.5.2 流密码的缺陷 
6.5.3 你“非要”使用相同的密钥会怎么样 
6.6 对流密码的位替换攻击 
6.6.1 解决位替换攻击问题 
6.6.2 什么时候使用散列、密钥散列或数字签名 
6.7 对明文和密文使用同一个缓冲区 
第7章 涉密信息的存储 
7.1 攻击方法 
7.2 有时你并不需要存储秘密信息 
7.3 从用户获取秘密信息 
7.4 在Windows 2000和Windows XP中存储秘密信息 
7.5 在Windows NT 4中存储秘密信息 
7.6 在Windows 95、Windows 98、Windows Me和Windows CE中存储秘密信息 
7.7 提高安全限制 
7.7.1 在FAT文件系统的文件中存储数据 
7.7.2 利用一个嵌入密钥和XOR来加数据 
7.7.3 利用嵌入密钥和3DES加密数据 
7.7.4 利用3DES加密数据并在注册表中存储口令 
7.7.5 利用3DES加密数据并在注册表中存储一个强密钥 
7.7.6 利用3DES加密数据、在注册表中存储一个强密钥并对注册表密钥和文件进行ACL处理 
7.8 一个想法:用外部设备对秘密数据加密 
7.8.1 一个应用PPCKey的例子 
7.8.2 PPCKey威胁方式 
第8章 规范的表示问题 
8.1 什么是规范?为什么它存在问题 
8.2 一点历史 
8.2.1 绕过AOL的家长控制 
8.2.2 绕过Napster的名称过滤 
8.2.3 绕过eEye的安全检测 
8.2.4 苹果机Mac OS X和Apache中的漏洞 
8.2.5 区域和IE4的“Dotless-IP Address”缺陷 
8.2.6 IIS4的::$DATA漏洞 
8.2.7 DOS驱动名漏洞 
8.2.8 Sun 公司StarOffice /tmp目录符号连接漏洞 
8.3 一般的Windows规范化错误 
8.3.1 长文件名的8.3格式表示方式 
8.3.2 NTFS的另一种数据流 
8.3.3 后缀字符 
8.3.4 \\?\格式 
8.3.5 目录遍历和使用父路径(..) 
8.3.6 绝对和相对文件名 
8.3.7 不区分大小写的文件名 
8.3.8 设备名称和保留名称 
8.3.9 UNC共享 
8.4 防止规范化错误的出现 
8.4.1 不要根据名称来做出判断 
8.4.2 使用正则表达式来限制名称的权限 
8.4.3 尝试对名字进行规范化 
8.5 最后的思考:基于非文件的规范化问题 
8.5.1 服务器名 
8.5.2 用户名 
第三部分 基于网络的应用程序
第9章 Socket安全 
9.1 避免服务器被截听 
9.2 选择服务器接口 
9.3 接受连接 
9.4 编写防火墙友好的应用程序 
9.4.1 用一个连接工作 
9.4.2 不要要求服务器连接回客户端 
9.4.3 使用基于连接的协议 
9.4.4 不要通过另外一个协议使你的应用程序进行多路复用 
9.4.5 不要在应用层数据中嵌入主机IP地址 
9.4.6 让你的应用程序可配置 
9.5 欺骗、基于主机和基于端口的信任 
第10章 RPC、ActiveX控件和DCOM安全 
10.1 RPC入门 
10.1.1 什么是RPC 
10.1.2 创建RPC应用程序 
10.1.3 RPC应用程序的通信原理 
10.2 RPC安全最佳实践 
10.2.1 使用/robust MIDL开关参数 
10.2.2 使用[range]表征项 
10.2.3 要求对连接进行验证 
10.2.4 使用数据包的保密性和完整性 
10.2.5 使用严格的上下文句柄 
10.2.6 不要依靠上下文句柄来进行访问检查 
10.2.7 注意空的上下文句柄 
10.2.8 不要信任你的对端 
10.2.9 使用安全回调 
10.2.10 在单一进程中牵连多个RPC服务器 
10.2.11 考虑为你的终端添加一个注释 
10.2.12 使用主流的协议 
10.3 DCOM安全最佳实践 
10.3.1 DCOM基础 
10.3.2 应用层的安全 
10.3.3 DCOM用户上下文环境 
10.3.4 可编程实现的安全性 
10.3.5 源端和接收端 
10.4 ActiveX入门 
10.5 ActiveX安全最佳实践 
10.5.1 什么样的ActiveX组件是可以安全用于初始化和脚本的 
10.5.2 可安全用于初始化和脚本的最佳实践 
第11章 拒绝服务(DoS)攻击的防范 
11.1 应用程序失败攻击 
11.2 CPU资源不足攻击 
11.3 内存资源不足攻击 
11.4 资源不足攻击 
11.5 网络带宽攻击 
第12章 基于Web服务的安全 
12.1 永远不要相信用户的输入 
12.1.1 用户输入问题上的安全漏洞 
12.1.2 解决用户输入问题的方法 
12.2位Web特有的规范化问题 
12.2.1 7位和8位ASCII码 
12.2.2 十六进制转换码 
12.2.3 UTF-8可变宽编码 
12.2.4 UCS-2 Unicode编码 
12.2.5 双重编码 
12.2.6 HTML转换码 
12.2.7 对基于Web的标准化问题的解决办法 
12.3 其他基于Web的安全性主题 
12.3.1 HTTP信任问题 
12.3.2 ISAPI程序和过滤器 
12.3.3 不要在Web页中存储涉密数据 
12.3.4 真的需要使用sa吗?可能不是 
第四部分 特殊话题
第13章 编写安全的.NET代码 
13.1 缓冲区溢出和CLR 
13.1.1 添加属于你自己的安全性错误处理 
13.1.2 一个事实 
13.2 在.NET中保存涉密数据 
13.3 总是要求适当的权限 
13.4 过度使用Assert 
13.5 关于Demand和Assert的其他信息 
13.6 不要害怕拒绝权限 
13.7 对来自不可信任源的数据进行验证 
13.8 ASP.NET中的线程支持问题 
13.9 在部署ASP.NET应用程序之前要禁用跟踪和调试 
13.10 使用.NET Framework产生良好的随机数 
13.11 对来自不可信任源的数据进行反串行化 
13.12 在出现故障时,不要让攻击者获知太多的信息 
13.13 权衡SAOP 
13.14 最后的一些想法 
第14章 测试应用程序的安全性 
14.1 安全测试员的作用 
14.2 安全性测试与一般测试的区别 
14.3 进入正题 
14.4 建立安全性测试计划 
14.4.1 分解应用程序 
14.4.2 确定组件接口 
14.4.3 依照隐患的相对大小对接口进行排序 
14.4.4 确定每一个接口使用的数据 
14.4.5 通过注入错误的数据发现安全问题 
14.4.6 在测试之前 
14.4.7 制作用于发现缺陷的工具 
14.5 用欺诈性的服务程序测试客户软件 
14.6 用户会看到或修改那些数据吗 
14.7 用安全模板做测试 
14.8 测试代码应该有很高的质量 
14.9 测试端到端的解决方案 
14.10 一些题外话:代码评审 
第15章 安全的软件安装 
15.1 最低权限原则
15.2 使用安全配置编辑器 
15.3 低层的安全API 
第16章 常用的好经验 
16.1 保护客户的隐私 
16.1.1 收集用户数据的类型 
16.1.2 收集用户数据 
16.2 不要告诉攻击者任何东西 
16.3 双重检查你的错误路径 
16.4 让它保持关闭 
16.5 核心模式(Kernel-Mode)错误 
16.5.1 使用用户模式(User-Mode)的内存 
16.5.2 通过未受保护的IOCTL访问有特权的接口 
16.6 考虑给代码添加安全注释 
16.7 借助于操作系统的功能 
16.8 不要依靠用户来做出好的设计 
16.9 安全地调用CreateProcess 
16.9.1 不要将lpApplicationName设置为NULL 
16.9.2 在lpCommandLine参数中用引号包含执行文件的路径 
16.10 不要创建共享的/可写的段(Segment) 
16.11 正确地使用假冒函数 
16.12 不要在\Program Files目录中写用户文件 
16.13 不要在HKLM中写用户数据 
16.14 不要以完全控制或所有访问的方式打开对象 
16.15 对象创建错误 
16.16 安全地创建临时文件 
16.17 客户端安全是一个矛盾 
16.18 例子是模板 
16.19 把你的应用程序的使用者当成傻瓜 
16.20 如果…你将其归功于你的用户 
16.21 判断基于管理员SID的访问 
16.22 允许使用长的口令 
附 录
附录A 危险的API 
附录B 十条安全法则 
附录C 安全管理员的十条法则 
附录D 安全的误区

本目录推荐