这是一门针对安全过程模型、基于风险测试、威胁分析报告等谈漏洞讲威胁的学科。

软件与软件安全

信息安全与软件安全

信息安全基本属性

安全性、可用性、保密性、可控性、可靠性

恰当的信息安全定义：信息具有保密性，完整性，可用性

软件安全

软件安全 ：软件在恶意攻击下能够正确地完成其功能。
软件安全性 ：软件不被恶意使用或者攻击进而造成用户信息资产损失的属性。包括：
（1）可信性：保护敏感信息不被未授权用户访问
（2）完整性：保护数据不被更改或破坏
（3）可用性：确保资源被授权用户的使用
软件安全保护 ：软件的完整性、可用性、可信性。
（1）自身安全：防止软件丢失、被破坏、被篡改、被伪造
（2）存储安全：可靠存储，保密存储，压缩存储，备份存储
（3）通信安全：安全传输、加密传输、网络安全下载、完整下载
（4）使用安全：防止非法用户授权访问，软件滥用，软件窃取，非法复制
（5）运行安全：确保软件正常运行，功能正常
软件安全研究 ：
如何设计、构造、验证和维护软件以保证其是安全的。
——改进和实现软件安全的 架构、工具、方法

开放系统互连安全的体系架构ISO7498-2

5种 安全服务 ：
鉴别服务、访问控制、数据完整性、数据保密性、抗抵赖
8种 安全机制 ：
加密、数字签名、访问控制、数据完整性、数据交换、业务流填充、路由控制、公证
5种 安全管理机制 ：
可信功能度、安全标记、事件检测、安全审计跟踪、安全恢复

软件安全重要概念

漏洞

安全漏洞 ：可能被入侵者恶意利用的属性，也称脆弱性。漏洞是软件的属性。
漏洞本质 ：通过已授权的手段获取对资源的未经授权访问，或对系统造成损害。
安全事件 ：当系统的某个漏洞被入侵者渗透而造成泄密时，其结果称一次安全事件。
脆弱状态 ：从已授权的状态变换到未授权状态。
攻击：以授权状态或脆弱状态开始，以受损状态为目标的状态变换。

ISO9126质量特性

1.功能性
准确性：功能精确度
互操作性：与其它系统交互
保密安全性：主要是权限和密码
2.可靠性
成熟性：对内错误的隔离
容错性：对外错误的隔离
易恢复性：系统失效后的重新恢复
3.易用性
易理解性；易学性；易操作性
4.效率
时间特性：响应时间；资源利用性：所耗系统资源
5.维护性
易分析性
易改变性：降低修复问题的成本
稳定性：避免由于软件修改而造成意外结果
易测试性
6.可移植性
适应性：无需变动就能适应不同环境
易安装性
共存性：公共环境中与其它软件分享公共资源
易替换性：同样环境下，替代相同用途的产品

缺陷：安全性是软件功能性的子属性->对安全的忽视

安全的代码 ：能够抵抗恶意攻击的代码；安全的代码同时也是健壮的代码
安全性代码 ：实现安全功能的代码
安全的程序 ：安全隐含一定程度信任，实现了期望的机密性、完整性、可用性及其功能

典型软件安全问题

安全问题来源

攻击者
软件存在的攻击路径－攻击面问题
漏洞漏洞是软件的属性，也是软件安全威胁的根源。
产生原因：
（1）软件或协议设计时的瑕疵
（2）软件或协议实现中的弱点
（3）软件本身的瑕疵——良好的、编写安全程序的的编程习惯。
（4）系统和网络的错误配置
可以分为：
（1）设计漏洞：设计错误，往往发现于软件的安全功能特性中。
（2）实现漏洞：实际编码中的安全缺陷。
意外行为：即程序安全缺陷，由于程序脆弱性引起的不适当程序行为。分有意的和无意的两种~~（废话）~~常见缺陷：缓冲区溢出、未校验输入、资源竞争、访问控制问题、认证、授权、加密缺陷。

安全设计问题

