读软件开发安全之道：概念、设计与实施14低级编码缺陷

本文主要是介绍读软件开发安全之道：概念、设计与实施14低级编码缺陷，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. 低级编码缺陷

1.1. 在更靠近机器级别的代码中常会出现这类缺陷

1.2. 当数据超出了固定的大小，或者超出了分配的内存缓冲区容量时，就会出现这类问题

2.1. 不同编程语言在定义其算术运算时有所不同，这种不同体现在数学上或处理器的相应指令上

2.2. 浮点数运算的范围比整数运算的范围更大，但其有限的精度也会导致意外的结果

2.3. 定宽整数漏洞

2.3.1. 定宽整数是包括Java和C/C++在内的许多语言中最基本的构建块，如果计算超出了定宽整数的限制范围，你将得到错误的结果
2.3.2. 安全性的底线在于我们要了解语言规范，并且避免出现有可能未定义的计算
- 2.3.2.1. 不要耍小聪明，试图找到某种方法来检测未定义的结果，因为在不同的硬件或新版本的编译器上，你的代码可能会停止工作
2.3.3. 错误的计算结果会让代码出现各种问题，并且这些问题通常会像雪球一样越滚越大，形成一连串的功能障碍，并最终导致系统崩溃或蓝屏
2.3.4. 程序员最好能在代码执行任何有可能超出范围的计算之前解决这些问题，并且保证所有数字都在范围之内
- 2.3.4.1. 解决问题最简单的方法是使用比有可能出现的最大值还要大的整数空间，然后检查并确保无效值永远不会悄悄潜入
2.3.5. 将计算分解，以便在乘法和除法中使用64位计算，并向下转换为32位结果
2.3.6. 最干净的解决方案是将所有变量都升级为64位，代价是降低一点效率
2.3.7. 这就是使用定宽整数进行计算所涉及的权衡

2.4. 浮点精度漏洞

2.4.1. 浮点数在很多方面都比定宽整数更强健，并且限制更少
2.4.2. 当超出这个极大的范围时，你会得到一个有符号的无穷大或NaN（Not a Number，不是数字）反馈，而不是像定宽整数那样对值进行截断
2.4.3. 1/10在二进制中是一个无限循环小数（即0.00011001100…以1100无限循环），所以最低位会出现错误
- 2.4.3.1. 这些错误都是在低位引入的，因此称为下溢(underflow)
2.4.4. 错误不会带来重大影响，但是当需要全精度时，或者当计算中纳入不同数量级的值时，优秀的编码人员会格外谨慎
2.4.5. 当无法精确表示结果值时，低位少量的错误也会一直累积
- 2.4.5.1. 尽可能永远不要使用浮点值来比较值是否相等（或不相等），因为这种操作无法容忍计算值的微小差异
2.4.6. 当你必须使用高精度时，请考虑使用超高精度浮点表示法（IEEE 754中定义了128位和256位格式）
- 2.4.6.1. 任意精度的十进制或有理数表示都可能是最佳选择

2.5. 安全算术

3.1. 大多数编程语言都提供了完全托管的内存分配，并设置适当的边界来限制其访问

3.2. 指针允许通过地址直接访问内存，这可能是C语言中最强大的功能

3.3. 缓冲区溢出

3.3.1. 当代码访问的内存位置在预期的目标缓冲区之外时，就会发生缓冲区溢出（buffer overflow或buffer overrun）
3.3.2. 缓冲区(buffer)是表示内存中任意区域的通用术语：数据结构、字符串、数组、对象或任何类型的变量
3.3.3. 访问(access)是读取内存或写入内存的统称
3.3.4. 缓冲区溢出指的是在预期内存区域之外，对内存进行读取或写入
3.3.5. 缓冲区溢出并不是堆内存独有的，而是任何类型的变量都有可能发生的，包括静态分配和栈上的局部变量
3.3.6. 缓冲区溢出bug会意外地读取内存，这可能会将信息泄露给攻击者，或者导致代码行为异常
3.3.7. 不要低估执行显式的内存分配、范围内访问，以及精准释放未使用的内存的难度和重要性
- 3.3.7.1. 使用简单模式来分配、使用和释放是最好的，其中包括异常处理，以确保不会跳过释放操作
- 3.3.7.2. 当一个组件给其他代码的引用分配内存时，一定要定义随后内存释放的责任，将其释放到接口的一侧或另一侧
3.3.8. 即使是在包含完全范围检查、垃圾收集等功能的语言中，你仍会遇到麻烦
- 3.3.8.1. 任何直接在内存中修改数据结构的代码都可能会导致与缓冲区溢出类似的问题