网站源代码的安全防护之道 输入参数效验



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

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

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

做得好,防御也能随之建立。
 
 
 
 
在此输入是相对的,取决于您所关注的系统,取决于“安全防线”(又称“安全边界”)的位置。防御

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

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

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

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

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

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

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

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


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

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

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

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

在主要方面的矛盾上。

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

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

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

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

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

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

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

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

拒绝服务。
分享: