[太原理工大学] 2023 大三下 软件安全技术考试重点_完全控制原则

这次考试老师没划多少重点，我也没找到历年题，所以复习量特别大，而且背的很多，看到的现在就赶紧背，不然小心背不完了！

有什么问题请在评论区和我说，虚心接受批评指正

目录

第一章

第二章

第三章

第四章

第五章

第六章

第七章

第八章

第九章

---

第一章

什么是零日攻击？

零日漏洞是指未被公开披露的软件漏洞，没有给软件的作者或厂商以时间去为漏洞打补丁或是给出解决方案建议，从而使攻击者能够利用这种漏洞破坏计算机程序、数据及设备。注意，零日漏洞并不是软件发布后被立刻发现的漏洞。

利用零日漏洞开发攻击工具进行的攻击称为零日攻击。零日攻击所针对的漏洞由于软件厂商还没有发现或是还未提供相应的补丁，所以零日漏洞攻击的成功率高，造成的破坏大。

零日漏洞反映了什么问题？

软件漏洞是普遍存在的，系统软件，应用软件和第三方软件，他们在开发，部署应用中的问题层出不穷

什么是软件漏洞？

软件漏洞通常被认为是软件生命周期中与安全相关的设计错误、编码缺陷及运行故障等。           

例子：

操作系统启动时发现未能驱动的硬件而导致蓝屏。·

应用软件由于存在内存泄露，运行时系统内存消耗越来越大，直至最后崩溃。

网络软件由于对用户并发数考虑不周，导致用户数量超出预计，程序运行错误

多线程软件对线程同步考虑不周，导致系统因资源死锁而死机。

软件使用明文存储用户口令，黑客通过数据库漏洞直接获取口令明文。

软件存在缓冲区溢出漏洞，黑客利用溢出攻击而获得远程用户权限。

软件对用户登录的安全验证强度太低，黑客假冒合法用户登录。

蠕虫软件对用户的输入没有严限制，被黑客利用后执行系统删除命令，从而导致系统被破坏。

恶意代码的概念？

恶意代码是未在授权的情况下，以破坏硬件设备、窃取用户信息、干扰用户正常使用、扰乱用户心理为目的而编制的软件或代码片段。

包括计算机病毒、蠕虫、特洛伊木马、后门、内核套件，间谍软件，恶意广告，流氓软件，逻辑炸弹，僵尸网络，网络钓鱼，恶意脚本，垃圾信息，勒索软件等等。

什么是软件安全？

软件安全是软件工程与软件保障的一个方面，它提供一种系统的方法来标识、分析和追踪对危害及具有危害性功能（例如数据和命令）的软件缓解措施与控制。

*CIA

什么是CIA

保密性、完整性、可用性。

1.保密性

信息安全中保密性是指确保信息资源仅被合法的实体（如用户、进程等）访问，使企业不泄露给未授权的实体。这里所指的信息不但包括国家秘密，而且包括各种社会团体、企业组织的工作秘密和商业秘密，以及个人秘密和个人隐私。保密性还包括保护数据的存在性，有时候存在性比数据本身更能暴露信息。

2.完整性

    信息安全中的完整性是指信息资源只能由授权方以授权方式修改，在存储或传输过程中不被授权、未预期或无意篡改、销毁，或在篡改后能够被迅速发现。不仅要考虑数据的完整性，还要考虑操作系统的完整性，既保证系统以无害的方式按照约定的功能运行，不被有意的或者意外的非法操作所破坏。

3.可用性

    信息安全中的可用性是指信息资源（信息、服务和IT资源等）可被合法实体并按要求的特性使用。例如，破坏网络和有关系统正常运行的拒绝服务攻击就属于可用性的破坏。

PDRR模型

保护-检测-响应-恢复

软件安全防护的基本方法

软件安全防护围绕漏洞消除展开，目前有两种基本方法：

1）采用多种检测、分析及挖掘技术对安全错误或是安全漏洞进行发现、分析与评价，然后采取多种安全控制措施进行错误修复和风险控制，如传统的打补丁、防病毒、防火墙、入侵检测和应急响应等。

这种将安全保障措施置于软件发布运行之时是当前普遍采用的方法。历史经验证明，该方法在时间和经济上投入人产出比低，信息系统的安全状况很难得到有效改善。本章前面对于当前软件安全问题的现状分析表明了这点。

2）分析软件安全错误发生的原因，将安全错误的修正嵌入到软件开发生命周期的整个阶段。通过对需求分析、设计、实现、测试、发布及运维等各阶段相关的软件安全错误的分析与控制，以期大大减少软件产品的漏洞数量，使软件产品的安全性得到有效提高。

该方法是将安全保障的实施开始于软件发布之前，尤其强调从软件生命周期的早期阶段开始安全考虑，从而减少软件生命周期的后期系统运行过程中安全运维的工作量，提高安全保障效果。实践经验表明，从系统开发需求阶段就引入安全要素要比在系统维护阶段才考虑安全问题所花费的错误修复成本要低很多。

软件安全防护的主要技术

软件安全属性的认知，系统安全工程，软件安全开发

第二章

软件中的错误、缺陷、故障和失效在软件生命周期各个阶段的表现

软件错误 (Error)是指在软件开发过程中出现的不符合期望或不可接受的人为差错，其结果将可能导致软件缺陷的产生。在软件开发过程中，人是主体，难免会犯错误。软件错误主要是一种人为错误，相对于软件本身而言，是一种外部行为。

