2023软件安全开发V3.0.2

PAGE193《软件安全开发》V3.0.2目录第1章 软件安全概述 11.1软件 11.1.1软件定义 11.1.2软件分类 11.2软件安全 31.2.1软件安全概述 31.2.2软件安全范畴 41.2.3软件安全问题 51.3本书的结构与内容 11第2章软件安全开发模型 132.1软件开发模型 132.1.1瀑布型软件开发模型 132.1.2渐增型软件开发模型 142.1.3变换型软件开发模型 152.2常用软件开发方法 152.3安全开发模型 172.4微软安全开发生命周期模型 182.4.1安全生命周期模型（SDL） 182.4.2SDL优化模型 192.4.3SDL安全人员角色 202.4.4SDL模型安全活动 212.4.5培训阶段 232.4.6需求阶段 242.4.7设计阶段 252.4.8实施阶段 262.4.9验证阶段 262.4.10发布和响应阶段 272.4.11可选的安全活动 282.5McGraw软件安全开发模型 292.6NIST安全开发生命周期模型 332.6.1开始阶段 342.6.2获取与开发阶段 352.6.3执行阶段 372.6.4操作和维护阶段 372.6.5部署阶段 38第3章安全漏洞管理 403.1概述 403.1.1漏洞分类 403.1.2漏洞等级 423.1.3漏洞管理流程 443.1.4漏洞管理机制 453.2安全内容自动化协议（SCAP） 473.2.1SCAP及其元素 483.2.2可扩展配置检查列表描述格式XCCDF 503.2.3开放漏洞评估描述语言OVAL 513.2.4通用漏洞和披露列表CVE 523.2.5通用平台枚举CPE 523.2.6通用配置枚举CCE 533.2.7通用漏洞评分系统CVSS 543.3典型软件安全漏洞 543.3.1缓冲区溢出漏洞 553.3.2整数溢出漏洞 583.3.3格式化字符串漏洞 593.3.4指针覆盖漏洞 623.3.5SQL注入漏洞 623.3.6ByPass漏洞 643.3.7信息泄露漏洞 653.3.8越权漏洞 653.4OWASPTop10 663.4.1注入攻击 663.4.2失效的身份认证和会话管理 683.4.3跨站脚本–XSS 703.4.4不安全的直接对象引用 723.4.5安全配置错误 743.4.6敏感数据暴露 763.4.7功能级别访问控制缺失 773.4.8跨站请求伪造（CSRF） 783.4.9使用已知易受攻击组件 803.4.10未验证的重定向和转发 81第4章安全功能设计 834.1安全审计 844.1.1安全审计自动响应 854.1.2安全审计数据产生 854.1.3安全审计分析 874.1.4安全审计查阅 884.1.5安全审计事件选择 894.1.6安全审计事件存储 904.2安全通信 914.2.1原发抗抵赖 924.2.2接收抗抵赖 934.3密码支持 954.3.1密钥管理 964.3.2密码运算 994.4用户数据保护 1004.4.1访问控制 1034.4.2数据流控制 1054.4.3数据鉴别 1094.4.4系统内部传送 1104.4.5残余信息保护 1124.4.6回退 1134.4.7存储数据的完整性 1144.5标识和鉴别（身份认证） 1154.5.1用户鉴别 1164.5.2用户标识 1194.5.3鉴别失败 1204.5.4用户属性定义 1214.5.5秘密的规范 1214.5.6主体-用户绑定 1224.6安全管理 1234.6.1功能的管理 1234.6.2安全属性的管理 1244.6.3数据的管理 1264.6.4安全管理角色 1274.7隐私保护 1284.7.1匿名 1294.7.2假名 1294.7.3不可关联性 1314.7.4不可观察性 1324.8安全功能的保护 1334.8.1底层抽象机测试 1364.8.2失效保护 1374.8.3安全功能数据的可用性 1374.8.4安全功能数据的保密性 1384.8.5安全功能数据的完整性 1394.8.6内部数据传送 1404.8.7物理保护 1414.8.8可信恢复 1434.8.9重放检测 1464.8.10引用仲裁 1474.8.11域分离 1484.8.12状态同步协议 1494.8.13时间戳 1504.8.14对外数据一致性 1514.8.15内部数据复制一致性 1524.8.16安全功能自检 1524.9资源利用 1534.9.1容错 1544.9.2服务优先级 1554.9.3资源分配 1564.10系统/子系统的访问 1574.10.1可选属性范围限定 1584.10.2多重并发会话限定 1594.10.3会话锁定 1604.10.4访问旗标 1624.10.5访问历史 1624.10.6会话建立 1634.11可信路径/信道 1644.11.1安全功能之间的可信信道 1654.11.2可信路径 165第5章 常见安全问题 1675.1概述 1675.2常见编程安全问题分类 1675.3常见编程安全问题 1695.3.1整数赋值错误问题 1695.3.2整型提升导致的内存溢出错误 1695.3.3临时变量溢出 1705.3.4整数截断错误问题 1705.3.5整数溢出问题 1715.3.6带符号与无符号整型比较问题 1715.3.7size_t导致的死循环 1725.3.8误用short引起缓冲区溢出 1735.3.9表达式中对同一变量多次写入问题 1745.3.10空字符结尾错误问题 1745.3.11无界字符串复制问题 1755.3.12定长字符串越界问题 1765.3.13字符串截断问题 1785.3.14与函数无关的字符串错误问题 1795.3.15修改字符串常量错误问题 1805.3.16字符串比较错误 1805.3.17数组越界问题 1815.3.18数组定义和值初始化括号形式混淆错误 1825.3.19未正确区分标量和数组问题 1835.3.20二维数组的内存泄露 1845.3.21释放指针指向的对象引起内存泄漏 1845.3.22数据指针被修改问题 1865.3.23函数指针被修改问题 1865.3.24删除void*指针错误 1885.3.25printf函数输出问题 1895.3.26格式化函数sprintf引起缓冲区溢出 1895.3.27指针变量的传值和传址混淆问题 1905.3.28验证方法参数问题 1915.3.29函数退出时内存未释放问题 1925.3.30continue和return混淆问题 1925.3.31非void返回类型函数问题 1935.3.32误用sizeof操作符取字符串长度 1955.3.33基类未定义虚析构函数引发错误 1955.3.34线程未join引起的内存泄露 1975.3.35notify线程唤醒问题 1985.3.36多线程中Socket终止问题 1995.3.37程序异常退出时未关闭已打开文件 2015.3.38目录打开后未关闭 2025.3.39写文件没有调用fflush 2025.3.40临时文件未删除问题 2035.3.41敏感信息硬编码问题 2045.3.42引用未初始化的内存错误问题 2065.3.43检查和处理内存分配错误问题 2065.3.44执行零长度的分配错误问题 2075.3.45引用已释放内存的错误问题 2085.3.46双重释放内存错误问题 2095.3.47不匹配的内存管理函数问题 2095.3.48匿名对象引起的内存泄漏 2105.3.49JVM内存泄漏问题 2115.3.50覆盖equals方法而没有覆盖hashCode方法问题 2125.3.51finally程序段非正常退出问题 2145.3.52非泛型的数据类型问题 2155.3.53类名称比较问题 2155.3.54等同的对象得不到相等的结果问题 2165.3.55在嵌套类中暴露外部类的私有字段问题 2175.3.56静态方法隐藏问题 2185.3.57构造函数中抛出异常引发错误 2195.3.58构造器调用可覆盖方法问题 2205.3.59字符乱码问题 2225.3.60功能级别访问控制缺失问题 2225.3.61表单重复提交问题 2255.3.62不安全的直接对象引用问题 2275.3.63信息的不安全存储问题 2285.3.64SQL注入攻击 2295.3.65失效的身份认证和会话管理问题 2315.3.66跨站脚本（XSS） 232第6章 安全编码实践 2346.1输入验证和数据合法性校验 2346.1.1输入数据有效性校验 2346.1.2避免SQL注入 2356.1.3避免XML注入 2356.1.4避免跨站点脚本（XSS） 2356.2声明和初始化 2366.2.1避免类初始化相互依赖 2366.3表达式 2376.3.1勿忽略方法返回值 2376.3.2勿引用空指针 2376.3.3比较数组内容 2386.4数值类型和操作 2386.4.1防止整数溢出 2386.4.2避免除法和取模运算分母为零 2396.5类和方法操作 2406.5.1数据成员声明为私有且提供可访问的包装方法 2406.5.2敏感类不允许复制 2406.5.3比较类的正确做法 2416.5.4不要硬编码敏感信息 2416.5.5验证方法参数 2426.5.6勿使用过时或低效的方法 2426.5.7数组引用问题 2426.5.8勿产生内存泄露 2436.6异常处理 2446.6.1不要忽略捕获的异常 2446.6.2不允许暴露异常的敏感信息 2456.6.3不允许抛出RuntimeException、Exception和Throwable 2466.6.4不要捕获NullPointerException或其他父类异常 2466.7多线程编程 2476.7.1确保被并发调用函数的可重入性 2476.7.2函数线程安全 2496.7.3确保共享变量的可见性 2506.7.4确保共享变量的操作是原子的 2516.7.5Thread.run（）和Thread.stop（） 2526.7.6确保执行阻塞操作的线程可以终止 2536.7.7不在一个有限的线程池执行相互依存的任务 2546.8输入输出 2546.8.1程序终止前删除临时文件 2546.8.2检测和处理文件相关错误 2556.8.3及时释放资源 2566.9序列化 2566.9.1不要序列化未加密的敏感数据 2576.9.2在序列化过程中避免内存和资源泄漏 2576.9.3反序列化要在程序最小权限的安全环境中 258第7章 软件安全测试 2597.1软件安全测试方法 2597.2软件安全测试过程 2607.3软件安全测试组织 2617.4软件安全测试举例 2627.4.1系统测试概要 2637.4.2系统测试结果 2647.4.3系统安全建议 273参考文献 275附录A测试工具 2761源代码分析器——SourceCodeAnalysis（FortifySCA） 2772字节码扫描器——FindBugs 2783数据库脆弱性扫描器——DatabaseScanner 2794网络漏洞扫描器——NTOSpider 2805网络漏洞扫描器——Metasploit 2816Web应用漏洞扫描器——AppScan 2867Web应用漏洞扫描器——JSky 2898Web应用漏洞扫描器——WVS 2919Web服务扫描器——SOATest 29310动态分析工具——CLRProfiler 29411设计验证工具——SDMetrics 295软件安全概述1.1软件1.1.1软件定义软件与硬件一起组成了完整的计算机系统。1983年美国电气和电子工程师协会IEEE（InstituteofElectricalandElectronicsEngineers）给出的软件的定义是“计算机程序、方法、规则和相关文档资料以及在计算机上运行时所需的数据。”目前，对软件通俗的解释是：软件=程序+数据+文档资料。其中：程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档资料是与程序开发、维护和使用有关的图文材料。软件已成为现代社会基础设施的要素，对人们的生活和工作都产生了深远的影响。为了能全面、正确地理解软件，必须了解软件的特点。软件是一种逻辑实体。对于软件来说，用户无法看到它的形态，而必须通过观察、分析、思考、判断去了解它的功能、性能及其他特性。软件是智力活动的产品。软件开发过程中没有明显的制造过程。软件是通过人们的智力活动，把知识与技术转化成信息的一种产品。软件在运行和使用期间不存在磨损和老化问题。软件的研发工作需要投入大量复杂的高强度脑力劳动，往往成本极高。软件的复杂度随着规模的增大而迅速增加。软件系统各个模块之间有各种逻辑联系，一起运行于同一个系统空间，模块越多，相互的影响和关联也就越复杂，导致整个软件的复杂度随着规模增大而成指数级增长。1.1.2软件分类到目前为止，软件尚无统一的分类。典型的分类方式包括按功能、规模和服务对象进行分类。一般来说，要给计算机软件做出科学的分类是很难的。但鉴于不同类型的工程对象，对其进行开发和维护有着不同的要求和处理方法，仍然需要对软件的类型进行必要的划分。按软件的功能划分按照软件的功能进行划分，软件可分为系统软件、支撑软件和应用软件三类。系统软件：系统软件是计算机运行的必不可少的组成部分，它与计算机硬件紧密配合在一起，控制并协调计算机系统各个部件、相关的软件和数据高效地工作。系统软件通常包括操作系统、数据库管理系统、设备驱动程序以及通信处理程序等。支撑软件：包括系统支撑平台软件和应用支撑平台软件。支撑软件是协助用户开发软件的工具性软件，其中包括帮助程序人员开发软件产品的工具，也包括帮助管理人员控制开发进程的工具。应用软件：应用软件是指在特定领域内开发，为特定目的服务的软件。目前，计算机已经成为大多数日常工作的必须工具，在很多应用领域都需要专门的软件支持，在这些种类繁多的应用软件中，商业数据处理软件所占比例最大，此外还有工程与科学计算软件、系统仿真软件、计算机辅助设计（ComputerAidedDesign，CAD）软件、人工智能软件及各类办公自动化软件和信息处理软件等。按软件的规模进行划分按软件规模分类（此处数据并无明确结论，仅供参考）即按照开发软件所需的人力、物力、时间以及完成的源程序行数进行分类，可将软件分为微型、小型、中型、大型、极大型、巨大型，如表1-1所示。表1-1软件的规模的分类类别参加人数研制期限产品规模（源程序行数）微型软件11周～1月5百小型软件11～6月2千中型软件2～51～2年0.5～5万大型软件5～152～3年5～10万极大型软件100～10004～5年1百万巨大型软件2000～50005～10年0.1～1千万1）微型软件：只有一个人，甚至是半时，在几天之内完成的软件。写出的程序不到500行语句；2）小型软件：一个人半年之内完成的2000行以内的程序。例如，数值计算问题或是数据处理问题这种规模的课题。这种程序通常没有与其他程序的接口;3）中型软件：5人以内在1～2年时间内完成的0.5～5万行的程序。这种课题开始出现在软件人员之间，软件人员与用户之间的联系、协调和配合关系的问题;4）大型软件：5～15人在2～3年时间里完成5万行～10万行的程序。例如编译程序、小型分时系统、应用软件包、实时控制系统等软件;5）极大型软件：100～1000人参加在4～5年时间里完成100万行以上的程序;6）巨大型软件：2000～5000人参加在5～10年的时间里完成1000万行以上程序。3、按软件服务对象划分按软件服务对象的范围，可将软件划分为面向市场广大用户的软件产品和面向部分客户软件项目。通用软件：指的是不局限于特定领域的、可以被广大用户直接使用的软件系统。如Windows、Office、WPS等。这类系统的特点是技术含量高，开发时要考虑到各种不同的用户需求。2）定制软件：是受某个特定客户（或少数客户）的委托，由一个或多个软件开发机构在合同的范围内进行开发的软件，如我们常说的管理信息系统和电子商务系统。这类软件的特点是领域知识所占的比重较大，相对技术而言工程性更强，如政府办公系统、ERP系统、监控系统等。1.2软件安全1.2.1软件安全概述软件安全（SoftwareSecurity）是指将开发的软件存在的风险控制在可接受的水平，以保证软件的正常运行。由于软件存在漏洞是必然的，而这些漏洞有现存的攻击方法，并且这些方法可以被利用来破坏一种或更多软件的安全性能，或迫使软件运行到不安全的状态。因此，软件很容易成为攻击目标。安全的软件是指即使它的安全性受到蓄意危害时仍然保持安全可靠运行。那么如何评判一个软件是否足够安全？著名的软件安全专家JuliaH.Allen给出了一个安全的软件需要满足的属性，这些属性是软件安全的重要因素。主要包括以下几种：1）机密性。软件必须确保其特性（包括运行环境和用户之间的联系）、资源管理和内容对未授权实体隐藏。这一点对于开源软件来说也仍然适用，尽管开源软件的特性和内容都可以公开使用（对授权实体），但其仍然要维持其资源管理的机密性。2）完整性。软件及其管理的资源必须能够抵御入侵（覆盖、删除、修改等）并能从中恢复。入侵破坏一般由未授权的修改引起，这些修改针对软件源代码、受管理的资源、配置或者授权用户的合法操作，包括重写、覆盖、篡改、破坏、插入等，在软件开发过程中必须保证其完整性。3）可用性。软件必须对授权用户（人或进程）开放，即可操作和运行，而对未授权用户关闭。相反，对于未授权的用户应该永远关闭，既不可操作和运行。4）可追溯性。所有与安全相关的软件行为都必须跟踪与记录，并进行责任归因。5）抗抵赖性。这一属性是指软件防止用户否认执行了某些行为的功能，以保证可追踪性不受到破坏。上述安全属性是紧密相关的，很难在不考虑其他属性的情况下达到其中一个属性的满足。比如用户的系统账户被人窃取，即意味着机密性的丧失，而完整性也必然得不到保障。为了从应用软件的数据库中提取个人的相关信息而进行的一次成功的SQL注入攻击，违背了软件的机密性。一次针对Web应用的跨站脚本（Cross-SiteScripting，XSS）攻击同时违背了软件的完整性和可用性。许多其他的重要软件特性隐含软件安全的特性，其间的关联通常能被描述为这些特性如何影响软件安全范畴内的属性。由于我们越来越依赖软件来解决关键性的工作，这使得软件成为那些带有恶意、犯罪、敌对、竞争心理的或带恐怖主义性质的攻击者的高价值攻击目标，所以设计安全的软件很重要。而且McGraw博士提出“使安全成为软件开发必需的部分（BuildSecurityIn,BSI）”的观点，已经得到工业界和政府部门的广泛认同，美国国土安全部下属的国家网络安全处（NationalCyberSecurityDivision,NCSD）专门建立了BSI网站（/portal），并与美国国家标准技术研究所（TheNationalInstituteofStandardsandTechnology,NIST）、国际标准化组织（InternationalOrganizationforStandards,ISO）以及电气工程师协会（InstituteofElectricalandElectronicsEngineers,IEEE）一起共同维护这个网站。1.2.2软件安全范畴软件的安全问题已经出现多年，随着软件系统的不断增加和越来越复杂，使得安全的潜在隐患不断增多。在确定软件安全特征并找到有效的改善方法之前，我们必须首先了解软件安全的具体范畴。根据软件的定义可知，软件安全的范畴主要包括数据的安全性、程序的安全性以及文档资料的安全性三大方面：1）数据安全：数据安全可定义为“保持数据的机密性，完整性，可用性；另外也可包括诸如真实性，可核查性，不可否认性和可靠性等”。数据安全包括两方面：一是数据本身的安全，主要是指采用现代密码算法对数据进行主动保护，主要解决了数据保密性、数据完整性、可追溯性、抗抵赖性等安全属性等；二是数据防护的安全，主要是采用现代信息存储手段对数据进行主动防护，例如通过磁盘阵列、数据备份、异地容灾等手段主要保证了数据的可用性、完整性、可靠性等安全属性。2）程序安全：程序安全主要指在软件开发周期中的代码安全，是贯穿在整个开发周期的软件安全保障。程序安全包括架构设计安全和编码测试安全两方面，软件工程师要尽量使用健全的和已经验证为安全的开发工具来进行代码编写以减少软件实现时的漏洞，并使用静态源码分析攻击，进行源码审查和人工审查方式来减少安全漏洞，除此之外，要使用大量的安全测试策略来检验程序是否安全，包括白盒测试（基于对源码的深度理解）、黑盒测试（关注软件可见的外部行为）、渗透测试（在系统级别识别特殊的漏洞）。3）文档资料安全：文档资料安全指在软件开发过程中对于软件需求规格说明书、设计文档等安全管理，即避免在开发周期的任意时候蓄意地删除，新增和修改文档资料来破坏软件。由于文档资料对于软件开发者和使用者了解程序功能、代码作用、程序的测试过程等具有十分重要的作用，所以对文档资料的保护要与程序和数据同步进行。1.2.3软件安全问题由于软件已成为那些带有恶意、犯罪、敌对、竞争心理的，甚至带恐怖主义性质的攻击者的高价值攻击目标，因此软件安全问题已经成为上到国家下到个人的关键问题。本节中主要介绍软件安全漏洞，软件生命周期中的安全问题以及软件安全问题产生的原因。软件安全漏洞软件安全漏洞指在计算机程序、系统或协议中存在的安全漏洞，它已成为被攻击者用来非法侵入他人系统的主要渠道。对于软件的安全漏洞问题，面对“如何开发出具有高安全性软件”与“如何利用软件漏洞进行攻击”，安全防护人员和黑客始终处于不断相互较量的过程中。根据著名的咨询公司GartnerResearch的报告，对于企业网络的攻击，超过70%来自软件和应用层，而不是网络层或系统层。软件和应用层的漏洞的数目在各种环境中都在增加。而来自NIST的数据更为惊人，有92%被发现的漏洞属于应用层。这些数据表明，目前绝大部分的黑客攻击都是利用了应用软件的安全漏洞实现的，而这些安全漏洞往往是由于软件开发人员在编码时的疏漏造成的。在面对恶意攻击时，软件的安全漏洞是普遍存在的，并且有可能导致严重风险，所以软件安全漏洞是最危险的安全问题之一。在过去十年里，软件安全漏洞这个问题变得越来越严重，图1-1显示了从2003年至2013年中国国家信息安全漏洞库（ChinaNationalVulnerabilityDatabaseofInformationSecurity,CNNVD）统计的软件漏洞数量变化情况。从图中可以看出十年内漏洞数量呈增长趋势，并且在以后的时间里这一趋势不会有很大的改变。而且CNNVD根据漏洞的影响等级范围、利用方式、攻击后果等，对漏洞危害进行了量化评分。并将漏洞分为4个等级，即危急（CNNVD评分为10分）、高危（7.0~9.9分）、中危（4.0~6.9分）和低危级别（0.0~3.9分）。图1-12003～2013年软件漏洞数量分布图目前，软件中安全漏洞的种类非常繁多，它们彼此之间都有一些共同的特点和模式。常见的8种软件安全中漏洞如下：（1）缓冲区溢出漏洞。严格的讲，当程序允许输入的数据大于已分配的缓冲区大小时，就会产生缓冲区溢出。缓冲区溢出造成的后果小到系统崩溃，大到攻击者完全控制程序。并且，如果运行该程序的用户拥有较高的权限，攻击者还可以控制整个操作系统。如果出现此漏洞的应用程序是一个网络服务，那么将会造成蠕虫病毒的产生并蔓延。第一个著名的Internet蠕虫病毒——RobertT.Morris蠕虫病毒，就利用了finger服务器上的一个缓冲区溢出漏洞进行攻击。在1988年，一次缓冲区溢出攻击差点使Internet瘫痪，之后，虽然我们似乎明白该如何避免缓冲区溢出，但是在许多种类的软件中仍旧能常常见到有关缓冲区溢出漏洞的报告。而且即使很优秀、很细心的程序员也会出现缓冲区溢出漏洞，但是优秀的程序员知道如何有效的避免这种漏洞，以及如何进行有效的测试来找出这种漏洞。（2）整数溢出漏洞对于不同语言，整数溢出漏洞的表现形式也有细微差别。自计算机编程出现之后，整数上溢、下溢以及各种类型的溢出就已经存在了。简单的栈粉碎攻击被堆攻击普遍替代后，整数溢出就变成了一个安全研究的主题。利用整数溢出进行攻击尽管存在一段时间了，但直到最近几年，整数溢出才因许多安全问题报告的出现而真正浮出水面。（3）格式化字符串漏洞格式化字符串漏洞是近年来新出现的少数几种攻击类型之一。第一个涉及格式化字符串攻击的漏洞是由LamagraArgamal于2000年6月23日发布的（/archive/1/66842）。大约1个月之后，PascalBouchareine更详细的解释了这类问题（/archive/1/10383），但是没有将输入和利用格式化字符串漏洞来写入内存。像其他安全漏洞一样，格式化字符串漏洞的根源在于未对用户提供的输入进行验证。在C/C++中，格式化字符串攻击可以用来向任意内存写入数据，最危险的是这种漏洞发生时不会改变临界内容块的内容。这种情况在UNIX和Linux系统上更为普遍。在Windows系统上，应用程序字符串表通常保存在可执行程序中，或者DLL（DynamicLinkLibraries，动态链接库）中。如果攻击者可以重写主执行程序或者资源DLL，就可以执行比格式化字符更为直接的攻击，因为它们可以修改正在运行的代码。（4）指针覆盖漏洞指针覆盖漏洞指由于程序在运行中往往会将来自于程序外部的数据也存放进入内存中，如果某些数据恰好覆盖了程序的指针，那么程序的执行流程就会被这些外部数据所控制。指针覆盖漏洞类似于缓冲区溢出漏洞，但是范围则更广泛一些，外部数据不仅可以覆盖程序的函数返回地址，还可能覆盖程序运行中其他的关键地址。如程序正在调用指令callecx，此时，ecx寄存器中的数据来源于内存中的某个地址。一旦程序发生指针覆盖漏洞，ecx索取数据的这个内存地址被一个执行ShellCode代码的地址所覆盖，那么程序一旦调用callecx指令，ShellCode就会马上被执行。指针覆盖漏洞可能是最近几年软件安全中出现最多的漏洞。尤其近几年CPU硬件设计者采用的一些硬件级别的防止缓冲区溢出漏洞的方法，更加使得缓冲区溢出漏洞难以被利用。（5）SQL注入漏洞SQL注入漏洞是Web系统特有的一类漏洞，源于PHP、ASP等脚本语言对用户输入数据的错误解析。网站开发程序员在编写代码时，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。以PHP语言为例，如果用户的输入能够影响到SQL命令串的生成，那么很可能再添加了单引号、#号等转义命令字符后，能够改变数据库最终执行的SQL命令。（6）ByPass漏洞Bypass漏洞是一个大类，包含了很多小类，这些小类有一个共同的特点，就是这些出现问题的软件都在功能上存在对用户的限制，而Bypass漏洞就可以绕过软件的限制，使得软件的限制形同虚设。Bypass漏洞不但可以让普通软件的限制功能作废，还可能造成某些软件安全功能完全形同虚设。（7）信息泄露漏洞信息泄露漏洞实际上指攻击者获取了可以破坏安全或隐私策略的数据，而不管是采取显式的还是隐式的手段。数据本身可能就是攻击者的目标，或者数据提供的信息可以使攻击者达到他们的目的。信息泄露的后果有时候不是很明显，但是这个漏洞有时会使用弱权限或访问控制表来放大。（8）越权型漏洞越权型漏洞是一个设计问题，当发生故障时，攻击者可以利用这个漏洞制造更危险的事故，软件会在其生命周期的某个时候失效，如果其代码失效了，但允许攻击者运行恶意代码，这些代码的运行通常会把权限赋予易受攻击的进程。例如，如果某进程用Administrator或root权限来运行，且这段代码中有一个导致执行任意代码的整数溢出漏洞，则恶意代码也会运行为Administrator或root。另一个实例是攻击者访问不应访问的数据，当危及安全的代码用足以访问数据的权限来运行时，就可以访问不该访问的数据。软件安全漏洞会影响软件安全的运行，这是一个不争的事实。这些漏洞可以被利用而影响到软件的安全属性并且迫使软件运行到一个不安全的、可被利用的状态。考虑到基于软件的系统广泛的连接能力和其复杂度爆炸性地增长，软件安全处理这些漏洞将是一个十足的挑战。软件生命周期中的安全问题软件产品同任何其他事物一样，也要经历孕育、诞生、成长、成熟、衰亡等各个阶段，在软件工程中一般将上述过程称为软件的生命周期。通过将整个软件生命周期划分为若干阶段，使得每个阶段都有明确的任务和目标，进而使得规模大，结构复杂和管理复杂的软件开发变的易于控制和管理。通常，软件生命周期包括可行性分析与项目开发计划、需求分析、设计、编码、测试、维护等活动，通常，可以将这些活动以适当的方式分配到不同的阶段去完成。这种按时间分配不同任务的思想方法是软件工程中的一种重要思想原则，即按部就班、逐步推进,每个阶段都要有各自的定义、工作、审查、形成文档以便工作交流或备查，进而达到提高软件质量的目的。目前，按照软件开发生命周期的思想进行软件设计和开发的理念已经得到广大软件设计和开发人员的广泛认同，但是在软件开发生命周期中对安全性的考虑则往往被忽略，进而产生了很多的软件产品漏洞，给使用软件产品的人们带来很多工作生活上的不便，甚至造成巨大的经济损失。在软件生命周期的各个阶段，如果缺乏良好的安全意识，则可能给软件产品带来如表1-2所示的各种安全问题。表1-2软件开发生命周期中可能给软件带来的安全问题软件开发生命周期各阶段各阶段安全问题需求分析阶段没有明确用户对安全性方面的需求设计阶段软件设计没有安全性的考虑软件设计存在逻辑上的缺陷编码阶段代码中存在安全漏洞，如存在SQL注入漏洞、对入口参数缺少有效性检查等为了测试方便,开发人员在程序中留下后门开发人员在程序中植入恶意代码引用没有经过安全性测试的开源代码测试阶段没有对软件进行安全性测试运行与维护阶段软件产品发布后没有对软件进行合理的保护,造成软件被破解或被非法复制历史遗留的软件项目源代码和文档缺失，造成即使发现安全漏洞也无法修改的局面传统软件开发生命周期主要从软件功能实现的角度出发，其基本目的是如何合理地组织开发流程以高效地完成软件的各项功能，通常只是注重软件功能的定义、实现与测试，安全策略没有得到充分的考虑。即使是在测试环节考虑到软件系统的安全性，也往往是在编码完成后进行，而没有将软件安全的思想贯穿到软件开发的整个过程。对比而言安全软件开发生命周期是将安全原则渗透到整个软件开发的生命周期中，即在每个开发阶段均需要考虑安全性。安全软件开发生命周期是通过软件开发的各个步骤来确保软件的安全性，其目的是确保安全的软件得以成功实现。在安全软件开发生命周期的每一个阶段都需要应用安全风险管理。只有保证安全风险管理贯彻在整个开发周期中才能保证软件的安全性。关于软件安全开发模型的内容将在本书第二章有详细介绍，并且着重分析了近年来较主流的四种安全开发生命周期模型实例：微软安全开发生命周期模型、McGraw软件安全开发模型以及NIST安全开发生命周期模型。软件安全问题的产生原因大多数商业和开源的应用、中间件系统和操作系统都相当庞大而复杂。在一般的执行中，这些系统可以在大量不同的状态之间转换。这个特征使得软件的开发和持续正常运行变得特别困难，更不用说持续安全运行了。面对不可避免的安全威胁和风险，项目经理和软件工程师必须考虑到软件的安全性。如果项目经理和软件工程师进行过系统的处理缺陷的训练，那么软件的大部分安全缺陷可以避免。不幸的是，在现实环境下，项目经理和软件工程师缺乏设计、开发安全的应用软件和进行质量保证的训练，在测试不安全代码和识别拙劣开发技术方面亟待提升。软件开发和设计人员通常都不理解在识别错误或消除缺陷过程中，或者在面对攻击时，哪些安全条例更有效。开发人员常常对一些特定的软件需求的安全因素不熟悉（或是缺乏）。同样，设计人员也很少学习软件构架、设计、开发、部署和运行的安全要素。这些知识的缺乏意味着软件的安全需求很可能不充分，并且开发出来的软件可能脱离特定的（和非特定）安全需求。此外，这些知识的缺乏将阻碍项目经理和软件工程师识别和理解当软件缺陷和漏洞遭受攻击时，软件会达到一个什么样的错误状态。错误不可避免，即使在需求分析和设计时可以避免（比如通过形式化方法），在开发时可以避免（比如通过全面的代码审查和大量的测试），但却还是会在软件汇编、集成、部署和运行时候被引入。不管如何忠实地遵守一个基于安全的开发过程，只要软件的规模和复杂性继续增长，一些可被挖掘出的错误和其他安全问题是肯定存在的，软件安全专家JuliaH.Allen认为这些问题主要有以下来源：1）复杂性，不完全性和软件运行模型的改变（比如，面向网络或面向服务的结构模型）。2）来自软件工程师的错误假设，包括软件的功能、输出和软件运行环境的行为状态，或者外部实体的预期进入。3）软件规格说明书或设计的瑕疵，或者来自以下方面有缺陷的情况：软件和外部实体的接口，这类型的开发失误包括不恰当的输入检查，错误处理和异常处理机制。软件运行环境的组件（从中间件级别到操作系统级别，再到固件级别和硬件级别的组件）。软件安全问题越来越多，越来越复杂。那种用防火墙来定义系统的“边界”，把软件与外界隔离，过分依赖加密技术，并且等到软件出现问题时才被动修复的传统的安全思想，已经无法应对不可避免的安全威胁和风险。为了改变这种状况，我们应该对传统的软件开发模型进行安全方面的改造，对软件设计和开发人员进行全方位的安全培训，使软件安全能够在软件开发的整个流程中都能够得到重视，提高软件产品的本质安全性。1.3本书的结构与内容软件安全一直是软件开发中的一个非常关键的问题，开发高安全性的软件是每个软件开发人员必须追求的目标。开发人员如何在开发的全过程从根本上提高软件的安全性，是每个软件行业从业人员（包括项目经理、系统分析人员、编码人员、测试人员、维护人员）都必须思考的问题。但是，软件安全是一门新兴的学科，所覆盖的范围极其广泛，需要探讨和研究的内容也非常之多。为了让广大软件从业人员更好地了解并掌握软件安全开发的相关理论和技术，本书编写组根据软件行业特点，从软件从业人员的实际情况和知识结构出发，系统地、循序渐近地介绍了软件安全的各个方面，分别对软件安全的基础理论和关键技术进行详细的介绍与讲解。本书的组织结构图如图1-2所示。图1-2组织结构图第1章“软件安全概述”。本章首先介绍了软件的定义和软件的分类，之后给出了软件安全的范畴以及软件安全中的一些典型问题。第2章“软件安全开发模型”。本章从软件安全开发模型和软件生命周期入手，重点介绍了几种典型的软件开发模型，包括：微软安全开发生命周期模型、MrGraw安全接触点以及NIST安全开发生命周期。第3章“安全漏洞管理”。本章首先讲解了漏洞管理主要元素和流程、我国的漏洞管理机制、安全内容自动化协议（SecurityContentAutomationProtocol,SCAP）、典型的软件安全漏洞以及开源Web应用安全项目（OpenWebApplicationSecurityProject,OWASP）所列出的2013年10大安全漏洞。第4章“软件安全功能设计”。本章所介绍的安全功能主要是参考了欧美国家制定的《信息技术安全评估通用准则》，即CC（CommonCriteria）和我国制定的《信息技术安全性评估准则》，即GB/T18336。本章具体的内容包括：安全审计、安全通信、密码支持、用户数据保护、标识和鉴别、安全管理、隐私保护、安全功能的保护、资源利用、系统/子系统的访问以及可信路径/信道等。第5章“常见安全问题”。本章重点介绍了软件安全设计中经常出现的编程安全问题，本章共列举66个安全编码问题，每个问题由问题描述、产生条件和问题涉及的编程语言3部分构成，供开发人员参考。第6章“安全编码实践”，本章重点介绍的内容是如何实现安全的编码和安全编程实践知识，有助于开发人员提高编码的安全性。第7章“软件安全测试”，本章首先对测试方法进行了系统的概述，之后介绍了单元测试、集成测试、系统测试、功能测试、性能测试以及验收测试等内容;本章前半部分侧重对软件测试过程进行讲解，后半部分对软件安全测试进行示例。供测试人员参考。本书面向的主要对象包括从事软件开发工作的软件技术人员、从事软件漏洞分析的安全人员以及学习“软件安全”课程的高等院校信息安全、计算机科学、软件工程类专业本科生和研究生。第2章软件安全开发模型2.1软件开发模型软件开发生命周期一般分为定义、开发、运行维护三个阶段。定义阶段又可细分为问题定义、可行性研究、需求分析阶段；开发阶段又可细分为总体设计、详细设计、编码、测试阶段。运行维护阶段不再细分。从软件开发全过程来看，软件开发模型可归纳为三种基本类型：瀑布型、渐增型、变换型。2.1.1瀑布型软件开发模型瀑布型软件开发模型遵循软件开发生命周期的定义、开发、运行维护三个阶段，明确规定了各个细分阶段的任务，每个阶段将上一阶段产生的相关文档通过处理，完成本阶段任务后生成的产品、文档提交给下一阶段，最终开发出软件产品。瀑布型软件开发模型各阶段任务与输出结果，如表2-1所示,其开发模型如图2-1所示。表2-1瀑布型软件开发模型各阶段任务与输出结果阶段基本任务输出结果问题定义目标理解与范围界定系统目标与范围说明书可行性研究理解工作范围确定任务项目计划任务书需求分析分析需求、定义用户要求需求规格说明书总体设计构建软件结构总体设计说明书详细设计各模块的功能设计程序功能说明书编码编写程序程序清单测试发现和排除错误软件产品运行维护运行和管理改进的软件产品图2-1瀑布型软件开发模型2.1.2渐增型软件开发模型渐增型软件开发模型如图2-2所示，在瀑布型软件开发模型基础上通过问题定义，从基本需求分析开始进行定义、设计、编码、测试，建立满足用户基本需求的原型系统。通过对原型系统的测试、运行评估反馈，进一步了解用户需求进行渐增式的设计、编码，修改完善，再测试与运行，如此循环直至用户满意，完成合同提交软件产品。基于这种模型的软件开发，要求用户直接参与和配合，软件文档随着软件开发过程逐渐形成。图2-2渐增型软件开发模型2.1.3变换型软件开发模型变换型软件开发模型如图2-3所示，该模型反映出一种形式化软件开发的方法，从软件需求形式化规格说明开始，通过一系列的形式变换处理，最终形成程序软件系统。该方法主要是在软件开发生命周期需求、设计、编程等不同阶段对相关规格说明采用形式语言描述，构建基于形式语言的代数模型（包含变换、演算规则），对系统的逻辑演绎结构进行变换、演算，实现应用软件系统的开发。例如：基于软件需求和相关规格说明的形式化描述,采用进程代数建立模型，通过变换、演算完成软件开发。只要形式化描述、变换规则是正确的，则程序系统一定是正确的。形式化描述、变换处理需要形式语言理论、数学工具和技术的支持。原型检查原型检查软件需求形式化规格说明(软件需求形式化描述)软件设计形式化规格说明(软件设计形式化描述)变换、演算处理变换、演算处理程序变换、演算规则变换、演算规则图2-3变换型软件开发模型上述模型是我们在软件开发过程中的常用模型，在开发过程中可以混合使用。如，采用基于形式化模型快速建立原型系统，以渐增的方式改进软件需求形式化描述，进行渐增式的设计、编码，修改完善再测试，直至用户满意，完成合同提交软件产品。2.2常用软件开发方法随着软件开发方法的不断发展，除了采用上述模型进行开发外，还可采用以下各种软件开发方法进行软件开发。结构化软件开发方法结构化软件开发模型核心思想是自顶向下和逐步求精。对于一个复杂的系统,采用“分解和抽象”手段，使其逐层分解直至各子系统足够简单为止。模型使用数据流图、数据词典和小说明等规范工具描述系统。其中小说明的表示方法除了自然语言外，通常采用结构化语言、判定表和判定树等三种形式。基于上述对系统的描述，建立系统模块结构图或软件层次方框图，在此基础上使用程序语言完成编码工作。模型采用“分解和抽象”手段，将整个系统逐层分解直至足够简单的各个子模块，这种思想贯穿于软件开发生命周期系统分析、设计和编程全过程。面向对象的软件开发方法面向对象的软件开发模型是围绕着现实世界的概念来组织模型，通过对客观领域的概念进行分类和组织来创建软件的模型。模型针对面向对象软件开发生命周期的四个阶段来组织。=1\*GB2⑴分析阶段，该阶段的任务是从问题域中抽象出类和对象的模型。=2\*GB2⑵设计阶段，设计是对时间问题域的行为进行关键抽象再分解的过程。设计的结果反馈到分析结果上并进行修正，直至关键抽象足够简单不需要再分解时设计结束。=3\*GB2⑶演化阶段，演化实际上是将编码、测试和集成组合在一起的活动。=4\*GB2⑷维护阶段，维护是在软件系统提交运行后进行的变更活动。组件开发方法基于组件开发是当前软件开发技术的趋势，是面向对象软件发展过程的延伸，它实现了分析、设计、类等多层次上的重用。基于组件的软件开发模型（组件开发模型），将开发过程分为四个主要阶段：=1\*GB2⑴标识组件。将需要开发的应用系统分解为粒度适宜的组件，进行标识。=2\*GB2⑵获取组件。对于分解后的组件，尽可能地从现有的组件中获取。=3\*GB2⑶设计组件。对于需要设计的新组件，也应尽可能地从已有的组件中抽取、修改，对于需要重新设计的组件，在设计过程中要针对组件的复用性来设计。=4\*GB2⑷测试组件。对获取、更改和设计的组件进行测试，是否满足功能需求。在组件被一个新的系统和运行环境接受之前，必须确定组件是否能正确的按规范说明实现功能。组件开发模型充分体现了组件重用特征。值得说明的是，不同组件描述技术和规范的不同，如UML、JavaBean、EJB、Servlet等，其模型具体构造也不同。敏捷软件开发方法（Scrum）敏捷软件开发技术与模型是敏捷开发的一种，近年内逐渐流行起来。开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证方案的成功。Scrum是英式橄榄球队,模型将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。Scrum开发模型是一种灵活的软件管理过程，它可以帮助开发者驾驭迭代、递增的软件开发过程。其轻量过程可以作为包装器，也就是说可以把Scrum与其它灵活的过程框架组合起来，比如说RUP（Rational