密码技术使用的败笔
（1）创建自己的密码技术or选用不当的密码技术
（2）依赖隐蔽式安全
（3）编写到程序中的密钥
（4）错误地处理私密信息
对用户及其许可权限进行跟踪的薄弱或缺失
会话管理、身份鉴别、授权的薄弱或缺失
有缺陷的输入验证
（1）未在安全的上下文环境中执行验证：如在服务器验证而未在客户端验证
（2）验证例程不集中：验证应尽可能靠近用户输入and验证应集中以便核实
（3）不安全的组件边界
薄弱的结构性安全
（1）过大的攻击面
（2）在过高权限级别上运行进程
（3）没有纵深防御
（4）失效时的处理不安全
其他
（1）代码和数据混在一起
（2）错将信任寄予外部系统
（3）不安全的默认值
（4）未做审计日志

C/C++安全问题

问题1：没有安全的本地字符串类型and没有安全易用的字符串处理函数
以NULL终止符表示一个字符串的末尾 -> 容易导致缓冲区溢出
问题2：缓冲区超限覆盖栈中的函数返回地址
栈溢出：函数返回地址在栈中位置紧接本地变量后，该变量缓冲区溢出会覆盖栈中返回地址。预防：精确控制输入变量长度；避免使用无界字符串；使用字符串缓冲区模块。
问题3：printf类型的格式化函数－格式化字符串攻击
sprintf(target, “Name: %s%s%s%s”);从栈中读取四个字符串，但事实上栈中不存在这四个字符串，程序读取栈中原本用于其他目的的值。
问题4：整数溢出
在C语言中，整数的正负标识是默认的；C语言没有任何措施预防整数溢出。

平台实现安全问题

平台：指程序在其中所运行的环境，包括OS及其交互组件。威胁多来自交互和OS
平台问题1：符号链接
符号链接等效于其指向的文件，即攻击者可以借此启动系统中任何程序。
权限——必须检查该文件的符号链接，不可以基于文件名做任何安全方面的判定
平台问题2：目录遍历
CIFS文件共享协议，允许计算机通过网络访问彼此文件系统。攻击者可通过使用“..”向上追溯
平台问题3：字符转换
平台进行升级的时候可能会引入新的字符编码，可能会产生意料外的结果

应用程序安全问题

引起原因：
某个组件的恶意数据在其另一个组件中被当作了合法代码；对涉密信息的不当处理
问题1：SQL注入
在连接到数据库的应用程序上执行自己所构造的查询。输入用户名’or’1=1，数据库里执行Select * from sys_user where username=’’or’1=1’成功入侵
问题2：跨站点执行脚本
来自非受信环境的攻击者可在受信环境注入数据，使其在受信环境作为脚本予以执行。类似于我写了一个脚本在你电教务系统上跑，你以为是你电新功能就输了你的学号密码~~收到了学号密码的我就能为所欲为为所欲为~~
跨站点执行脚本还可以用来访问数据，如用户cookies。<input type="text" name="address1" value="value1from">value后面的值是来自用户的输入，如果用户输入"/><script>alert(document.cookie)</script><!-那么就会变成<input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">嵌入的JavaScript代码将会被执行。

开发过程问题

安全需求和前提条件的文档记录缺乏
交流和文档匮乏
缺少安全过程
部署上的薄弱性：执行部署的一般不属于开发团队，很可能会扩大权限

OWASP

The Open Web Application Security Project
A1-注入：发送的恶意数据可以欺骗解释器，执行计划外的命令或者在未被恰当授权时访问数据。
A2-失效的身份认证
A3-跨站脚本
A4-不安全的直接对象引用
A5-安全配置错误
A6-敏感信息泄漏
A7-功能级访问控制缺失
A8-跨站请求伪造：迫使用户浏览器向存在漏洞的web应用程序发送请求
A9-使用含有已知漏洞的组件
A10-未验证的重定向和转发

安全软件工程

SSE-CMM

在CMM模型的基础上，通过对安全工程进行管理的途径将系统安全工程转变为一个具有良好定义的、成熟的、可测量的先进工程学科。发起者：国防部&国家安全局

开发目的

降低开发和维护系统的花费；
提高工程进度和预算的一致性；
选择合适的承包者。

主要内容

能力方面：

