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 ）
?EXADEL?Studio的3.0發布了，我個人認為這是eclipse平臺的輕量IDE中比較好的了。M7的Nitrox不錯，但是很貴哦。而且............加密做的不錯，很難找到CRACK的。
從2.5版本開始，他就分為了標準版和Pro版，前者是免費的，后者收費。3.0Pro版本同樣為＄99，可以說非常便宜了。而Nitrox同時支持JSF和Struts的版本居然是$699。
關于其新特征，可以查看：Pro版：http://www.exadel.com/products_exadelstudiopro.htm? 標準版：http://www.exadel.com/products_exadelstudio.htm。
有幾個特征值得一提：
導航圖：
Tree視圖編輯器：
特別是支持表達式的幫助：
這點非常不錯，看好！
?
對Struts的支持，除了常規的導航流圖，配置編輯，可視化驗證，之類，還直支持TILES的可視化，這點有很大進步，但是和Nitrox比還是有些差距，后者能夠支持JSP編輯器中的TILES WYSWYG效果。
還有個有趣的特征是Struts配置文件的Debug, 直接在圖形上就可以設置斷點。
?
另外的改進就是支持JSP 的WYSWYG編輯。
?
PRO版與標準版的支持在于對Hibernate 和Spring 的支持，以及JSP的可視化編輯。其中Hibernate 支持可視化MAP編輯。Spring 則是有Spring IDE提供，無新意。
?
哈哈，我決定在我后面的Spring 和struts的書中，以它作為演示工具。
Borland 最近宣布了將要升級JBuilder IDE的相關信息。基于Eclipse平臺，Borland JBuilder 2006 將提供端對端的開發人員協作功能，以提高對標準的支持和生產力增強。但是這恐怕不是令大家關注的地方，大家感興趣的還是Eclipse平臺。
BEA公司也意圖將其IDE Workshop的未來版本轉向Eclipse平臺，在加上IBM Websphere Studio(現在叫Rational Software Architect和Rational Application Developer)，似乎eclipse的勢力在妄圖一統天下。著名的Java IDE只剩下Oracle 的JDeveloper和IDEA了。但是實際上Java IDE 卻是陰云密布，不容樂觀。
基于Eclipse的 JBuilder，代號為Peloton。大約會在明年中期發布。它將會包含 JBuilder的可用性和協作特征，加上應用生命周期管理。
近兩年Eclipse社區不斷發展壯大，以致在Eclipse3發布的時候，瘋狂下載造成服務器幾乎癱瘓。因此，在Java IDE市場上， Eclipse估計占到20-30%的市場分額。.
因此，這種增長令商業的專用IDE廠商非常不安，前不久 Oracle終于宣布其JDeveloper向開發人員免費，僅對支持收費。就是一種無可奈何的反應。它們認為，Eclipse （包括商業和開源平臺）的開發工具已經占據了50%的半壁江山，Oracle在J2EE方面一直不太理想，還不如讓JDeveloper免費，也好做為Oracle Java的形象大使，賺回些關注。
但是實際上，Eclipse提供的是一個骨架平臺，當然Eclipse本身也提供一些開源的Plugins,也有其他一些廠商在提供商業的插件支持，比如MyEclipse, Lomboz, Exadel等等。還有其它一些開源的專用插件，層出不窮。
因此，Eclipse-Based IDE實際上成為兩種派系：OS和商業的。就商業來說，IBM是最嬉笑顏開的，Eclipse本身就是它鼎力支持的，從WSAD到RAD和RSA，IBM成功地將Rational 品牌產品和Websphere進行了整合，Rational體系如今專注軟件開發生產和測試，而RAD和RSA則提供了業界最高標準的，包含基本IDE支持，標準支持，協作，軟件生命周期（甚至集成了RUP），MDA等功能為一體的開發平臺。
當然，基于Eclipse的商業IDE和開源IDE會否共存？答案當然是肯定的。最簡單的原因就是，Java雖然是標準，但是廠商自有獨門功夫，因此，IDE商業平臺自然帶有一定的專有性。如果是大型的企業應用，需要優化等等，則非商業IDE莫屬。
另外一個就是Java本身的未來，輕量架構和方法的發展，比如如火如荼的IoC，MetaFramework等等，則又大大促進了開源IDE的發展。
因此，一定時期內，這兩種肯定會共存。IDE的較量，背后還是AS和基礎平臺的較量。
Borland的未來核心是構建一個 Borland Core Software Delivery Platform (SDP), 也都基于Eclipse。JB只是其中一個組件。
SUN的IDE則有些尷尬，NetBeans 一直沒什么人感興趣。現在，SUN的另一個IDE， Java Creator則讓人摸不清到底是何意思。Creator的意圖是想借JSF的組件架構，構造一個輕量的開發環境，并且還苦心構造了一個輕量的后臺的數據支持。這明顯和SUN的J2EE架構矛盾，真是搞不懂。不過，Creator對快速開發（RAD）倒是頗有點像VS.NET的那么點樣子，可惜是SUN在經營，恐怕也不會對MS造成什么威脅。
另外一個IDEA則也有一大幫擁甭。IDEA有些地方卻有獨到之處。其它倒是不說，不過IDEA的下一版（恐怕不妥）fabrique倒是非常有意思，它在常規的IDE之上構建了一個專門的應用框架，并且在IDE（應該說是RAD開發平臺）提供了業務對象框架，Web應用框架，以及通用的服務（稱為Active Libraries）（Forum,Email,...）的支持。非常具有特色。我個人十分欣賞。這點恐怕只是Oracle ADF可以與之一比。
呵呵，先說這么多。
有一個免費的Java在線教程，看樣子是一個SUN的專家掌控的，名字 sang.shin ，中國人？韓國人？
其中有很多非常好的材料，有詳細的課程表，還包括PPT材料，講課錄音，實驗材料等等。我覺得非常有價值。
你還可以注冊到一個相關的yahoo群組參與到課程中。初學者不妨試試。雖然是英文的，不過也不要怕，還可以學習英文，豈不更好？
地址是：http://www.javapassion.com
Roger Kitain （ JavaServer Faces co-specification lead ）在其blog宣布了開源的 "Open JavaServer Faces" ，并且在基于OSI-approved CDDL許可之下。
原來SUN JSF RI 是基于 Sun Java Research License [Sun, JRL]對”開放開發”發布。基本上，這意味著你可以免費獲得它的代碼和源代碼，并且你可以修改和分發它，只要你不是用作商業目的, 或者用作內部非生產之用。如果你修改了二進制代碼和源代碼用作商業用途或者內部生產之用，你必須使用商業許可證并且通過 JSF 技術兼容包 (TCK)的測試。你也可以提交補丁給 JSF RI 代碼基。
并且在Java.net社區也launch了一個專門的項目Javaserver Faces，地址是：https://javaserverfaces.dev.java.net/
Ed Burns 也在其BLog中公布了 JavaServer Faces 1.2 和 JavaServer Pages 2.1 Proposed Final Draft Specification的一些細節：
將JSP，JSTL和Faces EL統一起來，并且類似于 OGNL 的使用方式。這將極度方便表現層之間的整合，和MVC之間的簡化。
- 針對JSP/JSF應用的新的Tree 創建和內容交織模型（Content Interweaving Model）。
雖然可以不用JSP而使用Faces，但是因為技術、技能和各種生產開發環境的支持，JSP/JSF應用確實最現實和富有效率的。當然，這里還有一些集成問題，比如OnJava中的 Hans Bergsten 的這篇文章所述。 所以規范中將修改針對JSP的Faces ViewHandler 的實現，以及所有Faces組件標簽所用的JSP定制標簽句柄的基類的實現來解決這些問題。
有一個問題是JSTL不支持PostBack，所以使用 JSTL的 <c:forEach> 包含Faces 輸入組件會出現問題。所以需要在JSTL中引入類似于PostBack的新概念，將在下一個版本中發布，并且更好地支持所有Faces組件。
- Back Button 問題和多 Frame 或Multi Window Faces 應用。
因為在Multi Frame 或者 Multi Window 應用中使用Facesa在State Management API方面會出問題，即瀏覽器的Back按鈕會造成狀態錯誤。這個問題已經解決。
- 將消息與頁面中的某個特定的組件相關聯。
- AJAX support
- 暴露一個application 層面的 ResourceBundle 給 EL.
添加了一個新的 <resource-bundle>到 faces-config 中，列出應該暴露給使用ELResolver 鏈的EL的資源束。這樣可以優化性能。
原文見：http://weblogs.java.net/blog/edburns/archive/2005/08/javaserver_face_3.html