1. 安全测试

1.1. 测试是开发可靠、安全代码中的关键一环

1.2. 测试安全漏洞的目的是主动检测

1.3. 模糊测试是一种强大的补充技术，可以帮助我们找到更深层次的问题

1.4. 针对当前漏洞创建的安全回归测试，目的是确保我们不会再犯相同的错误

1.5. 大多数测试都是由执行代码组成的，其目的是校验软件是否能够按照设计目的工作

1.6. 安全测试则正好相反，其目的是保证不允许执行的操作无法执行

• 1.6.1. 安全测试必不可少，因为安全测试可以确保缓解措施发挥了应有的作用

• 1.6.2. 编写代码的人只专注于让目标功能在常规使用场景中能够正常工作，而那些出乎意料的攻击则很难进行预测

• 1.6.3. 安全测试可以预期到这类情况并且确保代码拥有必要的保护机制，从而提升代码的安全性

• 1.6.4. 对于那些安全性至关重要的代码，推荐对它们进行彻底的安全测试，以确保代码的质量尽可能高

• 1.6.5. 安全测试恐怕是我们能够迅速提升应用安全的最理想方式，而且执行安全测试一点也不困难

• 1.6.6. 在软件行业，并没有任何公开数据可以反映安全测试的普及程度，但是从相同漏洞总是反复出现这一点来看，安全测试显然没有得到足够的重视

1.7. 整数溢出

• 1.7.1. 建立允许值的范围，同时确保检测并拒绝超出这个范围的值

1.8. 内存管理问题

• 1.8.1. 测试代码是否正确处理了超大的数据值，并且在数据值太大时拒绝这个值

1.9. 不可靠输入

• 1.9.1. 测试各类无效输入信息，以确保这些数值要么被拒绝，要么被转换为能够安全处理的有效输入形式

1.10. Web安全

1.11. 异常处理缺陷

• 1.11.1. 强制代码通过各类异常处理路径来检查其是否能合理地恢复

1.12. 它们都偏离了代码正常使用的范围，因此这些用法都很容易被人们忽视

1.13. 所有这些攻击方法都已经非常成熟，所以进行彻底的测试一定会产生明显的效果

2. 功能测试

2.1. 功能测试的目的是验证代码是否按照人们预期的方式运行

2.2. 更加彻底的功能测试还可能包含一些其他的测试用例

• 2.2.1. 对失败的校验（即非0的返回码）进行检查

3. 安全测试的限制

3.1. 安全测试的目标是在代码中检测出失败的潜在主要原因，但安全测试无法涵盖代码出错的所有情形

3.2. 有可能出现一类漏洞正好是我们编写的测试无法检测出来的，不过这种情况在不经意间出现的概率不高

3.3. 除非测试覆盖的范围非常完整，否则还是有可能存在通过编写bug来躲避测试的

3.4. 原则

• 3.4.1. 安全测试对那些强调安全性的代码来说尤为重要

• 3.4.2. 最重要的安全测试往往会对某些行为进行校验

• 3.4.2.1. 如拒绝访问、拒绝输入或者执行失败（而不是成功）​

• 3.4.3. 安全测试用例应该确保每一个关键步骤都能正确执行

4. 安全测试用例

4.1. 安全测试用例可以确保某一种特定的安全失败不会发生

4.2. 渗透测试是指好人在软件中寻找漏洞，其目的是在坏人发现漏洞之前对其进行修复，渗透测试不会尝试找出所有可能的漏洞

4.3. 安全测试也和渗透测试有所不同，因为安全测试还会对被发现的漏洞提供保护

4.4. 安全测试用例会校验主动机制是否正常工作，因此往往会涉及对无效输入和不允许执行的操作的拒绝

4.5. 应该在编写其他单元测试的时候创建安全测试用例，而不是在发现漏洞的时候才撰写安全测试用例

4.6. 安全系统会通过阻塞不合理的行为、拒绝恶意的输入、拒绝访问等方式来对宝贵的资源进行保护

• 4.6.1. 只要存在这类安全机制，我们就应该创建安全测试用例来确保那些未经授权的操作一定会以失败告终

4.7. 常见的安全测试用例包括测试使用错误密码登录的尝试失败、从用户空间对内核资源发起未经授权的尝试失败，以及无效或伪造的数字证书永远都会被拒绝

4.8. 阅读代码是编写优质安全测试用例的理想方法

4.9. 测试输入验证

4.10. 测试XSS漏洞

