软件安全的24宗罪--编程缺陷与修复之道
点击看大图基本信息
- 原书名： 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them
- 原出版社： McGraw-Hill Osborne Media
- 作者： (美)Michael Howard David LeBlanc John Viega [作译者介绍]
- 译者： 董艳 包战 程文俊
- 丛书名： 安全技术经典译丛
- 出版社：清华大学出版社
- ISBN：9787302226345
- 上架时间：2010-6-18
- 出版日期：2010 年6月
- 开本：16开
- 页码：306
- 版次：1-1
- 所属分类：
计算机 > 安全 > 综合
编辑推荐
由著名软件安全专家编写的安全漏洞专业书籍
发现和修复各种安全漏洞的最佳指导
丰富的安全漏洞示例以及修复措施
作者长期实践经验的总结
内容简介回到顶部↑
软件安全是一个不断变化的主题,不仅不断出现新的漏洞类型,而且出现了漏洞的各种变体.本书总结了目前最危险的24个安全漏洞,给出了丰富的漏洞示例,并且提供了相应的修复措施。
各种web应用程序漏洞及修复措施
各种实现漏洞及修复措施
各种加密漏洞及修复措施
各种联网漏洞及修复措施
各种web应用程序漏洞及修复措施
各种实现漏洞及修复措施
各种加密漏洞及修复措施
各种联网漏洞及修复措施
作译者回到顶部↑
本书提供作译者介绍
Michael Howard是Microsoft公司Trustworthy Computing(TwC)Group(可信赖计算组)下属安全工程组的高级安全项目经理，负责管理整个公司的安全设计、编程和测试技术。Howard是一位Security Development Lifecycle(SDL)构建师，SDL是一个提高微软软件安全性的过程。
Howard于1992年开始在微软公司工作，那时他在微软公司的新西兰分部，刚开始的前两年在产品支持服务小组为Windows籼编译器提供技术支持，接着为Microsoft ConsultingServices提供技术支持，在此阶段，他为客户提供安全基础架构支.. << 查看详细
Howard于1992年开始在微软公司工作，那时他在微软公司的新西兰分部，刚开始的前两年在产品支持服务小组为Windows籼编译器提供技术支持，接着为Microsoft ConsultingServices提供技术支持，在此阶段，他为客户提供安全基础架构支.. << 查看详细
目录回到顶部↑
第ⅰ部分 web应用程序漏洞
第1章 sql注入 3
1.1 漏洞概述 3
1.2 cwe参考 4
1.3 受影响的编程语言 5
1.4 漏洞详述 5
1.4.1 关于linq的注意事项 5
1.4.2 受漏洞影响的c# 5
1.4.3 受漏洞影响的php 6
1.4.4 受漏洞影响的perl/cgi 7
1.4.5 受漏洞影响的python 7
1.4.6 受漏洞影响的ruby on rails 8
1.4.7 受漏洞影响的java和jdbc 8
1.4.8 受漏洞影响的c/c++ 9
1.4.9 受漏洞影响的sql 10
1.4.10 相关漏洞 11
1.5 查找漏洞模式 11
1.6 在代码审查期间查找该漏洞 12
1.7 发现该漏洞的测试技巧 12
1.8 漏洞示例 14
第1章 sql注入 3
1.1 漏洞概述 3
1.2 cwe参考 4
1.3 受影响的编程语言 5
1.4 漏洞详述 5
1.4.1 关于linq的注意事项 5
1.4.2 受漏洞影响的c# 5
1.4.3 受漏洞影响的php 6
1.4.4 受漏洞影响的perl/cgi 7
1.4.5 受漏洞影响的python 7
1.4.6 受漏洞影响的ruby on rails 8
1.4.7 受漏洞影响的java和jdbc 8
1.4.8 受漏洞影响的c/c++ 9
1.4.9 受漏洞影响的sql 10
1.4.10 相关漏洞 11
1.5 查找漏洞模式 11
1.6 在代码审查期间查找该漏洞 12
1.7 发现该漏洞的测试技巧 12
1.8 漏洞示例 14
前言回到顶部↑
今天的软件工程人员必须理解建立安全软件的基本规则，这不是因为“这是一个好主意”，或者我们想卖出更多的书，而是因为互联网的本质和一小撮卑劣的家伙想控制互联网。这不是说安全是如何特殊，它其实就是可靠性的另一面。我们都想编写出可靠的软件，而不安全的软件肯定是不可靠的。
软件工程人员不可能花许多时间学习似乎没有什么回报的新规则，这就是我们编写本书的原因：读者不需要翻阅上千页来了解能应用于手头工作的某个新规则，而只需阅读可应用于当前建构的软件的一章或几章内容，以确保不会构建出不安全的软件。
本书是The 19 Deadly Sins of Software Security(《一个都不能有——软件的19个致命安全漏洞》)的第2版。在开始编写本书时，我们其实并不知道读者对本书的期望。第1版卖得很好，大多数与我们谈论该书的人都喜欢它，这主要是因为第1版短小精悍、中肯、可操作性很强。与我们交谈的每个软件开发人员和设计人员都说，他们喜欢第1版的易于阅读，不需要学习软件安全的几乎所有内容，只要查看可应用于当前构建的软件的那几章即可。一些公司还把本书用作临时培训教材，在其员工开始设计或编写产品之前，必须阅读本书的相应章节。
类似这样的评论让我们很高兴，因为我们在开始编写第1版时，就希望它简明扼要、语言流畅、可操作性强。
但第一版是4年前编写的，而软件安全是一个不断变化的主题，不仅出现了新的漏洞类型，还出现了漏洞的变体，当然人们也想出了新的防范措施和缓解手段，以应对不断演变的各种威胁。由于安全领域的变化非常快，所以涉足软件开发的每个人都必须知道，有哪些安全问题、如何找出它们、如何解决它们。
我们第一次开始思考本书的第2版时，面对的问题是如何把软件安全致命漏洞的数量限制在可管理、切实有效的范围内。讨论软件界的安全问题时很容易跑题，还会描述对建立更安全的软件无关紧要的细节。这些细节可能在学术上和智力上很有刺激性，但我们只希望读者建立更安全的软件，而不是开始一次大脑探险！
如果您熟悉关系数据库，就应知道Ted Codd提出的12 Rules，这13条法则(它们从0到12编号)定义了关系数据库。许多数据库界的人都逐字引用这13条法则，因为它们非常简单，能应用于他们的工作上。我们想使本书比较短小，就像Codd法则那样。我们可不希望把19个致命漏洞扩展到100个致命漏洞，其中包含了罕见的、奇异的、浅显的、不相关的安全漏洞。这是一个两难问题：如何提高本书的价值，而又不使书过厚？
我们花了很长时间研究软件业在过去4年中的变化，最后编写出了24个致命漏洞。本书有许多新章节，删除了一些章节，还合并了一些章节。
我们对自己的成果很满意，认为本书反映了目前的大多数软件安全问题。我们也达到了之前的目标：短小、可操作性强、扼要。
本书读者和应读的章节
如果您是在设计、编写和测试软件，就是本书的核心读者。您不需要阅读本书的每一页，除非您喜欢这么做。
本书分为4个主要部分：
Web应用程序漏洞
实现漏洞
加密漏洞
联网漏洞
显然，如果您在建立任意类型的Web应用程序（客户端或服务器端），就需要阅读第I部分。第II部分最长，包含许多与语言相关的实现问题，稍后将讨论这一部分。如果应用程序涉及到加密，就应阅读第III部分。最后，如果应用程序进行了任意形式的网络通信，就应阅读最后一部分。
现在，看看第II部分的问题：
所有的开发人员都应阅读第10、11、12和14章；
需要频繁更新应用程序的开发人员应阅读第15章；
软件工程人员不可能花许多时间学习似乎没有什么回报的新规则，这就是我们编写本书的原因：读者不需要翻阅上千页来了解能应用于手头工作的某个新规则，而只需阅读可应用于当前建构的软件的一章或几章内容，以确保不会构建出不安全的软件。
本书是The 19 Deadly Sins of Software Security(《一个都不能有——软件的19个致命安全漏洞》)的第2版。在开始编写本书时，我们其实并不知道读者对本书的期望。第1版卖得很好，大多数与我们谈论该书的人都喜欢它，这主要是因为第1版短小精悍、中肯、可操作性很强。与我们交谈的每个软件开发人员和设计人员都说，他们喜欢第1版的易于阅读，不需要学习软件安全的几乎所有内容，只要查看可应用于当前构建的软件的那几章即可。一些公司还把本书用作临时培训教材，在其员工开始设计或编写产品之前，必须阅读本书的相应章节。
类似这样的评论让我们很高兴，因为我们在开始编写第1版时，就希望它简明扼要、语言流畅、可操作性强。
但第一版是4年前编写的，而软件安全是一个不断变化的主题，不仅出现了新的漏洞类型，还出现了漏洞的变体，当然人们也想出了新的防范措施和缓解手段，以应对不断演变的各种威胁。由于安全领域的变化非常快，所以涉足软件开发的每个人都必须知道，有哪些安全问题、如何找出它们、如何解决它们。
我们第一次开始思考本书的第2版时，面对的问题是如何把软件安全致命漏洞的数量限制在可管理、切实有效的范围内。讨论软件界的安全问题时很容易跑题，还会描述对建立更安全的软件无关紧要的细节。这些细节可能在学术上和智力上很有刺激性，但我们只希望读者建立更安全的软件，而不是开始一次大脑探险！
如果您熟悉关系数据库，就应知道Ted Codd提出的12 Rules，这13条法则(它们从0到12编号)定义了关系数据库。许多数据库界的人都逐字引用这13条法则，因为它们非常简单，能应用于他们的工作上。我们想使本书比较短小，就像Codd法则那样。我们可不希望把19个致命漏洞扩展到100个致命漏洞，其中包含了罕见的、奇异的、浅显的、不相关的安全漏洞。这是一个两难问题：如何提高本书的价值，而又不使书过厚？
我们花了很长时间研究软件业在过去4年中的变化，最后编写出了24个致命漏洞。本书有许多新章节，删除了一些章节，还合并了一些章节。
我们对自己的成果很满意，认为本书反映了目前的大多数软件安全问题。我们也达到了之前的目标：短小、可操作性强、扼要。
本书读者和应读的章节
如果您是在设计、编写和测试软件，就是本书的核心读者。您不需要阅读本书的每一页，除非您喜欢这么做。
本书分为4个主要部分：
Web应用程序漏洞
实现漏洞
加密漏洞
联网漏洞
显然，如果您在建立任意类型的Web应用程序（客户端或服务器端），就需要阅读第I部分。第II部分最长，包含许多与语言相关的实现问题，稍后将讨论这一部分。如果应用程序涉及到加密，就应阅读第III部分。最后，如果应用程序进行了任意形式的网络通信，就应阅读最后一部分。
现在，看看第II部分的问题：
所有的开发人员都应阅读第10、11、12和14章；
需要频繁更新应用程序的开发人员应阅读第15章；
序言回到顶部↑
在应用计算机工程领域中，使安全工作切实可行是我们面临的最大挑战。
所有的工程系统都有指导性需求——它们已成为可测量的要素，如果达不到这些要求，系统就会失败。例如，大楼必须是安全的(不能倒塌!)，但这还不够，大楼还必须是可用的(里面的空间可以使用)、能盖得起来、可以维护(建筑和维护的成本必须使大楼在投入使用后可以盈利)，最后，大楼还应有一定的吸引力(大楼的外观与其居住者的状态以及该属性的价值相关)。每个需求都有自己的优先级，但它们必须都得到满足。
在许多应用计算机工程领域中，人们不大重视安全。一些项目只是轻描淡写地提到了安全，这使安全无法成为真正的工程实践要求。这样很糟糕。软件的复杂性是毋庸置疑的——现代操作系统，甚至是现代网络浏览器，都比航天飞机复杂得多。航天飞机可以杀人，但带有极少的几个异常的软件却不会杀人。所以，安全的基本核心——“正确”，从来都没有成为软件的明确设计规则，更不用说成为根本的设计规则了。于是，软件中对安全的这种漠视使我们不得不忍受大量的重复设计(往好听了说)或错误(往难听了说)。毕竟，无论软件编写得多糟糕，在几乎所有的情况下，都不会有人因此丢掉性命。
破产则完全是另一回事，并不是只有人才会死，公司也会消亡。
计算机安全研究已经持续了数十年，但直到2000年以后，不安全软件的后果才最终为外界所知。2003年“夏虫”(the Summer of Worms)肆虐——简言之，几个恶意操作使整个商业界的IT资源完全不可靠达到3个月之久，2006年出了TJX事件——攻诌者利用无线天线光顾了T．J．Maxx，盗走了大量的信用卡账产。2008年，攻击率再创新高，据Verizon Business报告，2008年受到威胁的个人财务记录超过了2004、2005、2006和2007年的总和。
人们仍没有醒悟。“正确”还是没有受到人们的重视，却得到寄生虫的青睐——这些坏家伙远程闯入系统，利用不正确的代码绕过安全设施、盗取财物。对于用户和公司来说，这都是一个非常显著的问题。
事情这么糟糕，而工程师看到了什么?
一天结束时，地位低的开发人员必须把他听到的所有命令都转换为代码。软件有许多工程要求：性能、可用性、可靠性等。这些要求都有一个非常重要的特点：如果这些要求没有满足，它们就会变成非常明显的问题。可是，安全问题却没有那么明显。
考虑下面的情形：
假定软件有一个性能问题。甚至未受过培训的工程师都会注意到，某个操作需要执行很长时间。为了解决这个问题，工程师可以使用标准的数据集，找出运行过于频繁的代码块。为了检查修复的代码块是否有效，可以在应用修复代码块的前后使用己知的数据集，很容易看出执行过程需要的时间减少了。
假定软件有一个可用性问题，这比较难修复——工程师一般知道如何管理他们自己的系统，但用户不知道，用户只能立即让技术支持人员和销售人员知道系统出问题了。为了解决这个问题，工程师可以建立新的部署指南，对用户难以手工维护的组件自动化。为了检查修复的部分是否有效，可以给用户发送一个测试版，用户可以报告该测试版是否有效。
最后，假定软件有一个可靠性问题。它崩溃了!很难找出比这个更明显的问题。崩溃报告可以在开发期间发出，如果不在开发期间发出崩溃报告，则在软件发布后，崩溃报告可能由某个愤怒的用户那里手工发出，或者通过Windows错误报告自动收集和排序。
而用户告诉工程师，希望软件运行得更快、更可靠或更稳定时，用户可能并不确切地知道工程师会如何修复问题，但至少知道要工程师做什么。
但是，如果用户要求工程师编写出更安全的代码时，知道工程师会做什么吗?
这并不像是不言而喻的。实际上，除了偶尔的数据被破坏而导致可见的崩溃之外，大多数安全漏洞对可靠性都没有影响。更糟糕的是，《不堵住这些漏洞对性能和可用性有正面的影响。实际上，世界上大多数不安全的系统部实现了它们的诺言——只要所有的事情都是按照工程师的设计宋发生的。
但现实并没有这么友好，部署环境也不是工程师可以完全控制的——计算机工程师、土木工程师和机械工程师都不能。土木工程师和机械工程师都要考虑如何应对地球上对安全有直接威胁的一些意外事件。但即使是土木工程师和机械工程师所设计的系统，也很容易测试一些比较规范的问题：地震?每个人部很熟悉摇动某件东西的场景。火灾?可以划着一根火柴。水灾?把系统放在浴缸里，看看会发生什么。
安全?这需要请一位世界级的黑客来，问问他看到了什么。一般的计算机工程师更了解使办公大楼倒塌的原因，而不清楚自己编写的代码是如何被滥用的。毕竟，他的父母是告诉过他不要玩火，那么告诉过他不要玩格式字符串吗?
我们有很长的路要走。
本书非常重要的原因是，它出自两位业界经验最丰富的专家之手，工程师通过本书能理解编写安全代码的具体含义。本书反映了在代码发布后多年，Michael Howard和David LeBlanc与开发人员一起奋战，告诉他们出了什么问题，并解决这些问题所积累的经验。修复发布之后的代码的代价，无论怎样强调都不过分。NIST研究表明，从头开始编写新代码要比修复发布之后的代码便宜许多。修复发布之后的代码的过程很痛苦：必须切换到旧的代码基，重复所有的旧测试(记住，所有的代码仍必须执行良好、可用、稳定)，再发布新代码，并确保新发布的代码部署到合适的位置上，等等。
为了使软件安全的成本可以接受，最终使软件能成功发布，我们必须从一开始就考虑到软件的安全。工程师应对安全要求做出合适的反应，这需要他们理解安全要求的含义以及满足安全要求意味着什么。本书的主要任务是讲述这些知识，将上述安全要求表达清楚，而不是让工程师“雇佣一位黑客”或者“像黑客那样想问题”。本书提供了这方面的指导。
所有的工程系统都有指导性需求——它们已成为可测量的要素，如果达不到这些要求，系统就会失败。例如，大楼必须是安全的(不能倒塌!)，但这还不够，大楼还必须是可用的(里面的空间可以使用)、能盖得起来、可以维护(建筑和维护的成本必须使大楼在投入使用后可以盈利)，最后，大楼还应有一定的吸引力(大楼的外观与其居住者的状态以及该属性的价值相关)。每个需求都有自己的优先级，但它们必须都得到满足。
在许多应用计算机工程领域中，人们不大重视安全。一些项目只是轻描淡写地提到了安全，这使安全无法成为真正的工程实践要求。这样很糟糕。软件的复杂性是毋庸置疑的——现代操作系统，甚至是现代网络浏览器，都比航天飞机复杂得多。航天飞机可以杀人，但带有极少的几个异常的软件却不会杀人。所以，安全的基本核心——“正确”，从来都没有成为软件的明确设计规则，更不用说成为根本的设计规则了。于是，软件中对安全的这种漠视使我们不得不忍受大量的重复设计(往好听了说)或错误(往难听了说)。毕竟，无论软件编写得多糟糕，在几乎所有的情况下，都不会有人因此丢掉性命。
破产则完全是另一回事，并不是只有人才会死，公司也会消亡。
计算机安全研究已经持续了数十年，但直到2000年以后，不安全软件的后果才最终为外界所知。2003年“夏虫”(the Summer of Worms)肆虐——简言之，几个恶意操作使整个商业界的IT资源完全不可靠达到3个月之久，2006年出了TJX事件——攻诌者利用无线天线光顾了T．J．Maxx，盗走了大量的信用卡账产。2008年，攻击率再创新高，据Verizon Business报告，2008年受到威胁的个人财务记录超过了2004、2005、2006和2007年的总和。
人们仍没有醒悟。“正确”还是没有受到人们的重视，却得到寄生虫的青睐——这些坏家伙远程闯入系统，利用不正确的代码绕过安全设施、盗取财物。对于用户和公司来说，这都是一个非常显著的问题。
事情这么糟糕，而工程师看到了什么?
一天结束时，地位低的开发人员必须把他听到的所有命令都转换为代码。软件有许多工程要求：性能、可用性、可靠性等。这些要求都有一个非常重要的特点：如果这些要求没有满足，它们就会变成非常明显的问题。可是，安全问题却没有那么明显。
考虑下面的情形：
假定软件有一个性能问题。甚至未受过培训的工程师都会注意到，某个操作需要执行很长时间。为了解决这个问题，工程师可以使用标准的数据集，找出运行过于频繁的代码块。为了检查修复的代码块是否有效，可以在应用修复代码块的前后使用己知的数据集，很容易看出执行过程需要的时间减少了。
假定软件有一个可用性问题，这比较难修复——工程师一般知道如何管理他们自己的系统，但用户不知道，用户只能立即让技术支持人员和销售人员知道系统出问题了。为了解决这个问题，工程师可以建立新的部署指南，对用户难以手工维护的组件自动化。为了检查修复的部分是否有效，可以给用户发送一个测试版，用户可以报告该测试版是否有效。
最后，假定软件有一个可靠性问题。它崩溃了!很难找出比这个更明显的问题。崩溃报告可以在开发期间发出，如果不在开发期间发出崩溃报告，则在软件发布后，崩溃报告可能由某个愤怒的用户那里手工发出，或者通过Windows错误报告自动收集和排序。
而用户告诉工程师，希望软件运行得更快、更可靠或更稳定时，用户可能并不确切地知道工程师会如何修复问题，但至少知道要工程师做什么。
但是，如果用户要求工程师编写出更安全的代码时，知道工程师会做什么吗?
这并不像是不言而喻的。实际上，除了偶尔的数据被破坏而导致可见的崩溃之外，大多数安全漏洞对可靠性都没有影响。更糟糕的是，《不堵住这些漏洞对性能和可用性有正面的影响。实际上，世界上大多数不安全的系统部实现了它们的诺言——只要所有的事情都是按照工程师的设计宋发生的。
但现实并没有这么友好，部署环境也不是工程师可以完全控制的——计算机工程师、土木工程师和机械工程师都不能。土木工程师和机械工程师都要考虑如何应对地球上对安全有直接威胁的一些意外事件。但即使是土木工程师和机械工程师所设计的系统，也很容易测试一些比较规范的问题：地震?每个人部很熟悉摇动某件东西的场景。火灾?可以划着一根火柴。水灾?把系统放在浴缸里，看看会发生什么。
安全?这需要请一位世界级的黑客来，问问他看到了什么。一般的计算机工程师更了解使办公大楼倒塌的原因，而不清楚自己编写的代码是如何被滥用的。毕竟，他的父母是告诉过他不要玩火，那么告诉过他不要玩格式字符串吗?
我们有很长的路要走。
本书非常重要的原因是，它出自两位业界经验最丰富的专家之手，工程师通过本书能理解编写安全代码的具体含义。本书反映了在代码发布后多年，Michael Howard和David LeBlanc与开发人员一起奋战，告诉他们出了什么问题，并解决这些问题所积累的经验。修复发布之后的代码的代价，无论怎样强调都不过分。NIST研究表明，从头开始编写新代码要比修复发布之后的代码便宜许多。修复发布之后的代码的过程很痛苦：必须切换到旧的代码基，重复所有的旧测试(记住，所有的代码仍必须执行良好、可用、稳定)，再发布新代码，并确保新发布的代码部署到合适的位置上，等等。
为了使软件安全的成本可以接受，最终使软件能成功发布，我们必须从一开始就考虑到软件的安全。工程师应对安全要求做出合适的反应，这需要他们理解安全要求的含义以及满足安全要求意味着什么。本书的主要任务是讲述这些知识，将上述安全要求表达清楚，而不是让工程师“雇佣一位黑客”或者“像黑客那样想问题”。本书提供了这方面的指导。
加载中...