软件缺陷_(Bug/Defect) 是指由于人为差错或其他客观原因，导致软件隐含能导致其在运行过程中出现不希望或不可接受的偏差，例如软件需求定义，以及设计、实现等错误。在这种意义下，软件缺陷和软件错误有着相近的含义。当软件运行于某一特定的环境条件时出现故障，这时称软件缺陷被激活。软件缺陷存在于软件内部，是一种静态形式

软件故障(Fault)是指软件出现可感知的不正常、不正确或不按规范执行的状态。例如软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失或非正常中断等现象。

软件失效 (Fgilure) 是指软件丧失完成规定功能的能力的事件。软件失效通常包含三方面的含义:软件或其构成单元不能在规定的时间内和条件下完成所规定的功能，软件故障被触发及丧失对用户的预期服务时都可能导致失效;一个功能单元执行所要求功能的能力终结;软件的操作偏离了软件需求。

软件漏洞的成因？

计算机系统结构决定了漏洞的必然性

软件趋向大型化,第三方扩展增多

新技术、新应用产生之初即缺乏安全性考虑

软件使用场景更具威胁

对软件安全开发重视不够,软件开发者缺乏安全知识

软件漏洞的特点？

1.持久性与时效性

2.广泛性与具体性

3.可利用性与隐蔽性

软件漏洞的分类？

(1)基于漏洞成因的分类

基于漏洞成因的分类包括:内存破坏类、逻辑错误类、输人验证类、设计错误类和配置错误类。

1)内存破坏类。此类漏洞的共同特征是由于某种形式的非预期的内存越界访问(读、写或兼而有之)，可控程度较好的情况下可执行攻击者指定的任意指令，其他的大多数情况下会导致拒绝服务或信息泄露。对内存破坏类漏洞再按来源细分，可以分出如下子类型:栈缓冲区溢出、堆缓冲区溢出、静态数据区溢出、格式串问题、越界内存访问、释放后重用和二次释放。

2）逻辑错误类。涉及安全检查的实现逻辑上存在的问题，导致设计的安全机制被绕过。

3）输入验证类。漏洞来源都是由于对来自用户输人没有做充分的检查过滤就用于后续操作，威胁较大的有以下几类:SQL注入、跨站脚本执行、远程或本地文件包含、命令注入和目录遍历。

4）设计错误类。系统设计上对安全机制的考虑不足导致在设计阶段就已经引入安全漏洞。

5）配置错误类。系统运行维护过程中以不正确的设置参数进行安装，或被安装在不正确的位置。

(2)基于漏洞利用位置的分类

1）本地漏洞。即需要操作系统级的有效账号登录到本地才能利用的漏洞，主要构成为权限提升类漏洞，即把自身的执行权限从普通用户级别提升到管理员级别。

2）远程漏洞。即无需系统级的账号验证即可通过网络访问目标进行利用的漏洞。

(3）基于威胁类型的分类

1)获取控制。即可以导致劫持程序执行流程，转向执行攻击者指定的任意指令或命令，控制应用系统或操作系统。这种漏洞威胁最大，同时影响系统的机密性、完整性，甚至在需要的时候可以影响可用性。主要来源为内存破坏类。

2）获取信息。即可以导致劫持程序访问预期外的资源并泄露给攻击者，影响系统的机密性。主要来源为输入验证类和配置错误类漏洞。

3）拒绝服务。即可以导致目标应用或系统暂时或永远性地失去响应正常服务的能力，影响系统的可用性。主要来源为内存破坏类和意外处理错误类漏洞。

软件漏洞的分级？

按照漏洞严重等级进行分级

利用通用漏洞评分系统(CVSS)进行分级

由中国信息安全测评中心负责建设运维的CNNVD，将漏洞按照危害程度从高至低分为超危、高危、中危和低危4种等级

第三章

(这一章没看明白,下面是老师说的重点)

栈溢出、栈溢出漏洞及利用分析

堆溢出漏洞及利用分析

格式化字符串漏洞及利用分析

Windows安全漏洞保护分析

第四章

Web安全十大漏洞

注入，跨站脚本，失效的身份认证和会话管理，不安全的直接对象引用，错误的安全配置，敏感数据泄露，缺失功能级访问控制，跨站请求伪造，使用有漏洞的组件，未验证的重定向和转发。

SQL 注入漏洞原理：SQL注入漏洞是指，攻击者能够利用现有Web应用程序，将恶意的数据插入SQL查询中，提交到后台数据库引擎执行非授权操作。

SQL注入漏洞的主要危害如下。

·非法查询、修改或删除数据库资源。

·执行系统命令。

·获取承载主机操作系统和网络的访问权限。

利用方法：

1）注入点选择

在SQL注人攻击之前，首先要找到网站中各类与数据库形成交互的输入点。通常情况下，一个网站的输入点包括以下几项。

·表单提交,主要是POST请求,也包括GET请求。

·URL参数提交，主要是 GET请求参数。

·Cookie参数提交。

· HTTP请求头部的一些可修改的值，如 Referer、User_Agent等。·一些边缘的输入点，如.mp3文件的一些文件信息等。

上面列举的几类输入点，只要任何一点存在过滤不严、过滤缺陷等问题，都有可能发生SQL注入攻击。

(2)数字型和字符型注入

按照注入的数据类型，可将SQL注入攻击分为数字型注入和字符型注入。

数字型注入。当输人的参数为整数时，即为数字型注入，如ID、年龄等。数字型注入是—种最简单的注入方式。

字符型注入。当输人的参数为字符串时，即为字符型注入，如姓名、密码等。字符型注入和数字型注入的区别在于:字符型注入需要闭合单引号，而数字型注入不需要。

