上一次我们讲过利用源代码安全漏洞的常见几种姿势，这篇文章接着介绍相应的防御技术。

修改漏洞通常会比较简单，但如何通过安全编程来避免某些类型的漏洞的发生则会比较麻烦。实

际上，防御原理比较好概括，主要就是一个词“控制”：控制输入，控制过程，控制输出。”控字

做得好，防御也能随之建立。

 

 

 

 

在此输入是相对的，取决于您所关注的系统，取决于“安全防线”(又称“安全边界”)的位置。防御

系统在内部被认为是可信的，在外部则被认为是独立的；防御系统自然是不可信的，在外部被

认为是外人。所以我们要保护程序的时候，通常会有哪些类型的外部输入呢，下面给出几种常

见的外部输入。对外界输入，是否存在预期的逻辑限制，输入的完整集合是什么，合理的输入

区间在哪里，都需要认真考虑。举例来说，对于一个函数接口，如果需要处理外部输入的数据

，则通常要考虑输入数据的长度、数据的数值范围以及数据的字符集(如果将其作为字符处理)

范围等因素。

 

 

若还需要对输入数据进行进一步处理(例如，URL解码后仍然存在危险的字符结构注入)，或与

预置数据拼接(例如，使用'../'拼接跨越父目录的预置数据)，则需要进行再次确认，以确保经过

处理的数据在被送到函数的参数之前是预期的合格参数。

 

另一点，前面已经说过，“安全防线”的位置并不是固定的，如果我们确认了一台机器有入侵，

那么从它来的输入也会变成不可信的输入，其他机器也需要与之“划清界限”，对其输入再进行

检查。目前流行的“无信任安全性”假设任何输入都是不安全的，并且在收到输入之前必须进行

验证检查。对输入进行检查是需要成本的，完全的“零信任”是一个挑战，可以选择把精力集中

在主要方面的矛盾上。

 

防止数据变码保护解析器。前面已经提到，解析器经常成为安全攻击的重灾区，其自身就是

为了提高固定格式或协议文件的解析效率，而越复杂的解析器，其安全性缺陷就越多。为保

证解析器的安全性，需要了解我们使用了什么解析器，是否是安全版本的，使用什么解析器

来处理数据等等。一些解析器需要根据说明书进行合理配置，而不能一使用就直接使用。安

全性配置解析器并不意味着一定要限制解析器的功能，而是避免让开发者无法预期的功能被

打开。如果开发人员不知道要处理的数据协议本身，那么攻击者很可能会钻了他们的空子，

例如xml协议的使用，开发人员可能不知道xml实体扩展的功能，而xml解析器如果打开实体

扩展解析功能，则很可能导致xml解析接收到过量的实体扩展解析，损失计算资源，并导致

拒绝服务。