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

1. 低级编码缺陷

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

• 1.1.1. 越接近硬件级别越能获得最大服从的诱惑仍然很大
  
• 1.1.2. 更接近硬件级别的编程是非常强大的，但其代价是工作量和脆弱性的增加
  

1.2. 当数据超出了固定的巨细，或者超出了分配的内存缓冲区容量时，就会出现这类问题
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. 安全算术

• 2.5.1. 整数溢出比浮点下溢更轻易出现问题，因为它会带来差别很大的结果，但我们也不能认为浮点下溢很安全而忽略它
  
• 2.5.2. 使用范例转换时要谨慎，因为它有可能像执行盘算一样导致截断或改变结果
  
• 2.5.3. 任何情况下，尽可能限制盘算的输入，确保所有可能出现的值都是可以精确表示的
  
• 2.5.4. 使用较大的固定的整数来避免可能出现的溢出；在将结果转换为较小的整数之前，检查结果是否在范围内
  
• 2.5.5. 要记住，纵然最闭幕果始终在范围内，盘算的中间值也有可能会溢出，从而导致问题
  
• 2.5.6. 在检查安全敏感代码及其四周的算术精确性时要格外谨慎
  

3. 内存访问漏洞

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. 任何直接在内存中修改数据结构的代码都可能会导致与缓冲区溢出类似的问题
  

3.4. 要想低落这种内存不测泄露的风险并不难，但我们必须覆盖有可能发生泄露的数据结构中的所有字节

• 3.4.1. 不要试图准确猜测编译器会怎样分配字段偏移量，因为这可能会随着时间平静台的变化而变化
  
• 3.4.2. 避免这些问题最简单的方法是在分配后将缓冲区清零，除非我们可以确保它们被完全覆盖，或者知道它们不会被泄露到信托边界之外
  
• 3.4.3. 纵然你的代码自己并不使用敏感数据，但通过这种内存泄露路径也可能在进程中的任何位置将其他数据泄露出去
  

4. Heartbleed漏洞

4.1. Heartbleed是研究低级语言脆弱性的一个很好的对象

• 4.1.1. 小错误会引发巨大的影响
  
• 4.1.2. 假如恰好发生在内存中错误的位置上，则缓冲区溢出可能会暴露具有高价值的秘密
  
• 4.1.3. 设计（协议规范）中已经猜测到了这个错误，指出代码应该忽略字节长度不精确的心跳哀求，但在没有明确测试的情况下，没有人注意到这个漏洞
  

4.2. Heartbleed是TLS Heartbeat扩展中OpenSSL实践的一个缺陷，于2012年在RFC 6520中一起提出
4.3. Heartbleed漏洞不但作为“第一个带有徽标的bug”而成为新闻，还在部署了盛行的OpenSSL TLS库的服务器中展现了一个微小的漏洞
4.4. 所谓心跳，就是往返交互心跳哀求，其有用载荷是16至16384(214)字节之间的任意数据，与之对应的心跳响应中也携带了雷同的载荷
4.5. 格式错误的心跳哀求中会发生严重缺陷，这些哀求提供了一个小的有用载荷，却声称是一个较大的载荷
4.6. 最终会被泄露的数据取决于内存分配的弱点，攻击者可以重复利用这个漏洞来访问服务器内存，并最终得到各种敏感数据
4.7. 对“会说谎”的心跳哀求做出猜测

• 4.7.1. 这些哀求会要求比它们所提供的载荷多得多的载荷
  

4.8. 在格式正常的哀求中，一切都可以完善地运行，只有格式错误的哀求才会让本无恶意的代码出现问题
4.9. 心跳响应中泄露的服务器内存并不会对服务器造成直接伤害：只有对被泄露的大量数据举行细致分析后，人们才能看出丧失程度

• 4.9.1. 它不太可能发生，而且返回比接收到的载荷多得多的载荷数据，乍看起来似乎是无害的
  

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