（3）通过Web端对数据库注入和直接访问数据库注入

按照注入的物理途径，可将SQL注人攻击分为通过Web端对数据库注入和直接访问数据库注入。

漏洞防护的基本措施

1.代码层漏洞防护

(1)基本措施

1)采用强类型语言，如Java、C#等强类型语言几乎可以完全忽略数字型注入。

2)尽可能避免使用拼接的动态SQL语句，所有的查询语句都使用数据库提供的参数化查询接口。参数化的语句使用参数而不是将用户输人变量嵌入到 SOL语句中。

3)在服务器端验证用户输入的值和类型是否符合程序的预期要求。

4)在服务器端对用户输人进行过滤。针对非法的 HTML字符和关键字可以编写函数对其进行检查或过滤。

5）避免网站显示SQL错误信息，如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

6)加固应用程序服务器和数据库，利用最低权限账户与数据库连接。

7）遵循安全规范

8）使用专业的漏洞扫描工具进行安全性测试。

第五章

软件生命周期

软件生命周期由定义、开发和维护3个时期组成，每个时期又可进一步划分成若干个阶段。

软件安全开发模型

软件安全开发主要是从生命周期的角度，从安全设计原则，安全开发方法，最佳实践和安全专家经验进行总结，通过采取各种安全活动来保证得到尽可能安全的软件

安全开发生命周期SDL：

第1阶段:安全培训

在软件开发的初始阶段，针对开发团队和高层进行安全意识和能力培训，使之了解安全基础知识及安全方面的最新趋势，同时能针对新的安全问题与形势持续提升团队的能力。

第2阶段:安全需求分析

确定安全需求。在安全需求分析阶段，确定软件安全需要遵循的安全标准和相关要求，建立安全和隐私要求的最低可接受级别。

创建质量门/缺陷（Bug)等级。质量门和缺陷等级用于确立安全和隐私质量的最低可接受级别。

安全和隐私风险评估。安全风险评估（SRA）和隐私风险评估（PRA）是必需的过程，用于确定软件中需要深入评析的功能环节。

第3阶段:安全设计

在安全设计阶段，从安全性的角度定义软件的总体结构。通过分析攻击面，设计相应的功能和策略，降低并减少不必要的安全风险，同时通过威胁建模，分析软件或系统的安全威胁,提出缓解措施。

第4阶段:安全实施

在安全实施阶段，按照设计要求，对软件进行编码和集成，实现相应的安全功能、策略及缓解措施。在该阶段通过安全编码和禁用不安全的API，可以减少实现时导致的安全问题和由编码引入的安全漏洞，并通过代码静态分析等措施来确保安全编码规范的实施。

第5阶段:安全验证

在安全验证阶段，通过动态分析和安全测试手段，检测软件的安全漏洞，全面核查攻击面，检查各个关键因素上的威胁缓解措施是否得以正确实现。

第6阶段：安全发布

在安全发布阶段，建立可持续的安全维护响应计划，对软件进行最终安全核查。本阶段应将所有相关信息和数据存档，以便对软件进行发布与维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档和应急响应计划等。即使在发布时不包含任何已知漏洞的程序，也可能面临日后新出现的威胁。

第7阶段:安全响应

在安全响应阶段，响应安全事件与漏洞报告，实施漏洞修复和应急响应。同时发现新的问题与安全问题模式,并将它们用于SDL的持续改进过程中。

SDL模型是由软件工程的瀑布模型发展而来的，是在瀑布模型的各个阶段添加了安全活动和业务活动目标。

SDL模型实施的基本原则

SD3+C原则是SDL模型实施的基本原则，其基本内容如下

安全设计(Secure by Design)。在架构设计和实现软件时，需要考虑保护其自身及其存储和处理的信息，并能抵御攻击。

安全配置(Secure by Default)。在现实世界中，软件达不到绝对安全，所以设计者应假定其存在安全缺陷。为了使攻击者针对这些缺陷发起攻击时造成的损失最小，软件在默认状态下应具有较高的安全性。例如，软件应在最低的所需权限下运行，非广泛需要的服务和功能在默认情况下应被禁用或仅可由少数用户访问。

安全部署(Security by Deployment)。软件需要提供相应的文档和工具，以帮助最终用户或管理员安全地使用。此外，更新应该易于部署。

沟通(Communication)。软件开发人员应为产品漏洞的发现准备响应方案，并与系统应用的各类人员不断沟通，以帮助他们采取保护措施(如打补丁或部署变通办法)。

敏捷 (Agile) SDL

敏捷SDL与典型SDL的差别主要有两点。

1)敏捷SDL不采用传统的瀑布模型，而是采用无阶段的迭代开发模型，以实现软件版本的快速更新和发布。

2)在敏捷 SDL中，并不是每个发布版本 (或每次“突击发布”) 都需要达到所有的要求，这也是敏捷SDL与传统SDL之间最大的差别。

第六章

软件安全需求分析的目的和作用

(1)软件安全需求分析的目的

软件安全需求分析的目的是描述为了实现信息安全目标，软件系统应该做什么，才能有效地提高软件产品的安全质量,减少进而消减软件安全漏洞。