通用设施（增强执行过程能力的实现和制度化实施）-> 公共特征（一组实施，管理和制度化过程的相同点）-> 能力级别（共同工作的一组公共特征，主要增强执行一个过程的能力）
能力级别１――非正式执行
执行基本实施
能力级别２――计划与跟踪
计划、规范化、验证、跟踪执行
能力级别３――充分定义
定义标准过程、执行已定义的过程、协调安全实施
能力级别４――定量控制
建立可测的质量目标、客观地管理过程的执行
能力级别５――连续改进
改进组织能力、改进过程的有效性

域方面：
基础设施（工程和安全实施是安全工程过程中必须存在的性质，指出特殊过程区的目的并属于该过程区）-> 过程区（每个过程区（PA）是一组相关安全工程过程的性质，当这些性质全部实施后则能达到过程区定义的目的）-> 过程类（一组过程区指出活动的同一通用区）

关于安全工程与评估

安全工程分三个基本过程：风险、工程、保证
风险过程：确定产品或者系统的危险性，并对这些危险性进行优先级排序-风险信息
工程过程：针对危险性，安全工程过程与相关过程一起确定并实施解决方案-产品/服务
保证过程：建立起对解决方案的信任，并把这种信任传达给顾客-保证论据

SSAM（SSE-CMM评定方法）
——决定实施安全工程过程的能力；
——定义了安全工程环境便于评定；
——评定时巧妙使用了SSE-CMM体系结构中的两个方面。

SDL安全开发生命周期模型

微软可信计算努力的一个组成部分
基于并行理念的标准软件开发过程
基于威胁建模和测试

SDL概览

SDL从三个方面考虑软件安全的保障：
设计安全: 保护软件自身及其处理的信息并抵御攻击，应从架构、设计和实现上考虑安全
缺省安全: 设计者应假定安全缺陷将会出现。
为了使被攻击时损害降到最小，软件缺省状态应保证安全。比如，最小特权原则。
提交安全: 工具和指南应随软件一起提供以帮助用户安全使用。软件更新应易提交。

SDL过程

教育和意识
1. 安全设计基础：受攻击面分析、深度防御、最小特权、安全默认配置
2. 威胁建模：设计威胁建模、编码威胁建模、测试威胁建模
项目启动：SDL覆盖应用，安全顾问及领导团队，BUG标准、BUG追踪中含安全、隐私类BUG
最佳设计阶段：
1. 常见安全设计原则，如最小特权，权限分离、最少公共机制等
2. 受攻击面分析：枚举所有接口、协议以及可执行代码的过程。
3. 受攻击面降低：代码中一定存在漏洞，部分严重漏洞用户不得不去妥协。唯一解决的方法是将代码的利用率降至为零。
  受攻击面降低的方法：综合考虑完美的安全与无法规避的风险，尽可能减少未经信任的用户可能接触到的代码比例：
  （1）降低默认执行的代码量
  （2）限制可访问到代码的人员范围
  （3）限定可访问到代码的人员身份
  （4）降低代码所需权限。
产品风险评估：
1. 安全风险评估：安装、受攻击、移动代码（ActiveX）
2. 隐私影响分级：分级1：存储或转发个人信息，儿童相关，不间断监控，安装新软件or改变文件类型的关联（改变IPEG解码）。分级2：传输匿名数据。分级3：其余。
3. 统一各种因素：确定安全与隐私风险后必须在日程中排出响应时间，减少客户风险。
风险分析/威胁建模：
优点：
（1）有助于整个风险管理过程
（2）进入编码阶段前发现系统威胁
（3）通过威胁建模重新验证其架构与设计
（4）进一步明确针对应用及环境采取相应的解决对策
（5）指导整个代码审核过程和渗透测试过程
威胁建模过程：
（1）定义应用场景、收集外部依赖列表
（2）定义安全假设、创建外部安全备注
（3）绘制待建模应用的一个或多个数据流图
（4）确定威胁类型
（5）识别系统威胁、判断风险并规划消减措施
创建安全文档、工具：安装、使用、帮助、开发文档；禁止端口和不必要服务etc.
安全编码策略：使用最新版本编译器及其内置防御特性，使用源代码分析工具
安全测试策略：模糊测试、渗透测试、运行时测试、重审威胁模型、重估受攻击模型
最后五个阶段
安全推进活动：代码评审、安全测试、更新威胁模型
最终安全评审：威胁模型评审、未修复安全BUG评审、工具使用有效性验证
安全响应规划：建立安全的响应过程
产品发布阶段：用户验收，确认SDL过程被正确执行
安全响应执行：遵从计划尽可能补救

