在跨编程语言边界调用程序时一定要特别小心，比如从解释语言调用本机代码（native code），因为在语言边界之间存在一个不期望的交互。确保你没有打破你所调用语言本身的规范。比如，尽管Java可能没有缓冲区溢出的风险，但是，在Java程序中调用本机代码并属于一个很大的参数，可能会导致溢出。

　　直接把你输入的类型转换成期望的数据类型，比如用转换函数把字符串转换成数字。在转换成期望的类型之后，确保输入的数值在允许的范围之内，并且保证多字段的一致性。

　　应该首先把输入进行解码或者规范化，转换成系统内部的表示形式，然后再进行验证（CWE-180, CWE-181）。确保你的应用系统不会无意中把相同的输入解码两次（CWE-174）。因为如果在检查之后再进行解码的话，通过引入危险的输入可以逃避白名单机制的检查。建议使用类似OWASP ESAPI 规范化控制的软件库。

　　可以考虑对输入数据反复地执行规范化操作，直到输入不再变化为止。这是为了防止两次解码（double-decoding）和类似的场景，但是这可能会修改输入数据，把允许的数据修改成正确编码的危险内容。
　　在两个组件交换信息数据时，确保两个组件都使用了相同的字符编码。确保在每个接口上都使用了正确的编码方式，只要是协议允许，一定要显式地设置编码，而不是使用缺省的方法。

　　3.测试
　　使用一些专门设计的自动静态分析工具分析这种漏洞。现代许多技术用数据流分析的方法，可以把误警率降到最低；但是期望百分之百的准确率是不太实际的。
　　使用动态分析的工具和技术，用大的测试集穷尽各种输入，包括Fuzz 测试、鲁棒性测试、故障注入。这些软件操作可能很慢，但不会使系统变得不稳定、崩溃，或者产生错误的结果。

　　讨论
　　计算机都有一种奇怪的习惯：它按照你说的去做，而不是按照你想的做。输出编码和输入验证错误往往相伴，构成了最近流行的注入式攻击的根源。攻击者可以修改你打算发送给其他组件的命令，可能导致应用彻底被攻破，或者，还可以暴露攻击者无法直接攻击的组件相关信息。这将会使得“按我的意思做”变为“按攻击者说的做”。当你的程序给其他组件产生的信息是结构化的查询或请求时，你需要把控制信息（或元信息）和实际数据分开。这一点很容易被忘记，因为许多范例将数据和命令捆绑在同一数据流中，只用少数几个特殊字符作为分隔。一个例子是Web 2.0和其他框架，它们都模糊了数据和控制结构的界限。这一点使它们更容易受到攻击。

　　预防和减缓

　　1.体系结构与设计
　　如果可能，尽可能使用存储过程或其他结构化机制，特别使用大量键盘输入时。这种过程一般可以自动转义或编码特殊字符。

　　理解使用的数据的上下文和可能的编码方式，尤其是在组件交互的边界。理解数据在不同的组件间是如何传输的。研究所有预期的通讯协议和数据表示，以确定所需要的编码策略。要特别小心的一些环境，如WWW。即使在一个文件中（如脚本部分，URIs ，CSS，属性，或HTML体），其中的编码根据位置也是各不相同。

　　在每个接口使用正确的编码。利用预期编码的或自动处理的库，如ESAPI Encoding API。或者，利用内置（bulit-in）的函数，但是应该是在考虑使用包封装的情况下，以免内置的功能发现存在漏洞。

　　在某些情况下，当输出编码不能提供一个完整的解决方案时，输入验证也是一个重要的策略。例如，你可能会提供统一的输出，而是用你输出的多个用户使用不同的编码来表示。你可能需要允许用户提供的输入包含控制信息，如支持受限的HTML标记格式的Wiki或公告。如果不得不在数据中包含控制信息，一定要使用严格的白名单以限制这些控制信息。确认所产生的语法结构是你所想要的；对于剩下的输入，把它们当作数据，使用正常的编码方法。

　　使用输入验证作为纵深防御措施，以减少输出编码错误的可能性。

　　2.需求
　　明确指定组件间相互通信所使用的编码方式。

　　3.实现
　　当组件间进行数据交换时，确保组件使用的是相同的字符编码方法。如果通信协议允许，一定要显式地设置编码，而不是使用缺省的编码方式。
　　使用自动静态和动态分析工具来定位这种类型的漏洞。许多现代技术利用数据流分析，以尽量减少误报。然而这不是一个完美的解决方案，因为100%的准确性和覆盖面是不切实际的。
　　（译者单位为清华大学信息网络工程研究中心）

　　来源：《中国教育网络》2009年6月刊