(2）软件安全需求分析的重要作用

以往软件在开发时只强调业务功能需求，没有考虑安全需求，导致所开发的应用系统存在大量的漏洞。尽管周边安全技术如防火墙、入侵检测系统、防病毒及平台安全可以用来实现系统安全，但由于安全只是在产品环境下被测试和构建，其效果并不理想。

一个缺少安全需求分析的软件开发项目，将威胁到信息的保密性、完整性和可用性，以及其他一些重要安全属性。这个软件产品被攻破可能就只是一个时间早晚的问题，而不是条件的问题，这取决于攻击者对于这个软件系统价值的判断。

软件安全需求分析与软件需求分析的区别：

（1）软件安全需求的客观性

软件安全需求由系统的客观属性决定。安全需求与一般需求的一个主要不同之处在于:安全需求并不是从使用者的要求和兴趣出发，而是由系统的客观属性所决定的。因此，需求分析员将承担更多软件需求的分析工作。

在软件需求分析过程中，分析员和用户都起着关键的、必不可少的作用。因为，只有用户才真正知道自己需要什么，而他们又需要开发人员来帮助实现自己的需求，所以用户必须把他们对软件的需求尽量准确、具体地描述出来;分析员知道怎样用软件去实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通来获取用户对软件的需求。因此，软件需求分析过程中，用户与分析员之间需要密切沟通，而且，为了避免在双方交流信息的过程中出现误解或遗漏，还必须严格审查验证需求分析的结果。

在软件安全需求分析过程中，用户对于软件即将面临的使用对象和使用环境的考虑通常不会包括那些恶意用户和不可控环境，因此，他们对于安全威胁的了解往往不全面，也很难从专业角度提出安全需求。这时，需求分析员就需要承担软件安全需求分析的主要工作。

（2）软件安全需求的系统性

软件安全需求分析不能只从软件本身出发，必须从系统角度进行分析。这是因为，虽然软件（包括操作系统、数据库等）本身可能会由于逻辑、数据和时序等设计缺陷导致安全问题，但同时，由于软件属于逻辑产品，很多情况下并不是软件失效，而是在软件正常工作时，在某种特殊条件下软硬件相互作用，以及由于人的使用问题而导致不安全情况发生。因此，软件安全需求分析必须在系统安全性分析的基础上进行。

通常情况下，凡是与软件相关的接口、硬件状态、硬件故障和系统时序、人员操作、使用环境，包括软件自身的逻辑和物理模型，以及处理的静态动态数据，均属于软件安全性需求分析的范畴。分析的重点为软件功能设计缺陷，以及软件使用过程中软件、硬件和操作人员的相互作用。

此外，软件开发的每一个阶段都需要持续地对安全需求进行充分的定义和管理，这些安全需求应该作为与软件功能、质量和可用性同等重要的需求来处理，并且对那些残余风险需要遵从相关约束的安全需求也应该明确定义。

从系统角度分析软件的安全性需求，这就不可避免地会涉及各种不同领域的专业知识与经验积累。因此，分析时应以人为主，任何软件分析工具只能起辅助作用。这就对软件安全性分析人员提出了较高的要求。分析时要求有专门知识的软件安全性分析人员、熟悉系统结构的系统总体设计人员、软件设计人员和领域专家共同参加，共同工作。

(3）软件安全需求的经济性和适用性

软件安全的需求内容非常丰富，并不是所有的应用安全需求控制都要采纳和实施。组织应当根据具体业务的重要性，对安全措施进行成本控制。安全控制的成本应该与软件所有者或者管理部门要求的目标水平相当。

信息安全等级保护制度是我国信息安全保障体系建设的一项基本制度，对不同等级的信息系统提出相应的安全要求，要求不同等级的信息系统具备相应的基本安全保护能力。不同安全等级的信息应能对抗不同强度和时间长度的安全威胁，即使对于相同等级的信息系统,由于承载的业务不同，其所面临的威胁也不同。因而需要使用不同的保护策略。由此可见,通过对威胁的识别和分析进而建模威胁，是信息系统进行等级保护的基本前提。

软件安全需求分析的主要工作

在软件开发生命周期的需求分析阶段，首先确定目标系统的业务运行环境、规则环境及技术环境，然后在了解各类软件安全需求内容的基础上，通过一定的安全需求获取过程，软件应该包含的安全需求进行分析，而对于如何实现这些安全需求将在软件安全设计和开发部分进行讨论。

软件安全需求的来源

外部需求和内部需求，遵从性需求

1.外部安全需求

外部安全需求通常主要指法律、法规等遵从性需求，包括相应国家和地区关于安全技术与管理的法规、标准及要求等。这些安全技术和管理的合规性要求往往是已有安全威胁的经验性对策的总结，因而遵循这些要求不仅是法规制度上的要求，也是软件安全性保障的要求。

2.内部安全需求

内部安全需求通常包括两个部分，一是组织内部需要遵守的政策、标准、指南和实践模式，二是与软件业务功能相关的安全需求。

在需求分析过程中，不论是外部安全需求还是内部安全需求，都应当给予同等重视。

我国信息安全标准概述

1)信息安全体系、框架类标准。

2)信息安全机制标准。

3)信息安全管理标准。

4)信息系统安全等级保护标准。

5) 信息安全产品标准。

2017年6月1日起实施的《中华人民共和国网络安全法》

(3）等级保护的基本概念

1)网络安全等级保护是指:

对网络（含信息系统、数据，下同)实施分等级保护、分级监管。

对网络中使用的网络安全产品实行按等级管理。

·对网络中发生的安全事件分等级响应、处置。

这里的“网络”是指，由计算机或者其他信息终端及相关设备组成的按照一定的规则和程序对信息进行收集、存储、传输、交换、处理的系统，包括网络设施、信息系统、数据资源等。

网络安全等级保护制度将网络划分为如下五个安全保护等级，从第一级到第五级逐级增高。

第一级，属于一般网络，其一旦受到破坏，会对公民、法人和其他组织的合法权益造成损害,但不危害国家安全、社会秩序和社会公共利益。