SDL缺陷

SDL过程不能保证生产出绝对安全的软件：
（1）开发团队一定会出错
（2）新漏洞一定会变化
（3）规则一定会变化

软件安全测试

安全测试

安全性测试：验证应用程序安全等级and识别潜在安全性缺陷。
安全指标不同测试策略不同。
目的：查找软件程序设计中的安全隐患and检查应用程序对非法侵入的防范能力。
法律问题：安全测试及工具应用必须得到授权；未明确授权下，不允许针对第三方系统进行穿透测试实验

安全测试方法

静态测试：对源码进行安全扫描，与特有软件安全规则库匹对，找出潜在安全漏洞。
编码阶段使用，适用早期代码开发阶段，而不是测试阶段。
动态测试：即渗透测试使用自动化工具或人工方法模拟黑客输入进行攻击性测试，找出运行时存在的安全漏洞。
真实有效，问题一般正确且严重。缺点：测试数据只能达有限的测试点，覆盖率低。
程序数据扫描：进行内存测试，发现许多诸如缓冲区溢出的漏洞，这类漏洞使用其他测试手段都难以发现。

内容（测试点）：程序安全性测试、数据安全性测试
程序安全测试：用户权限、用户冲突、密码保护
网络安全测试：防护配置（系统补丁）、模拟非授权共计、检查漏洞、木马、外挂
数据安全测试：系统数据的机密性、完整性、管理性、独立性、可备份和恢复能力

安全的常规测试方法

基于风险的安全测试

安全测试目标：给定的时间和资源不变的情况下，尽可能多地找出最严重的安全缺陷。
威胁建模＝风险建模

信息搜集
目的：熟悉程序的设计、了解程序访问入口点位置和需要保护的信息
（1）评审程序设计文档
（2）与设计人员和架构师会谈
了解组件框架、组件间主要数据流、程序外数据流（非受信数据，攻击性输入）
（3）在运行时用调试和诊断程序分析
运行时分析应用程序痕迹：网络端口、文件、注册表键值
威胁建模
目的：排定测试优先级，找出测试区域，发现系统弱点
1. 识别威胁路径
  目的：识别应用程序级别最高的风险领域，确定相应的保护措施
  （1）了解应用程序平台和编程语言的整体强度
  （2）确定用户的访问类别
  （3）建立并分析数据流图
2. 识别威胁
  目的：深入识别威胁路径的处理，理清与处理相关的每一种威胁。
  该组件执行什么样的处理、如何确定身份、是否信任数据或其他组件、修改了什么数据、有何外部连接
  在一个威胁路径上的9个高风险活动：
  （1）数据解析、处理私密数据
  （2）文件访问、数据库访问、网络访问
  （3）生成子进程、同步或会话管理
  （4）身份鉴别、授权
3. 识别漏洞
  目的：找出可能存在于组件中的实际漏洞。
  对漏洞的可能缓解措施：
  （1）数据验证测试
  （2）资源监视
  （3）关键功能的访问控制
  搜寻漏洞的方法及途径：
  （1）安全设计审查
  （2）安全代码审查
  （3）安全测试
4. 风险分级——DREAD模型
判定可利用性
目的：判断漏洞是否可被攻击者利用。
基本原则：开发中直接修补一个漏洞比浪费时间判定其是否会被利用容易。

白盒、黑盒和灰盒测试

白盒测试可以看作是内部的攻击。
测试人员可以访问源代码和设计文档，可以进行威胁建模或逐行的代码检查。
白盒测试是找出漏洞最为有效的方法。
黑盒测试是白盒测试的补充。
以局外人身份攻击系统，使用工具检查系统的攻击面，并探查系统的内部信息。
方向工程团队利用黑盒测试验证隐蔽式安全方法的强度。
组合使用白盒测和黑盒测试。
白盒测试用于发现在设计和开发中详细说明的功能的缺陷；
黑盒测试在无法了解程序内部信息的时候找出缺陷。
程序开发中的调试运行是典型的灰盒测试方法。

