TOP 10 Web应用脆弱性之一：未经验证的输入
描述
Web 应用使用HTTP 请求(也许还有文件，也是一种特殊请求) 来进行输入，并决定如何进行响应。攻击者可以篡改HTTP 请求的任何部分，包括url，查询字符串（querystring）, headers, cookies, 表单字段（包括隐藏字段），试图绕过服务器的安全机制。常见的通用输入篡改攻击包括：
o 强迫浏览（forced browsing）；
o 命令注入（command insertion）；
o 交叉站点脚本（cross site scripting）；
o 缓冲区溢出（buffer overflows）；
o 格式字符串攻击（format string attacks）；
o SQL注入（SQL injection）；
o 有毒饼干（cookie poisoning）；
o 隐藏字段操作（hidden field manipulation），等等。
某些站点试图通过过滤恶意输入来保护自己。但问题是编码信息的方式无穷无尽。这些编码方式看起来并不是加密的，所以似乎也用不着解码。但是，开发人员仍然经常忘记将所有的参数在使用之前解码为最简单的形式。参数应该在其被校验之前转换为最简单的形式，否则，恶意输入就可能掩饰自己从而流过过滤器。简化这些编码的过程称为是“规格化（canonicalization）”。因为几乎所有的HTTP 输入都可以编码为多种格式，这种技术便可以打乱各种旨在利用和攻击上述弱点的攻击行为。这使得过滤非常困难。
有非常之多的web 应用仅使用客户端校验来验证输入。客户端校验机制是非常容易绕过的，这样就使得Web应用几乎对恶意参数的攻击毫无保护。攻击者可以使用攻击甚至telnet来产生他们自己的HTTP 请求。他们才不关心开发人员预定想要在客户端发生的时候事情呢。注意，客户端校验仅仅在提高性能和可用性方面有益，但是它毫无安全可言。因此，对于恶意参数攻击，服务器端校验是必须的。
这种攻击的数量在不断上升，因为有大量的支持参数的“模糊化”（“fuzzing”）、腐朽（corruption）、以及野蛮强制增长的工具出现。不应该低估了这些使用非校验输入进行攻击的影响。实际上如果开发人员能够在使用参数之前对其进行验证，就可抵挡大部分的攻击。因此，最好使用一个中心化的、强大的验证机制来对所有HTTP 请求的输入都进行验证，这样利用此弱点进行攻击的数量就会大减。
环境影响
所有web servers, application servers, 以及应用环境都容易受到这种参数篡改的攻击。
如何决定你的应用是否脆弱
一个Web应用所用的未经验证的HTTP请求的任何和部分都称为是“脏” 参数。找出脏参数的最简单的方式是进行最详细的代码评审，找出所有从HTTP请求提取信息的方法调用。比如，在J2EE应用中，这些包括HttpServletRequest 类（以及其子类）中的方法。然后你就可以循着代码查看参数变量是在哪里使用的。如果变量在使用之前未作验证，这可能就是一个潜在的问题。在Perl中，你因该考虑使用 “taint” (-T) 选项。
你也可以通过一些工具来找出脏参数，比如OWASP的 WebScarab。它们可以查看和评审通过HTTP/HTTPS的所有数据，并进行分析。
如何保护
保护很简单，那就是确保任何参数在被使用之前都进行了验证。最好的办法是使用一个中心化的组件库，比如Java中的Jarkarta Commons Validator.每个参数都演进行严格检查。涉及到过滤脏数据的“负面”方法或者依赖于签名的方法都不可能很有效率，并且难以维护。
参数应该进行“正向”规格的检查，正向规格（ “positive” specification ）的定义可包括：
- 数据类型(string, integer, real, 等)
- 允许的字符集
- 最大最小长度
- 是否允许null
- 是否必需
- 是否允许重复
- 数值范围
- 特定的法定值 (枚举)
- 特定模式(正则表达式)
* 本系列整理自 OWASP（Opensource Web Applicaiton Security Project ）