第二级，属于一般网络，其一旦受到破坏，会对公民、法人和其他组织的合法权益造成严重损害，或者对社会秩序和社会公共利益造成危害，但不危害国家安全。

第三级，属于重要网络，其一旦受到破坏，会对公民、法人和其他组织的合法权益造成特别严重损害，或者会对社会秩序和社会公共利益造成严重危害，或者对国家安全造成危害。

第四级，属于特别重要网络，其一旦受到破坏，会对社会秩序和社会公共利益造成特别严重危害，或者对国家安全造成严重危害。

第五级，属于极其重要网络，其一旦受到破坏，会对国家安全造成特别严重危害。3)开展网络安全等级保护工作的流程。

根据《信息安全等级保护管理办法》的规定，等级保护工作主要分为以下五个环节。

·一是定级。网络运营者根据《信息安全技术网络安全等级保护定级指南》（GA/T1389—2017）拟定网络的安全保护等级，组织召开专家评审会，对初步定级结果的合理性进行评审，出具专家评审意见，将初步定级结果上报行业主管部门进行审核。

·二是备案。网络运营者将网络定级材料向公安机关备案，公安机关对定级准确、符合要求的网络发放备案证明。

·三是等级测评。网络运营者选择符合国家规定条件的测评机构，对第三级以上网络（含国家关键信息基础设施)每年开展等级测评，查找发现问题隐患，提出整改意见。

·四是安全建设整改。网络运营者根据网络的安全保护等级，按照国家标准开展安全建设整改。

·五是监督检查。公安机关每年对网络运营者开展网络安全等级保护工作的情况和网络的安全状况实施执法检查。

网络安全等级保护是对网络进行分等级保护、分等级监管，是将信息网络、信息系统、网络上的数据和信息，按照重要性和遭受损坏后的危害性分成五个安全保护等级（从第一级到第五级，逐级增高);等级确定后，第二级（含）以上网络到公安机关备案，公安机关对备案材料和定级准确性进行审核，审核合格后颁发备案证明;备案单位根据网络的安全等级，按照国家标准开展安全建设整改，建设安全设施、落实安全措施、落实安全责任、建立和落实安全管理制度;选择符合国家要求的测评机构开展等级测评;公安机关对第二级网络进行指导，对第三、第四级网络定期开展监督、检查。

软件安全需求的获取方法：头脑风暴、问卷调查和访谈、策略分解、数据分类、主/客体关系矩阵、使用用例和滥用案例建模，以及软件安全需求跟踪矩阵。(看具体方法P149-152)

第七章

1.软件安全设计的目的和作用

软件安全设计的目的是将安全属性设计到软件架构中，以实现软件产品本质的安全性。软件安全设计对于软件安全有着举足轻重的作用，大多数软件安全问题都是由于软件设计上的安全性考虑不足或不完整所导致的。

2．软件安全设计与软件设计的联系

软件安全设计就是将软件的安全需求转化为软件的功能结构的过程。

软件设计过程通常包括架构设计、接口设计、构件设计和数据模型设计等工作，

3．软件架构安全性设计

(1)软件架构设计

软件架构可以分为以下3类。

1）逻辑架构:描述软件系统中组件之间的关系，如用户界面、数据库和外部系统接口等。

2）物理架构:描述软件组件在硬件上的部署方式。

3）系统架构:说明系统的非功能性特征，如可扩展性、可靠性、灵活性和性能等。

（2）软件架构安全性设计

软件架构安全设计首先需要进行系统描述，包括系统功能、安全要求、系统部署和技术需求，确定软件系统的安全级别。

4．软件架构安全性分析

软件架构安全性分析的基本过程

软件架构安全性分析的基本过程如图7-1所示（p162），首先进行架构建模,然后根据软件的安全需求描述或相关标准,对架构模型是否满足要求进行检查，如果不满足则需要修改设计架构,如此反复，直至满足所有安全需求和相关标准。

6.安全设计原则介绍(看具体内容，老师说写不够12条没关系，但要具体)

1.减少软件受攻击面原则

软件受攻击面是指，用户或其他程序及潜在的攻击者都能够访问到的所有功能和代码的总和，它是一个混合体，不仅包括代码、接口和服务，也包括对所有用户提供服务的协议,尤其是那些未被验证的或远程用户都可以访问到的协议。一个软件的攻击面越大，安全风险就越大。减少软件受攻击面就是去除、禁止一切不需要使用的模块、协议和服务，其目的是减少攻击可以利用的漏洞。

采取减少软件受攻击面原则的实例如下。

·重要性低的功能可取消;重要等级为中的功能可设置为非默认开启，需要用户配置后才予以开启;重要性高的功能则关闭或增加一些安全措施进行限制。

·重用那些经过测试、已证明安全的现有库和通用组件，而不是用户自己开发的共享库。

2.最小授权原则

最小授权原则是指，系统仅授予实体（用户、管理员、进程、应用和系统等）完成规定任务所必需的最小权限，并且该权限的持续时间也尽可能短。最小授权原则可使无意识的、不需要的、不正确的特权使用的可能性降到最低，从而确保系统安全。

应用程序应该以能够完成工作的最小特权来执行，尽量避免拥有多余的特权属性。因为如果在代码中发现了一个安全漏洞，攻击者可以在目标程序进程中注入代码或者通过目标程序加载执行代码，而这些被注入执行的代码又含有危险操作，那么这部分代码就能够以与该程序进程相同的权限运行。如果没有很高的权限，那么很多程序是无法实现其破坏功能的。不仅要防止程序被攻击，还要尽可能地预防程序被攻击之后的后续破坏行为的实施，将损失尽可能降到最低。