安全漏洞分级

DREAD模型：进行威胁程度级别分析的有效技术
（1）潜在的破坏：如果该漏洞被利用，所产生的破坏程度
（2）再现性：探测并利用该漏洞所需要的努力要多久
（3）可利用性：是否需要身份鉴别或者特殊的知识
（4）受影响的用户：漏洞利用的影响面有多大
（5）可发现性：漏洞研究人员或黑客找出该漏洞的可能性
基于可利用性提出TRAP模型：
（1）时间：某些漏洞可能需要长时间的探测才能利用。
比如解个密要算一千年，那风险肯定很低。
（2）可靠性/再现性：漏洞的严重程度依赖于可被攻击者利用的程度。
通常高级别漏洞的可靠性和可再现性高。
（3）访问：利用漏洞通常可以为攻击者提供更高的访问权。
（4）定位：攻击者必须要能与存在漏洞的应用程序交互，并访问到含该漏洞的代码。

编写安全的代码

SD3

Secure by Design, Default, Deployment

安全设计

（1）安排具体的安全设计人员；进行安全教育；
（2）确保威胁分析已经完成；符合安全设计和编码的指导原则；
（3）尽可能修补安全编程指南上BUG；确保安全指南是逐步改进的；
（4）回归测试已修复缺陷；简化代码和安全模型；打包前完成穿透测试。

缺省安全

（1）缺省状态下，不要设置所有的特点和功能；
（2）允许最小权限；恰当的资源保护。

安全提交

（1）确认程序给管理员提供了安全功能；尽可能提供高质量补丁；
（2）提供足够信息使用户安全的使用软件。

安全规则

（1）学习错误；最小化攻击面；
（2）使用深度防御；应用缺省安全；
（3）使用最小权限；基于错误计划；
（4）记住兼容性的倒退是痛苦的；
（5）假定外部系统是不安全的；
（6）切记安全的特性不等于安全特性；
（7）不要混合编码和数据；正确修复安全问题。

学习错误

学习错误从填写一个文档开始，文档内容：
产品名称；产品版本；联系人；BUG数据库编号；
脆弱性描述；脆弱性的隐含意义；
在产品的缺省安装中，这个问题是否存在？
设计，开发和测试人员能够做什么来防止这个缺陷？
修复的细节，包括代码的区别，如果可以填写。

最小化攻击面

需要计算下面的内容：
（1）打开socket、命名管道、RPC端点的数量；
（2）服务的数量；缺省运行服务的数量；服务以提高权限运行的数量；
（3）ISAPI过滤器和应用的数量；动态WEB页面数量；加入管理员组帐号的数量；
（4）文件，目录和注册键值的数量，带有弱访问控制列表。

一个信息系统的安全模型分析

信息系统MIS及其特征

借助自动化数据处理手段进行管理的系统
由计算机硬件、软件（系统软件、应用软件、管理学软件包）、数据库规程和人共同组成。

由人、计算机等组成的能进行管理信息的收集、传递、加工的信息系统。
主要特征：
（1）一定是依赖于计算机的；
（2）涉及了计算机的软件和硬件；
（3）实现数据的采集、传递、加工、处理功能。
主要特性：
（1）整体性：系统各部分一定以整体目标为目标，追求全局最优；
（2）目的性：一个系统一定具有明确目的标，并完成一定的功能；
（3）层次性：一个系统可分为若干层次和子系统；
（4）边界性：每个系统明显区别于其他系统，系统间有明确界限；
（5）关联性：系统包括若干元素，元素间存在一定关联性；
（6）环境性：系统处于一定的环境之中并受环境影响。
主要类型：
宏观的国家经济信息系统；面向基层的企事业管理信息系统；
事务型管理信息系统；办公型管理信息系统；专业型管理信息系统等；
运行环境要素：
（1）物理世界；
（2）管理者实体：拥有授权管理、变更、修复和使用系统的人或其他系统
其中一些被授权人可能缺乏有效管理系统的能力或具有恶意的目的；
（3）使用者：在使用界面接受系统服务的实体；
（4）提供者：在系统使用界面提供服务的实体；
（5）基础组织：对系统提供信息源、通信链接、能源、冷气等特定服务的实体；
（6）入侵者：企图超越其权限来变更或阻止服务，变更系统功能、性能或存取秘密信息的实体。

