[太原理工大学] 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 ) ,在某些情境下被称为不必要的复杂性原则。

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

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点！真正的体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

原则。

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

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

[外链图片转存中…(img-QUh76bSz-1715561531921)]

[外链图片转存中…(img-K7uw9iHu-1715561531921)]

[外链图片转存中…(img-9v4EffFG-1715561531922)]

[外链图片转存中…(img-qqqphSgJ-1715561531922)]

[外链图片转存中…(img-wSvI6ndw-1715561531922)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点！真正的体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！