软件设计中采用最小授权原则的实例如下。

·将超级用户的权限划分为一组细粒度的权限，分别授予不同的系统操作员/管理员。对管理员账户分配安全资源的访问权限也要设置为受限访问，而不是超级用户权限。·采用高内聚、低耦合的模块化编程方法，也就是模块之间的依赖关系是弱链接（低耦合)．每一个模块只负责执行一个独立的功能（高内聚)

3．权限分离原则

权限分离原则在软件设计中是指，将软件功能设计为需要在两个或更多条件下才能实现，以防止一旦出现问题，整个软件都可能面临风险。实际上这一原则也是最小权限原则的一种体现。

权限分离原则是类似于不将所有鸡蛋放在一个篮子里的防御模式。例如，导弹发射时必须至少由两个人发出正确的指令才能够发射，财务部门中会计和出纳必须由两人分别担任,以防止不同部门人员之间的相互勾结。

软件设计中采用权限分离原则的实例如下。

·清晰的模块划分，将风险分散到各个模块中去。这样，如果出现问题就可以快速定位到模块，以便进行修复;其次，还可以对单个模块进行测试，保证各个模块的正确性;还可以重复使用已经开发的模块，并且可以在已有模块上增加和替换模块，同时不影响原有模块的功能。

·不允许程序员检查自己编写的代码。

4．纵深防御原则

纵深防御又称为分层防御，是指在软件设计中加入层次化安全控制和风险缓解/防御方法。纵深防御原则有助于减少系统的单一失效点。它强调不依赖于单一的安全解决方案，使用多种互补的安全功能，即使一个安全功能失效，也不会导致整个系统遭受攻击。例如，企业通常使用防火墙进行边界防护，如果进一步对数据进行加密等防护，就可以在防火墙被攻击失效的情况下确保数据的机密性。

纵深防御原则还可以威慑好奇的或者非确定性的攻击者，当他们遇到一层又一层的防御控制时,可能就会知难而退。

·在使用预处理语句和存储过程的同时应用输入验证功能，不允许使用用户输入的动态查询结构，以防止注入攻击。

·不允许活动脚本与输出编码、输入或请求验证相结合，以防止跨站脚本攻击XSS.●使用安全域，根据被授权访问的软件或者人员级别来划分不同的访问域。

5.完全控制原则

完全控制原则是指，要求每一次访问受保护对象的行为都应可能进行细粒度检查。例如，在Web应用中，为了方便用户，常常采用让客户端记自又检查结果，即完成身份验证后基于Cookie缓存认证凭证。这种设计方案固然能够提~乙瓷性能，然而也会带来身份假冒和信息泄露的风险，缓冲区中保存的缓存凭证会成为攻绕过身份认证，进行会话劫持、重放攻击及中间人攻击的安全风险。因此，当一个老i官访问对象资源时，不对其访问权限进行检查就允许访问会违反完全控制原则，这样是很危险的。

软件设计中采用完全控制原则的实例如下。

·应该避免仅仅依赖于客户端或者基于Cookie缓存的认证凭证进行身份验证。·不允许没有经过访问权限验证的浏览器进行数据回传。

6.默认安全配置原则

默认安全配置原则是指，为系统提供默认的安全措施，包括默认权限、默认策略等，尽可能让用户不需要额外配置就可以安全地应用。默认安全原则也是保持系统简单化的重要方式。

软件设计中采用默认安全配置原则的实例如下。

·对任何请求默认加以拒绝。

·不经常使用的功能在默认情况下关闭。

·默认检查口令的复杂性。

·当达到最大登录尝试次数后，默认状态下拒绝用户访问，锁定账户。

7.开放设计

软件的开放设计原则是指，软件设计本身应该是开放的，安全防御机制的实现应该不依赖于设计本身。通过模糊和晦涩难懂的方法固然可以给攻击者增加一些难度，或者说某种程度上提供了纵深防御的能力，但不应该是唯一的或主要的安全机制。

