读软件开发安全之道：概念、设计与实行15安全测试

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)攻击则通过多项协偕行为的累积效应来完成攻击
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。