Unified

Process，Rational统一过程），是一种被广泛使用的软件过程框架，可以很好地迎合开发者软件开发过程的需要，还可以容纳其他技术。本节给出的软件开发模型保障了用户需求和软件系统功能、性能的实现，但是从软件安全开发生命周期的角度来看，上述软件开发模型的安全性，并没有系统、完整的体现。2.3安全开发模型从软件开发生命周期全过程来看，软件安全开发生命周期（SDL，SecureDevelopmentLifecycle）模型核心思想是在软件开发生命周期的每个阶段融合安全要素，用以解决软件开发各阶段可能出现的安全问题。在瀑布型、渐增型软件开发模型基础上融合安全要素，构建的面向软件开发生命周期的一类基本软件安全开发模型如图2-4所示。该模型通过项目启动阶段中安全原则制定、需求阶段中的安全需求分析、设计阶段中的架构和设计安全分析与评审、编码阶段中的安全编码原则与实施、测试阶段中的安全测试等策略、方法，达到减少软件开发过程中引入的安全漏洞数量，确保软件开发的安全性及安全软件的实现。图2-4软件安全开发模型该软件安全开发模型面向软件开发生命周期各阶段融合了安全要素：安全基本原则、安全需求、安全设计与架构评审、威胁建模、安全编码、安全测试、安全评审评估等安全活动与方法，是面向软件开发生命周期的一类基本的软件安全开发模型。软件安全开发模型、安全开发建模方法与应用是信息安全技术领域的研究热点，代表性的有微软的安全开发生命周期模型（MicrosoftSDL）、McGraw的软件安全接触点模型（BuildingSecurityIn，BSI）、美国国家标准与技术研究院（NIST）的安全开发生命周期模型等。2.4微软安全开发生命周期模型2.4.1安全生命周期模型（SDL）微软的安全开发生命周期（MicrosoftSDL）模型（/sdl）是用于改进软件安全和隐私保护的过程。SDL模型将软件开发生命周期划分为需求分析、软件设计、代码实现、审查、产品发布五个阶段，它包括了必需的安全活动：安全培训、安全需求、安全设计、安全实施、安全验证和发布与响应。这与2.3节面向软件开发生命周期的软件安全开发模型中的安全基本原则、安全需求、安全设计与架构评审、威胁建模、安全编码、安全测试、安全评审评估等安全活动与内容基本一致。MicrosoftSDL模型不仅包括遵从通常软件开发过程的必需行动，还十分灵活，允许添加其他策略和方法，从而创建组织所特有的软件开发方法体系。提供的过程、培训和工具的组合具有明显的优势，如可增强可预测性、技术能力及软件安全性，这些优势可降低组织及软件用户的风险。MicrosoftSDL模型对开发过程进行了扩充，在开发过程的各个阶段加入一系列安全活动，并形成相应的交付物和报告进行安全审查。这些安全活动和报告包括：1）需求分析阶段，对安全功能的要求和可信行为进行确切定义，定义安全目标、安全需求特性和保障措施、检验准则；2）软件设计阶段，对安全风险识别中的安全架构、威胁建模，风险分析，关键组件和攻击面进行识别，确定设计技术指南等；3）代码实现阶段，建立安全编码原则与标准，使用静态分析、代码扫描工具和代码审核工具进行代码测试，以及以安全为核心的测试（如Fuzz测试）；4）审查阶段，进行代码审核、安全测试；5）产品发布阶段，首先进行最终安全复审（FSR），系统部署后为反馈的新漏洞设置响应机制，避免在后续开发过程中再次出现。此外，SDL模型强调在系统安全开发项目启动阶段引入安全顾问的角色，安全顾问统筹和指导系统安全开发全过程，直到最终安全复审（FSR）结束。微软通过利用安全衡量指标，以及微软核心安全团队的安全专业知识对软件开发人员进行强制性的安全培训。从微软的报告发现，利用SDL开发产品的安全性能令人鼓舞。2.4.2SDL优化模型软件安全开发是成功还是失败，通常取决于组织规模、资源（时间、人才和预算）以及高层支持等因素。将安全开发概念整合到现有开发过程时，如果方式不当，可能会造成不利的局面而且成本高昂。因此，需要正确地理解安全开发实践的要素，选用合适的开发模型，根据开发团队的成熟度水平确定实施优先级，控制无形因素的影响。为此，Microsoft创建了具有功能和成熟度水平的SDL优化模型，如图2-5所示。图图2-5具有功能和成熟度水平的SDL优化模型SDL优化模型围绕五个功能领域构建，这些领域大致与软件开发生命周期模型的各个阶段相对应。包括：培训、政策和组织功能、要求和设计、实施、验证、发布和响应。针对上述领域中的实践和功能，SDL优化模型定义了基本、标准化、高级和动态四个成熟度水平。SDL优化模型从基本成熟度水平（几乎或完全没有任何过程、培训和工具）开始，发展到动态成熟度水平（特点是整个组织完全遵循SDL）。完全遵循SDL包括：高效的过程、训练有素的人员、专用工具以及组织内部和外部各方的强烈责任感。与其他软件成熟度模型相比，MicrosoftSDL优化模型严格侧重于开发过程改进。它提供可操作的说明性指南，说明如何从较低水平的过程成熟度发展为较高水平的过程成熟度。2.4.3SDL安全人员角色对于实施MicrosoftSDL控制的软件安全开发项目，为组织设定明确的预期值是非常重要的。实践经验表明，具备以下一个或多个特征的应用程序的开发应实施SDL控制：1）在业务或企业环境中部署；2）处理个人可识别信息（PII）或其他敏感信息；3）定期通过Internet或其他网络进行通信；4）计算技术无处不在，威胁环境不断变化，因此，可能更方便的方式是确定不需要实施安全；5）控制（如SDL安全控制）的应用程序开发项目。如果确定对某个软件开发项目实施SDL控制，为符合MicrosoftSDL过程的要求，开发团队必须成功完成必需的安全活动。这些必需活动已由安全和隐私专家确认有效，并且会作为严格的年度评估过程的一部分，不断进行有效性评析。为确定软件开发项目中存在的安全和隐私问题并进行分类和缓解，软件开发项目中开发团队需要有安全人员角色构成的组织结构。这些角色包括：1）评析者/顾问角色。这些角色的任务是对项目安全和隐私进行监督，有权接受或拒绝项目团队的安全和隐私计划。2）安全顾问/隐私顾问。这些角色由项目团队外部的主题专家（SME）担任。该角色可以由组织中专门进行此类评析的独立集中小组中的合格成员担任，也可以由组织外部的专家担任。最好是集中的内部顾问小组；内部顾问小组具备组织环境和过程知识，这是外部专家无法做到的。为此任务选择的人员必须担任两个子角色：（1）审计官。此角色必须监控软件开发过程的每个阶段，并证明每个安全要求的成功实现。审计官必须能够自主证明过程是否符合安全和隐私方面的要求，而不受项目团队的干扰。（2）专家。为顾问角色选择的人员必须在安全方面拥有可靠的相关专业知识。3）顾问角色组合。如果可以确认某人具有合适的技能和经验，则安全顾问的角色可以与隐私顾问的角色合二为一。4）团队负责人。团队负责人角色应由项目团队的主题专家担任。这些角色负责协商、接受和跟踪最低安全和隐私要求，并在软件开发项目过程中与顾问和决策者保持通畅的沟通渠道。5）安全负责人/隐私负责人。此角色（一人或多人）不仅负责确保软件发布解决了所有安全问题，还负责协调和跟踪项目的安全问题。此角色还负责向安全顾问和项目团队的其他相关方（例如，开发和测试负责人）报告情况。6）角色组合。与安全和隐私顾问角色一样，如果可以确认某人具有合适的技能和经验，则可以由一人承担安全负责人和隐私负责人的角色，并履行其职责。2.4.4SDL模型安全活动MicrosoftSDL模型规定了一组必须的安全活动，为了实现所需安全和隐私目标，项目团队或安全顾问可以自行决定添加可选的安全活动。图2-6（a）、2-6（b）表示了SDL模型过程详细关系图。该图以直观的方式说明一个假设项目中使用的安全活动（从培训员工到应用程序发布）。图中包括了必需和可选的任务。图2-6(a)SDL模型过程详细关系图图2-6(b)SDL模型过程详细关系图（续）值得注意的一个基本概念是，模型注重每个阶段产生输出的质量和完整性。SDL优化模型的高级和动态水平开发运营组织，应具备一定程度的安全过程复杂性。尽管如此，这并不影响威胁模型的产生方式。例如，可以通过与开发团队进行白板会议产生威胁模型；在文档中以叙述形式描述威胁模型；也可以使用专用工具（如SDL威胁建模工具）生成威胁模型。高效的工具和过程自动化会使SDL实现过程受益，其实际价值在于可以获得全面而准确的结果。针对SDL模型的简化描述如图2-7所示，它包括了必需的安全活动：安全培训、安全需求、安全设计、实施安全、验证安全和发布与响应。图2-7MicrosoftSDL模型（简化图）在下面的各小节中，具体描述了安全生命周期模型（SDL）在开发过程的各个阶段的一系列安全活动。2.4.5培训阶段培训阶段，软件开发团队的所有成员都必须接受适当的培训，了解安全基础知识以及安全和隐私方面的最新发展趋势。直接参与软件程序开发的技术角色人员（开发人员、测试人员和程序经理）每年至少必须参加一门特有的安全培训课程。基本软件安全培训应涵盖的基础概念包括：（1）安全设计培训包括以下主题：减小攻击面、深度防御、最小权限原则、安全默认设置；（2）威胁建模培训包括以下主题：威胁建模概述、威胁模型的设计意义、基于威胁模型的编码约束；（3）安全编码培训包括以下主题：缓冲区溢出（对于使用C和C++的应用程序）、整数算法错误（对于使用C和C++的应用程序）、跨站点脚本（对于托管代码和Web应用程序）、SQL注入（对于托管代码和Web应用程序）；（4）弱加密安全测试培训包括以下主题：安全测试与功能测试之间的区别、风险评估、安全测试方法；（5）隐私保护培训包括以下主题：隐私敏感数据的类型、隐私设计最佳实践、风险评估、隐私开发最佳实践、隐私测试最佳实践；（6）高级概念方面的培训包括但不限于以下方面：高级安全设计和体系结构、可信用户界面设计、安全漏洞细节、实施自定义威胁缓解。2.4.6需求阶段需求阶段，“预先”考虑安全和隐私是开发安全系统过程的基础环节。在初始计划中，为软件项目定义信任度要求是最佳的时间。尽早定义安全要求有助于开发团队确定关键里程碑和交付成果，并使集成安全和隐私的过程尽量不影响计划和安排。在项目初期对安全和隐私要求的分析，涉及在计划运行环境中运行的软件程序确定最低安全要求，并确立和部署安全漏洞或者工作项以跟踪系统开发。1．SDL质量门/缺陷（Bug）栏质量门和缺陷栏用于确立安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全缺陷。项目团队必须协商确定每个开发阶段的质量门（例如，必须在嵌入代码之前会审并修复所有编译器警告），随后将质量门交由安全顾问审批。安全顾问可以根据需要添加特定于项目的说明以及更加严格的安全要求。缺陷栏是应用于整个软件开发项目的质量门，它用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。缺陷栏一经设定，便绝不能放松。动态缺陷栏是一种不断变化的目标，可能不便于开发组织的理解。2．安全和隐私风险评估安全风险评估（SRA）和隐私风险评估（PRA）是必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：1）安全项目的哪些部分在发布前需要威胁模型；2）安全项目的哪些部分在发布前需要进行安全设计评析；3）安全项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试；4）安全是否存在安全顾问认为有必要增加的测试或分析要求，以缓解安全风险；5）安全模糊测试要求的具体范围是什么；6）基于以下准则回答隐私对评级的影响：=1\*GB2⑴P1高隐私风险。功能、产品或服务将存储或传输PII，更改设置或文件类型关联，或是安装软件。=2\*GB2⑵P2中等隐私风险。功能、产品或服务中影响隐私的唯一行为是用户启动的一次性匿名数据传输（例如，软件在用户单击链接后转到外部网站）。=3\*GB2⑶P3低隐私风险。功能、产品或服务中不存在影响隐私的行为。不会传输匿名或个人数据，不在计算机上存储PII，不代替用户更改设置，并且不安装软件。2.4.7设计阶段设计阶段，至关重要的是应仔细考虑安全和隐私问题。如果在项目生命周期的开始阶段执行缓解措施，则缓解安全和隐私问题的成本会低得多。项目团队应避免到项目开发将近结束时再“插入”安全和隐私功能及缓解措施。此外，项目团队还必须理解“安全的功能”与“安全功能”之间的区别。实现的安全功能实际上很可能是不安全的。“安全的功能”定义为在安全方面进行了完善设计的功能，比如在处理之前对所有数据进行严格验证或是通过加密方式可靠地实现加密服务库。“安全功能”描述具有安全影响的程序功能，如Kerberos身份验证或防火墙。创建安全和隐私设计规范设计要求活动包含一些必需行动。包括创建安全和隐私设计规范、规范评析以及最低加密设计要求规范。设计规范应描述用户会直接接触的安全或隐私功能，如需要用户身份验证才能访问特定数据或在使用高风险隐私功能前需要用户同意的那些功能。此外，所有设计规范都应描述如何安全地实现给定特性或功能所提供的全部功能。针对应用程序的功能规范验证设计规范。功能规范应：准确完整地描述特性或功能的预期用途；描述如何以安全的方式部署特性或功能。减小攻击面在安全设计中，减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问、应用最小权限原则以及尽可能进行分层防御。威胁建模威胁建模用于存在重大安全风险的环境之中。威胁建模使开发团队可以在其计划的运行环境的背景下，以结构化方式考虑、记录并讨论设计的安全影响。通过威胁建模还可以考虑组件或应用程序级别的安全问题。威胁建模是一项团队活动（涉及项目经理、开发人员和测试人员），并且是软件开发设计阶段中执行的主要安全分析任务。首选的威胁建模方法是使用基于STRIDE威胁等级分类法的SDL威胁建模工具。2.4.8实施阶段使用批准的工具所有开发团队都应定义并发布获准工具及其关联安全检查的列表，如编译器或链接器选项和警告。此列表应由项目团队的安全顾问进行批准。一般而言，开发团队应尽量使用最新版本的获准工具，以利用新的安全分析功能和保护措施。弃用不安全的函数许多常用函数和应用编程接口（API），在当前威胁环境下并不安全。项目团队应分析与软件开发项目结合使用的所有函数和API，并禁用确定为不安全的函数和API。确定禁用列表之后，项目团队应使用头文件（如banned.h和strsafe.h）、较新的编译器或代码扫描工具来检查代码（在适当情况下还包括旧代码）中是否存在禁用函数，并使用更安全的备选函数替代这些禁用函数。静态分析项目团队应对源代码执行静态分析。源代码静态分析为安全代码评析提供了伸缩性，可以帮助确保对安全代码策略的遵守。静态代码分析本身通常不足以替代人工代码评析。安全团队和安全顾问应了解静态分析工具的优点和缺点，并准备好根据需要为静态分析工具辅以其他工具或人工评析。一般而言，开发团队应确定执行静态分析的最佳频率，从而在工作效率与足够的安全覆盖率之间取得平衡。2.4.9验证阶段1.动态程序分析为确保程序功能按照设计方式工作，有必要对运行时的软件程序进行验证。此验证任务应指定一些工具，用以监控应用程序行为是否存在内存损坏、用户权限问题以及其他重要安全问题。SDL过程使用运行时工具（如AppVerifier）以及其他方法（如模糊测试）来实现所需级别的安全测试覆盖率。2.模糊测试模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定以应用程序的预期用途、应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试或扩大模糊测试的范围和增加持续时间。3.威胁模型和攻击面评析应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范上。因此，在给定应用程序完成编码后重新评析其威胁模型和攻击面度量是非常重要的。此评析可确保对系统设计或实现方面所做的全部更改，并确保因这些更改而形成的所有新攻击平台得以评析和缓解。2.4.10发布和响应阶段事件响应计划受SDL要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。事件响应计划包括：单独指定的可持续工程（SE）团队。如果团队太小以至于无法拥有SE资源，则应制定紧急响应计划(ERP)，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。与决策机构的电话联系（7天24小时随时可用）。针对从组织中其他小组继承的代码的安全维护计划。针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更改的合同许可（如果适用）。最终安全评析最终安全评析（FSR）是在发布之前仔细检查对软件应用程序执行的所有安全活动。FSR由安全顾问在普通开发人员以及安全和隐私团队负责人的协助下执行。FSR不是“渗透和修补”活动，也不是用于执行以前忽略或忘记的安全活动的时机。FSR通常要根据以前确定的质量门或缺陷栏检查威胁模型、异常请求、工具输出和性能。通过FSR将得出以下三种不同结果：通过FSR。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解。通过FSR但有异常。在FSR过程中确定的安全和隐私问题都已得到修复或缓解，并且/或者异常都已得到圆满解决。无法解决的问题（例如，由以往的“设计水平”问题导致的漏洞）将记录下来，在下次发布时更正。需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成一致接受，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的SDL要求问题，或是上报高级管理层进行抉择。发布/存档发布软件的生产版本（RTM）还是Web版本（RTW）取决于SDL过程完成时的条件。指派负责发布事宜的安全顾问必须证明（使用FSR和其他数据）项目团队已满足安全要求。同样，对于至少有一个组件具有相应隐私影响评级的所有产品，项目的隐私顾问必须先证明项目团队满足隐私要求，然后才能交付软件。此外，必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款，以及执行发布后维护任务所需的任何其他数据。2.4.11可选的安全活动SDL中可选的安全活动，通常在软件应用程序可能用于重要环境或方案时执行。这些活动通常由安全顾问在附加商定要求集中指定，以确保对某些软件组件进行更高级别的安全分析。1．人工代码审核人工代码审核是SDL中的可选任务，通常由应用程序安全团队中具备高技能的人员或由安全顾问执行。尽管分析工具可以进行很多查找和标记漏洞的工作，但这些工具并不完美。因此，人工代码审核通常侧重于应用程序的“关键”组件。这种审核最常用在处理或存储敏感信息（如个人身份信息（PII））的组件中。另外，此活动也用于检查其他关键功能，如加密实现。2．渗透测试渗透测试是对软件系统进行白盒安全分析，由高技能安全专业人员通过模拟黑客操作执行。渗透测试的目的是发现由于编码错误、系统配置错误或其他运行部署弱点导致的潜在漏洞。渗透测试通常与自动及人工代码评析一起执行，以提供比平常更高级别的分析。3．相似应用程序的漏洞分析