这一原则的具体表现是应用于加密设计的柯克霍夫(Kerckhoff）原则，即密码的安全性不依赖于对加密系统或算法的保密，而依赖于密钥。利用经过公开审查的、已经证明的、经过测试的行业标准，而不是仅采用用户自己开发的保护机制是值得推荐的做法。

软件设计中采用开放设计原则的实例如下。

·软件的安全性不应该依赖于设计的保密。

保护机制的设计应该对团队成员的审查工作开放，让一个团队成员发现系统漏洞总比让攻击者发现要好。

8.保护最弱一环原则

保护最弱一环原则也常称为保护最弱链接（( Weakest Link）原则，是指保护软件系统中的最弱组件。该原则类似于“木桶原理”，描述了软件抵御攻击时的弹性主要依赖于最弱组件的安全性，它们可能是代码、服务或者接口。

与最弱链接相关的一个概念是“单点失效”，在软件安全问题中，最弱链接常常是多个单点故障的超集。软件必须被设计为不存在单点的完全失效。当软件被设计为纵深防御时，可以降低最弱链接和单点失效带来的风险。

攻击者常常试图攻击系统中看起来最薄弱的部分，而不是看起来最坚固的部分。有时软件本身并不是系统最薄弱的环节，而人往往是系统的最薄弱环节。例如，攻击者往往通过钓鱼攻击骗取用户账户与口令，而不是花费时间破解。

软件设计中采用保护最弱一环原则的实例如下。·进行风险分析,标识出系统最薄弱的组件。

·对开发人员或者用户进行充分的安全告知、培训和教育。

9最少共用机制原则

最少共用机制原则是指，尽量减少依赖于一个以上用户甚至于所有用户的通用机制。设计应该根据用户角色来划分功能或隔离代码，因为这可以限制软件的暴露概率，提高安全性。

软件设计中采用最少共用机制原则的实例如下。

·不使用成员与管理员和非管理员之间共享的函数或库，而推荐使用两个互相区分的功能，每一个功能为每一个具体的角色服务。

·使诸如文件及变量等共享资源尽可能少。

10．安全机制的经济性原则

安全机制的经济性原则是指，以较低的开发成本和资源消耗获得具有较高安全质量的软件产品和系统保障。安全机制的经济性也称化繁为简原则KISS ( Keep It Simple，Stupid ) ,在某些情境下被称为不必要的复杂性原则。

保证代码与设计尽可能简单、紧凑是经济性原则的体现。软件设计越复杂，包含漏洞的可能性越大。更简单的设计意味着程序更易于理解，以及减少的攻击面和更少的弱链接。在攻击面减少的情况下，软件失效的可能性就会越小，发生错误间隔的时间更长，需要修复的问题也越少。

安全机制的经济性原则并不是要求压缩安全上的投入。安全性并不是在业务功能之上的华而不实的功能，而是业务功能之下的系统基本保障功能。微软SDL实践也表明，软件安全开发方法并不会增加成本，相反因为减少了用户的损失和后期系统运行维护的成本而降低了总成本。

软件设计中采用经济性原则的实例如下。

·避免设计不必要的功能和不需要的安全机制，然后再将它们置于禁用状态。

·保持安全机制简单，确保安全机制被全部而不是部分实现，因为后者会导致兼容性问题。同样重要的是要保持数据模型简单，使数据验证代码和例程不过分复杂或不完整。正则表达式能够支持复杂的数据验证，简化数据验证的复杂度。

力求操作方便。单点登录（Single Sign On，SSO)是一个使用户认证简单化并易于操作的好方法。

11．安全机制心理可接受原则

安全机制心理可接受原则是指，安全保护机制设计得要简单，要让用户易用，要确保用户对资源的可访问，以及安全机制对用户透明，用户才会使用这些保护机制。

易用性是指用户使用安全机制的方便程度。例如，很多公司实行了强口令规则，如大小写混合、字母和数字混合并且长度要有一定的限制，另外口令也要求定期变更，以减小口令猜测和强力攻击的可能性，而大多数用户记住复杂的口令非常困难，因此他们倾向于将口令记录到一张纸条上并将它们贴到桌子上，甚至于贴到计算机屏幕上。这是一个典型的安全机制在心理上不被接受的实例。

安全机制不应该阻止资源的可访问性，安全保护机制不应该成为用户额外的负担，更不能比没有安全保护机制的情况下对资源的访问更困难，否则用户就会决定关闭或绕过安全机制，从而中和甚至抵销安全保护机制。

透明性主要是指安全机制本身应该对用户透明或者只有极小的使用阻碍，如果用户对于所用的安全机制存在质疑，他们会选择弃用这些安全机制。

软件设计中采用心理可接受性原则的实例如下。

·配置和执行一个程序应该尽可能简单和直观,输出应该直接而且有用。

通过明确的错误信息和标注通知用户，如消息框提示、帮助对话框及直观的用户界面。

12.平衡安全设计原则

以上介绍的这些安全设计原则每一项都有自己的侧重点，将所有这些安全原则都设计到软件中是不可能的，因此有必要在这些安全原则间进行决策折中，即平衡安全设计原则。

例如，单点登录SSO可以强化用户体验，增加心理可接受性，但它与完全控制原则相矛盾，所以SSO可能只是一个候选方案，并且.SSO本身的设计也要考虑单点失效问题和适当的纵深防御机制。另外，为了实现完全控制，每次都需要对访问权限和优先权进行检查,这些工作会对软件性能产生严重影响，所以软件安全设计需要仔细考虑在实现纵深防御策略的同时不降低用户的体验和心理可接受性。

再如，最少共用机制与利用现有组件的开发方法似乎也相互矛盾，这些也需要在不降低软件安全性的前提下，根据业务需求很好地平衡。心理可接受性原则要求每一次的错误都要向用户报告，实际设计时则需要仔细衡量，以避免内部系统配置信息被泄露。

7.软件安全功能设计

P170,老师让看看

8.基于安全模式的软件安全设计

设计模式是对软件设计中普遍存在、反复出现的各种问题，根据多次处理的经验，提出的一套能够快速、准确响应此类问题的解决方案。设计模式描述在各种不同情况下，应解决共性问题。

使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码可靠性和程序的重用性。

设计模式特指软件“设计”层次上的问题。具体算法不属于设计模式考虑的范畴，因为算法主要解决计算上的问题，而非设计上的问题。

安全模式

安全模式是在给定的场景中，为控制、阻止或消减一组特定的威胁而采取的通用解决方案。该解决方案需要应对一系列的问题，并且可以使用 UML 类图、时序图、状态图活动图等进行表述。

基于安全模式的软件安全设计方法过程可以分为三个阶段：风险确定阶段、系统安全架构阶段和系统设计细化阶段。

9.威胁建模：软件威胁建模是指通过抽象的概念模型对影响软件系统的威胁进行系统的识别和评价

为什么要威胁建模

威胁建模是一项在软件设计阶段不应忽视的、系统的、可迭代的、结构化的安全技术。对软件系统来说，资产包括软件流程、软件本身，以及它们处理的数据。在当前超过70%的漏洞来自于应用软件的情况下，解决软件安全问题应该首先明确应用软件面临的威胁，建立威胁模型,然后才能考虑软件的安全设计和编码实现。

威胁建模的过程

第八章

软件安全编码的主要工作：

（1）选择安全的编程语言

所谓安全的编程语言，是指那些具有对缓冲区、指针和内存进行管理能力而避免发生软件安全问题的语言。类型安全语言就属于安全的编程语言。

（2）版本（配置)管理