5. 模糊测试

5.1. 模糊测试是一种自动创建测试用例的方式，其目的是通过测试输入来“轰炸”目标代码

5.2. 模糊测试可以帮助我们判断某个输入是否有可能导致代码出现问题，或者导致流程崩溃

5.3. 模糊测试这种分散的方法也可以相当有效地发现更大范围的错误，其中一些错误就是软件的漏洞，在这一点上，模糊测试完全不同于为特定目的而编写的安全测试

5.4. 典型的方法是“模糊”那些不可靠的输入（即尝试各种不同的值）​，然后查找异常的结果或者崩溃的情形

5.5. 很多库都提供了各式各样的模糊功能，从随机模糊到基于特定格式（如 HTML、XML 和JSON）的知识所生成的变体

6. 安全回归测试

6.1. 安全漏洞一经发现和修复，就没人希望再被相同的漏洞袭扰

6.2. 在对新发现的安全漏洞进行响应时，有一项重要的最佳实践，那就是创建一个安全回归测试来检测潜在的错误

6.3. 安全回归测试的作用是对漏洞进行简单重现（重现错误）​，以确认我们的修复工作在事实上消除了漏洞

6.4. 一些安全漏洞回归的情况比新的漏洞还要糟糕得多

• 6.4.1. 苹果在2019年发布iOS 12.4的时候，这个版本重新引入了在iOS 12.3中已经发现并且修复的错误，这无异于推开了一扇本应该已经牢牢关闭的大门

6.5. 一个理想的安全回归测试应该尝试多种测试用例，而不是针对某一种已知攻击建立测试用例

6.6. 除了解决新发现的漏洞之外，通过调查也可能会在系统的其他地方发现类似漏洞，这些漏洞同样可以被攻击者利用

• 6.6.1. 我们可以利用自己对系统内部的了解和对源代码的熟悉，在同对手的竞争中占据先机

• 6.6.2. 攻击者很可能也是按照相同的思路来思考，而发布修复程序无异于是在给攻击者提供如何攻击自己的系统的线索

7. 可用性测试

7.1. DoS攻击表示一种特殊类型的威胁，因为系统能够承受的负载上限是很难加以归类的

7.2. 负载(load)这个词包含多重含义，包括处理能力、内存占用、操作系统资源、网络带宽、磁盘容量以及其他可能存在的瓶颈

7.3. 安全测试还可以避免故意利用性能漏洞的攻击方式

7.4. 安全测试应该有能力判断出性能有可能呈非线性下降的代码

7.5. 资源消耗

• 7.5.1. 对于那些我们深知有可能受到可用性攻击威胁的功能，我们应该增加安全测试用例（对资源）​，并且确定输入的合理限制以防止负载过高

• 7.5.2. 一种简单的方法可以防止代码变更导致内存消耗急剧增加，那就是人为制造资源受限的条件并允许测试

• 7.5.3. 单元测试应该在内存非常受限的条件下运行

• 7.5.4. 更大规模的集成测试则要求测试时使用的资源与生产中的可用资源相仿，如果使用与生产中几乎完全相同的资源来运行测试，测试就可以起到警示作用

7.6. 冒烟测试、负载测试和兼容性测试

7.7. 阈值测试

• 7.7.1. 一种保护系统可用性的重要方式很容易被人们忽视，那就是在达到基本限制之前建立一个警告标志

• 7.7.1.1. 如果对计数器值进行监测并且在数值接近上限（如0.99*INT_MAX）时发出警告，灾难原本可以避免

• 7.7.2. 对阈值进行告警的工作往往被看作运维人员的职责，而不是安全测试团队的工作

• 7.7.3. 存储容量是另一个我们希望获得预先告警的重要数据

• 7.7.3.1. 针对存储容量，我们可以把告警值设置为限制值的99%，而不是某个任意的阈值

• 7.7.3.2. 一种更加有用的计算方法是计算一个时间序列（也就是存储容量随时间变化的一组测量值）​，并且推断到达限制值所需的时间

• 7.7.4. 时间限制也绝对不能忽视

• 7.7.4.1. 数字证书的过期时间很容易被人们忽视

7.8. 分布式拒绝服务攻击

• 7.8.1. 拒绝服务(Denial of Service，DoS)攻击是一种单独的行为，旨在给可用性造成负面影响

• 7.8.2. 分布式拒绝服务(Distributed Denial of Service，DDoS)攻击则通过多项协同行为的累积效应来完成攻击