信息系统的安全问题

ISO7498-2五种安全服务类型：
（1）身份鉴别；
（2）访问控制；
（3）数据保密；
（4）数据完整性；
（5）抗抵赖。

安全模型

系统的使用者划分为：用户、系统管理员、信息主管（或企业主管）
系统划分为：用户界面逻辑、业务逻辑、异常检测机
系统安全功能：访问控制；抗抵赖；数据保密；身份鉴别；授权机制；日志审计；系统异常探测。

用户界面逻辑

用户界面逻辑部分：数据访问、登录控制。
系统启动时，用户首先登录系统，通过验证后才能数据访问。
登录控制主要功能：口令验证；口令修改；口令数据的加密；登录时间记录。
登录控制设计考虑：
（1）用户ID：从权限数据中提取相应用户名，回避重名，简化输入
用户号本身也可以增加一定的安全性。
（2）用户修改口令，而非系统管理员：管理员授权，但口令由用户输入加密存到后端
避免系统管理员获取用户口令造成泄密。
（3）初始口令的安全：系统初次运行关键——初始口令的赋予，由信息主管（或其他高层）完成用户身份确认
要求用户初次登录时必须更改初始口令。
（4）口令安全：口令长度限制、字符集限制、有效期限制。
（5）用户封锁：用户多次登录失败后系统锁定用户操作，解锁必须由系统管理员完成。

业务逻辑

业务逻辑部分：
（1）数据服务：完成特定数据的加密、解密，日志数据的存储，权限及用户信息的存储
（2）权限管理：完成用户的授权，包括两个部分：系统管理员和信息主管。
系统管理员负责日常权限管理、日志审计、系统状态监控、异常监测、用户锁定处理。
信息主管负责系统启动和初始授权。
（3）日志审计：对用户的操作行为进行跟踪，提供根据时间、用户、系统的检索手段。日志不能人工清除，怕被管理员在后台清掉。log周期性自动清旧信息，保留最新信息。
信息系统提高安全可信性的重要手段：合理并具有一定强度的日志设计。

异常探测机

主要功能：分析日志、网络状态的安全监测、提供一定的日志文件保护机制
异常检测独立于业务逻辑的目的：
（1）独立程序便于进一步发展，有较大发展空间；
（2）位于业务和用户进程之外，能对其进行监控；
（3）不对信息系统运行发生干扰；
（4）作为系统的可选件而非强制。

异常行为探测

区别内容	异常探测机	IDS
检测范围	网络内部行为	网络外部行为
实现方式	软件	硬件
与系统关系	可以存取系统数据	不能存取系统数据
保护目标	信息系统	网路

异常行为

用户身份的攻击：针对用户的ID猜测用户身份。采用ID登录原因：方便输入&安全性。猜测三次后用户被封锁。
口令攻击：已知用户身份来猜测口令。在系统设计中，当猜测三次后则封锁用户。
服务器异常访问：Sever PC和Web Sever等专用服务程序。类似局域网内DOS攻击。
数据库异常连接：主要通过特定端口访问DB，威胁来自合法或非法的客户端程序。

日志分析

针对日志文件自身的攻击

（1）日志数据的删除：系统不向用户提供日志修改功能。
合法用户不具有删除log的能力，只有超过log过期时间的日志数据才可删除。
非法用户受到异常探测机、操作系统、数据库系统的安全机制约束。
针对非法用户的攻击——
如果是单独的log，当系统启动后，该文件置于异常探测机的保护之下；
如果是数据库数据，则依赖于操作系统和数据库本身的保护机制。
（2）日志数据的修改：系统不向用户提供日志修改功能。
日志浏览需要授权，当系统管理员身份浏览日志时，该操作本身也将被写入日志。
由于单独的日志文件置于异常探测机的保护之下，所以可以避免合法用户的修改。
非法用户试图修改数据库中日志数据时，会受到操作系统和数据库系统的约束。

日志数据审计和异常模式