软件版本管理或控制不仅能够保证开发团队正在使用的程序版本是正确的，同时在必要的情况下也能提供回退到上一个版本的功能;另外，软件版本管理还提供了跟踪所有权和程序代码变化的能力。

（3）代码检测

这里的代码主要是指源代码。代码检测是指对代码质量进行检查，以发现是否存在可利用漏洞的过程。根据代码检测时代码所处的状态，可以将代码分析分为两种类型:代码静态检测和代码动态检测。

代码静态检测是指，不在计算机上实际执行所检测的程序，而是采用人工审查或类似动态分析的方法，通常借助相关的静态分析工具完成程序源代码的分析与检测。

代码动态检测是指，实际运行代码时进行检测的方法。通常依靠系统编译程序和动态检查工具实现检测，但完成后可能仍会存在与安全相关的、在编译阶段发现不了的、运行阶段又很难定位的错误。

4。安全编译

编译是指将程序员编写的源代码转换为计算机可以理解的目标代码的过程。安全编译包括以下4个方面的含义。

1）采用最新的集成编译环境，并选择使用这些编译环境提供的安全编译选项和安全编译机制来保护软件代码的安全性。例如在VS中编译时，开启/GS选项对缓冲区的安全进行检查。

2）代码编译需要在一个安全的环境中进行。编译环境的完整性对于保证最终目标代码的正确性是很重要的。可以采用以下一些保证措施。

●在物理环境上，对代码编译系统实施安全访问控制，防止人为地破坏和篡改。

●在逻辑上，使用访问控制列表防止未授权用户的访问。

●使用软件版本控制方法，保证代码编译版本的正确性。

●尽量使用自动化编译工具和脚本,保证目标代码的安全性。

对应用环境的真实模拟也是软件编译需要考虑的问题。很多软件在开发和测试环境中运行得很好，而到了生产环境中就会出现很多问题，主要原因就是开发和测试环境与实际开发环境不匹配。由于应用环境比较复杂，因此要开发出能够适应所有环境的应用软件并不是一件简单的工作，对环境的适配也是反映软件应用弹性的一个重要指标。

在安全编码阶段，多样化编译技术作为一种提高软件安全性的方法已经得到了应用。

2.CERT安全编码建议：

CERT给出的10条最重要的建议：

1)验证输入(Validate input)。对于不可信任数据源的输入应当进行验证。正确的输人验证能减少大量软件漏洞。这些数据源包括命令行参数、网络接口、环境变量，以及用户文件。

2）留意编译器警告（Heed compiler warnings)。应采用实现了安全特性的编译器，并启用编译器的警告和错误提示功能。不仅要处理和解决代码中的错误，而且也应处理和解决所有的警告,确保不将任何一个警告带入到程序的最终编译版本中。

3）安全策略的架构和设计(Architect and design for security policies)。创建一个软件架构来实现和增强安全策略。例如，如果系统在不同的时间需要不同的权限，则考虑将系统分成不同的互相通信的子系统,每个系统拥有适当的权限。

4）保持简单性(Keep it simple)。这是第7章中介绍的减少软件被攻击面原则的体现。程序越复杂，控制会越复杂，就会增加代码出错的可能。要尽量使程序短小精悍，代码中的每个函数应该具有明确的功能，在编写函数代码时，应在保持功能完整实现的前提下控制该函数内代码量的多少。对于复杂的功能，应将该功能分解为更小、更简单的功能，确保软件仅包含所要求或规定的功能。

5）默认拒绝 （Default deny)。这是第7章中介绍的默认安全配置原则的体现。默认的访问权限是拒绝,除非明确是允许的。

6）坚持最小权限原则(Adhere to the principle of least privilege)。这是一个通用的安全原则，在本书第7章已经提及，这里从编码角度再次重申。每个进程拥有完成工作所需的最小权限，任何权限的拥有时间要尽可能短，以阻止攻击者利用权限提升执行任意代码的机会。

7)清洁发送给其他系统的数据（Sanitize data sent to other systems)。清洁所有发送给子系统的数据，以免攻击者实施注人类等攻击。输人验证后再次净化数据是纵深防御的体现。

8）纵深防御(Practice defense in depth)。这是一个通用的安全原则，在本书第7章已经提及。

9)使用有效的质量保证技术(Use effective quality assurance techniques)。好的质量保证技术能有效地发现和消除漏洞。渗透测试、模糊测试及源代码审计可以作为有效的质量保证措施。独立的安全审查能够促成更安全的系统，外部审查人员能带来独立的观点。

10）采用安全编码标准（ Adopt a secure coding standard)。为开发语言和平台设计安全编码标准，并应用这些标准。多数漏洞很容易通过使用一些规范编码的方法来避免，例如对代码进行规范缩进显示，可以有效避免出现遗漏错误分支处理的情况。

“沙箱”模型的核心思想是:本地环境中的代码能够访问系统中的关键资源(如文件系统等)，而从远程下载的程序则只能访问“沙箱”内的有限资源。

第九章

不知道考啥，都看看吧

有余力的建议看看这个，去年学长留下的复习资料，和我这个互补一下，我也有不少看他的写出来的。