Java的安全狀況越來越糟

在一年前的JavaOne大會上，Fortify Software創始人兼首席科學家Brian Chess作了一個標題為“Java的12個技術陷阱及其應對方法”的演講。一年過去了，我們為這些內在的脆弱性作了什麼呢?

這些弱點包括：XSS(跨站點的腳本)、SQL注射和允許引入C或者C++代碼的本地方法――同它的BUG一起。

如今，它可能會變得更糟，Chess說，他有證據證明這一點。

Fortify――它的市場在於開源分析技術，已經涉及到了針對大型數據庫的通用Java程序錯誤和弱點――不但來源於客戶，而且來源於Java Open RevIEw項目。

在這個項目中，Fortify使用FindBugs――一個靜態分析工具，能夠在Java代碼中尋找Bugs，能夠審查開源項目代碼，如：apache、Azureus和Tomcat。它能夠在線發布它發現的問題，然後把這些問題分享給那些特定代碼脆弱性的維護人員。

在這個項目中，Fortify所發現的開源系統代碼缺陷密度是“天文數字”級別的。Chess指出，Fortify在去年的一個名為“Net Trust”的項目中所發現了大量錯誤――大約是每1000行代碼有12215個錯誤。

“這樣的錯誤量顯然是是過大了。”Chess說。

更具有諷刺意義的是，Net Trust居然是Google用來為單點登陸和認證所建立的一個項目。“他們就像還是個沒有做好作業的學生。” Chess說。

Net Trust 只是能夠證明Java安全陷阱的許多例證之一，雖然大家都對此有所了解，但是隨著它應用的增長，還是會不斷給那些使用它的程序員帶來麻煩。

當Java專家William Pugh意識到Java安全陷阱變得更糟的時候，他完全同意Chess的意見。“Xss變成了一個大問題。”他說。雖然像Fortify這樣的工具集可以尋找XSS問題，但是它不能驅除你代碼中所有的XSS漏洞。如果不包括所有的Web攻擊，據統計，目前XSS漏洞正在變成最大的漏洞。

Pugh是馬裡蘭大學的計算機科教授，同時還是FingBug工具的作者，這個工具被用在Java開放檢查項目中。

舉一個Sun說明書中的XSS漏洞的例子：

try { firstname = request.getParameter("firstname"); } catch (Exception e) {e.printStackTrace(); }

userName = firstname;

...

pw.print(" Thanks for your feedback, " + userName + "!");

這段代碼允許黑客在應用程序中注入代碼，它將在受害者的浏覽器中運行。Chess說。

“這段代碼期望用戶輸入像Bob這樣的名字” Chess在email中寫道。 “但是黑客能建立一個看起來像這樣的數據：

and then the victim's browser would execute a function named sendDataToMotherShip()." ”

安全的服務器端代碼會判斷它只包含特定的字符集並且不包含可執行腳本。

為什麼XSS會得到如此抨擊?原因同10年前緩沖溢出的道理是一樣的，這兩個漏洞對黑客來說是十分重要的，因為這個漏洞允許黑客在系統中注入代碼從而完全控制計算機。

過去的棘手問題是緩存溢出，目前是XSS。

“這兩個漏洞的不同是，緩存溢出方法不太容易掌握，黑客需要對系統架構和本機上發生的各種情況十分精通。而XSS漏洞十分容易被利用――只要在當地的書店買本關於Java的書你就可以使用XSS了。”

如果這些都來源於Sun，我們還能信任誰呢?事實是：查找最普遍的Java安全漏洞陷阱的責任應該完全由開發人員承擔。

這樣情況就能夠好轉嗎?也許會，但是也很困難，Chess說。一個解決方案是限制浏覽器執行XSS。這就需要更改Web標准同時使得浏覽器變得更大。

即使某些人說服了廠商來支持這個計劃，它也需要把新的浏覽器推廣給數百萬的用戶。“我們轉換到這上面的時間最少也得幾年，基礎架構和語言的變化需要很長的時間才能完成。”Chess說。

“如果開發人員重視它的話，漏洞的數量會顯著下降”Chess說。

或許更有效的方法是同框架所有者和軟件制造商來交流，從而使得Web成為安全的程序執行場所，Chess說。當然，這也不是能很快的解決。