软件安全策略
@author：alkaid
生命以负熵为食 —— 《生命是什么》薛定谔
背景
我想作为一个信息安全从业者，无论是在渗透测试、代码审计亦或是其他安全服务中都会接触到各种各样的漏洞。把这些漏洞进行简单分类可能能够得到几十类漏洞，当然几乎所有的漏洞类型在common Weakniss Enumeration都有相应的描述。
- 面对类型如此丰富漏洞，我们要如何进行处理呢？
要知道人类的本质是懒惰，逐条进行分析验证几乎是不可能的。而且渗透测试、红蓝对抗等服务在本质上都是为了达到以点带面的目的，那么这个面在哪里是值得我们去思考的问题。
废话扯完了，进入正题。
安全策略框架
- 本文所说的安全策略，即系统采用的方式用于处理可能存在的安全风险。
我这边简单的梳理了一下，在考虑软件安全时需要考虑的几个方面的问题，（在标题中斗胆用了框架这个词，我希望这样框架确实能够帮助到更好的实现软件安全），图如下：
- 身份认证策略、访问控制策略、会话管理策略这三个方面基本上属于整个软件安全的基石，如果这三个方面缺少了相应控制或者实现的大方向上存在问题，那么对于整个软件的影响极大，可能是颠覆性的需要推到重建。
- 对抗中间人： 对于中间人攻击大部分人的看法可能是属于软件后期的部署问题，采用https/HSTS就没什么问题（问题可能并没有这么简单），不过我还是把它纳入到框架。
- 输入输出： 这可能有点老生常谈，不过我觉得清楚的了解对于软件而言是输入，什么是输出，可能会更好进行分析。
- 敏感数据：在网络逐渐形成虚拟社会的背景下，其开放性的特征必然会引起有关部门的注意，作为一项重要的合规项应当在初期就纳入考虑到。同时如果出现相应的问题，软件修复起来极其头疼，完全可能出现修不完的情况，在投产的过程触犯了相应的法规造成的损失可能也极其巨大。
- 软件技术栈： 白话一点的说法就是软件都用了什么技术。
- 配置管理： 一些意料之外漏洞可能都出自于错误的配置管理，诸如交易日志泄露
异常处理： 安全对抗的本质是获取信息，尽可能的获取一些常规获取不到的信息，异常是一项比较重要的来源。
身份认证
概念
- 在虚拟世界中的身份认证同现实世界中一样，首先需要识别人，建立在识别的基础能够去开展各项业务，产生、处理、使用、存储数据。 只是目前而言，由于你是真实存在的，不会出现类似于证明你是你问题，而虚拟身份的更像是一个物化的概念，那么身份认证就是能够证明虚拟身份是属于现实的你。
- 所以在虚拟世界这是一个必须要解决的问题——如何让真实的你与虚拟世界中虚拟的你进行绑定。
- 那么最直接的方式就是提供秘密——只有账号的拥有者持有的信息。例如在账号注册时输入的密码信息、密保信息
- 换句话说，在虚拟的世界中只要能够提供账号的相关的秘密信息，就能声明账号的所有权。因为对于全知全能的程序而言，它都是仅仅收到了这个秘密，你和他并没有区别。
- 举个例子：
- alkaid登录账号alkaid，输入了密码password，程序验证通过，允许以alkaid账号执行相关业务
- person2 不知道通过什么途径知道了，alkaid/password的认证信息，程序验证通过，允许以alkaid账号执行相关业务。
风险与处理
- 现在身份认证应该就是很清晰了，其实就是验证虚拟账号的秘密信息，那么要知道只要是验证信息就会返回成功和失败的结果，从一定程度这也是一类信息泄露，只是信息泄露的量较少，通过不断累积信息，就能最终破获秘密信息，也是身份认证主要的风险点。
- 这类风险的直接体现就是暴力枚举破解账号。
- 当然，这风险属于无法解决的，我们只能采用降低风险，使风险可控的方式：
- 解决累积信息的特点。
- 账号锁定机制
- 由于完美解决1是相对困难的（主要是引入的不可用风险不一定能被接受），也可以采用提高目标的信息量的方式，在有限的时间维度内，无法破解账号
- 提供秘密信息的复杂度，例如密码的复杂度
- 采用验证码技术，防止通过机器突破现实人的极限。
- 减少单次信息累积的量
- 模糊失败的错误提示
- 解决累积信息的特点。
- 其实还有其他的无法解决的风险，例如秘密信息被窃取。所以一般还会要求提供更换秘密信息的功能。
- 采用生物信息的技术让人难以接受的是无法进行更新秘密信息，如果需要更换可能需要重新设计相关的算法和信息采样的算法，可能会要求所有虚拟用户同时更换设备和秘密信息。
会话管理
概念
- 由于HTTP协议属于无状态（每个数据包都是独立的，仅根据数据包无法判断之前发过哪些数据包）的协议，同时在身份认证一节中已经说明大部分的业务操作是需要基于虚拟身份进行的，那么在完成身份认证后，后续数据包无法回溯之前的数据包，从而导致无法证明自己确实能够持有声明的虚拟身份。
- 当然如果每次都带着身份的秘密信息请求进行确实是可以进行身份认证，但是频繁的使用这类秘密信息可能会增加秘密信息泄露的风险。
- 现实的生活中由于时间和空间的限制，基本上不存在这类风险，我们也很难进行参考。
- 不过这类问题反过来——如何让服务器知晓是你这个真实的人在操作你的拥有的虚拟身份（问题又回到了身份认证）
- 同身份认证一章节所述，那就是掌握秘密信息。
- 即服务器与我商量一个只有我们两个人知道的临时秘密，来替代原先虚拟身份的秘密。
- 临时秘密作为虚拟身份的秘密的替代品，在每次访问时都进行提供。—— 临时秘密即我们一般而言的sesssionID（会话ID）。
会话管理，即围绕sessionID是怎么进行处理的。
- 再绕一点，是不是觉得会话像是系统给我开设的临时虚拟身份，但是同时具有原先虚拟身份的信息？
- 确实没错，会话从某种程度上来讲与账号其实没有区别，也能够提供相应的信息存储，只不过会话是临时的。
风险与处理
- 会话与账号相似，其面对的风险也与身份认证相同。
- 但是由于是相似（如果完全相同，又会回到最开始的问题——无法证明自己确实能够持有声明的虚拟身份），会话最大的一个特征是临时性。 由于预置的时间属性，基本我们采用2中的复杂度方式。
- 如何来尽可能的保证的复杂度呢？
- 随机生成的符号组合。（避免组合单词，账号信息等，从信息熵的角度来说，尽可能避免与已知信息相关联，关联的越多，这段数据包含的信息越少，越容易被猜测）
- 一定长度的保证（每一位的长度增加，破解难度都是成倍提高）
访问控制
概念
- 鉴于可能会与我们学习过的MAC、DAC、RBAC混淆，这节讨论的东西不是这些具体的策略，谈论这些具体的策略，可能搜索一下google、wiki来得更加方便和准确,是讨论访问控制解决什么问题，面对什么样的风险。
涉及到访问控制，自然有两个概念，主体和客体。
主体
- 一般指提出访问请求的对象。在实现身份认证和会话管理的基础上，主体相对明确，有两类构成
- 虚拟身份代表的主体
没有虚拟身份，（代表了所有未授权的情况）
客体
一般指被访问的资源。 具体哪些资源其实在相关的系统里是很难明确的，这里我仅提及两类，功能和数据。 它们应该是在各类系统中最最常见的两类资源。
分析
- 既然是虚拟时间，如果排除了空间和时间的影响，其本质应该是一样的，现实中与安全性质类似场景包括消防、防盗、安保等
- 这里以我居住的小区为例，alkaid 住在A小区1幢11层1111房间。
- 我需要回到我的房间需要经过，小区的门禁、1幢的门禁、1幢的电梯梯控、1111房间的钥匙、密码。
- 我们讲现实的场景与虚拟的场景进行映射，帮助进行分析也方便大家思考，发现一些我可能没有提到的东西。
- 小区的门禁，相当于系统的身份认证，通过门禁确认我属于小区的住户
- 进入小区后，处于会话管理的范畴内，当我只持有1幢的门禁和梯控，相当于只允许我访问某些功能。
- 而房间钥匙则对应着我的数据访问权限。
- 而小区的跑道和绿化则属于授权用户的公共资源， 小区外的其他则属于任何人都能访问的资源
小区中遍布的监控能够支持对行为的审计
总结
- 在访问控制方面，我们至少需要几点：
- 功能级别访问控制
- 针对用户数据或者其他资源的数据级的访问控制
- 梳理公共资源以及个人的资源
- 监控与审计
风险与处理
- 风险也围绕着我们在上文所说的几点
- 相关资源的访问控制（即门禁的设计）。
- 根据系统不同的需要，对不同的资源设置相应的访问权限。毕竟在一般情况下，我房间应该只有我以及我授权的相关人员能够进入
- 需要评估和确认访问权限设计的有效性，满足最小化的原则
- 对于资源默认的访问权限应当是拒绝
- 授权绕过/未授权访问
- 在系统变更过程中是否持续对资源进行梳理和监控
- 侧信道/信息推测
- 例子的描述： 房间里会有窗户，可能透过窗户能够看到一些 或者 分析你的生活习惯推测一些信息。 从描述来看，风险相较于其他几项较少
- 之前提到过，我们忽略了时间和空间的影响。在虚拟世界中可能会存在直接访问到我个人房间的情况，所以一般情况下我们首先需要去验证访问者是否持有认证通过后持有的虚拟身份。（一般这个操作在软件系统中会作为全局拦截器来实现，相当于将所有的资源纳入到门禁的范围内，避免在实现新增功能时，忘了考虑这类情况，从而产生风险【该类情况即使通过审计发现，也无法进行追溯】。）
总结
- 本文暂时只分析三个基础策略，后续会进行更新其他的内容。