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 應用僅使用客戶端校驗來驗證輸入?？蛻舳诵ｒ灆C制是非常容易繞過的，這樣就使得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 ）