（1）手动审计：提供必要的数据检索和查询的手段
可根据用户、授权人、时间段、功能等进行检索，以进行必要的分析和事件跟踪。
（2）自动审计和报警：根据日志数据，系统可自动完成的审计和报警功能
用户锁定；口令超期；异常时间访问；异常功能访问；异常授权

网络异常探测机

网络异常探测机：针对来自网络的信息进行分析，提供对信息系统的保护报警。
探测器并不是通用的系统异常探测器。
（1）数据流量检测；
（2）服务器连接异常：连接数量异常、连接主机异常、连接端口异常。
（3）文件访问限制；
（4）日志文件保护。

WEB应用安全

WEB APPLICATION

采用HTTP协议完成通信
与后台WEB Server实现交互
与互联网服务器，包括Web Server，database server进行交互
位于中间层，进行数据交互或其他服务程序

WEB应用安全现状：
WEB应用安全实现非常困难
WEB应用环境包括多个系统
WEB应用大部分运行于INTERNET，具有更广的攻击面
WEB应用运行中，具有更多的临时决策以支持系统的运行，系统状态具有更多的可变性
许多支持系统没有得到恰当的保护

微软WEB应用安全框架

WEB应用安全建模

活动：Web 应用程序的威胁建模
目的：确定方案中相关威胁和漏洞，以帮助构建应用程序的安全设计。
输入：主要用例和使用方案、数据流、数据架构、部署关系图
输出：威胁列表、漏洞列表

威胁建模：
步骤 1 ：确定安全目标。业务需求、安全策略、兼容性要求 -> 主要安全目标
步骤 2 ：创建应用程序概述。列出重要特征和参与者有助于步骤 4 确定威胁。
步骤 3 ：分解应用程序。
部署关系图、用例、功能说明、数据流关系图 -> 信任边界、入口点、出口点、数据流
（在网络层，每个服务代表了一个入口点）
步骤 4 ：确定威胁。使用步骤2&3中的详细信息来确定相关威胁。
步骤 5 ：确定漏洞。检查应用程序的各层以确定与威胁有关的弱点。
使用漏洞类别来帮助关注最常出现错误的区域。

输入验证：在进行其他处理前如何筛选、删除或拒绝输入
身份验证：一个实体验证另一个实体身份的过程，通过如用户名和密码的凭据进行
授权：提供对资源和操作的访问控制的方式
配置管理：处理运行身份、数据库连接、应用程序管理、设置保护
敏感数据：处理必须受到保护的所有数据，不管数据在内存、网络还是永久性存储中
会话：用户与Web 应用程序之间的一系列相关交互
加密：应用程序保证机密性和完整性的方式
参数操作：既指保护这些值不被篡改的方式，也指处理输入参数的方式
审核与记录：记录与安全相关的事件的方式

一个WEB应用安全模型

威胁建模：一种用于理解和消除系统安全威胁的形式化的方法
（1）信息收集：定位文档、访问相关人员、探查系统
（2）分析：用户、构件，资产，动机、入口、弱点和威胁
（3）威胁消除：建立预算、排序处理、确立针对威胁的工作
消除的选择：大概率会忽略，毕竟入侵代价昂贵、安全代价昂贵，搞不好不能承受
消除的策略：移除入口点、减少攻击面、区分、最小优先权原则
消除的技巧：
1.建立子模型分支来减小复杂性
2.开发可重用的威胁模型库
3.先不做假定，消除多数明显的威胁会大大简化

一个安全工程过程模型

核心工作

1.安全目标定义：形成规范的文档，作为工程过程中的指导原则
2.敏感数据分析：确定涉及的敏感数据并分类，给出明确定义、敏感程度和保护措施
3.威胁分析：确定系统威胁来源，明确关键工程，部署，各部分及功能用户
4.安全设计：根据前三部分实现安全设计。包括架构，安全问题应对措施等
5.受攻击面分析：与安全设计对应，根据架构及敏感信息，对受攻击面
（端口，数据，文件）及攻击路径进行分析
6.安全实现：掌握安全实现方法，库及安全编码原则。针对安全目标，敏感数据，明确威胁的主要应对措施。
7.安全测试
8.安全维护