一年前的Javaone上，Fortify 軟件公司的創始人 和首席科學家Brian Chess做了一個題為“12個Java技術安全陷阱和如何避免它們”的演講。

一年后，我們在解決那些固有的弱點，包括XSS，跨平臺腳步，SQL注入，以及允許導入c或者c++代碼的本地方法上——還有伴隨它們的BUG上，有何長進呢?毫無進展——除非你認為后退也是一種進展的話。

情況變得更糟了，Chess在eweek的采訪中說，“我有證據證明這一點。”

Fortify作為原代碼分析技術的銷售商，它有個常見Java編程錯誤和弱點的大數據庫，不僅是從它的客戶那里收集來的，還有Java Open Review項目運行一年以來的收集到的。

在那個項目中，Fortify使用了findBUGs，這是一個靜態分析工具，可以尋找Java代碼中的BUG，查看開源項目中的代碼，例如Apache, Azureus 和Tomcat。Fortify對每個受到懷疑的代碼集進行分析，在線發布它找到的問題，然后將其與項目維護者共享弱點的細節。

那么Fortify從運行的項目中找到的是否代表了開源代碼的錯誤密度是“龐大的”，Chess說，他特別指出了去年Fortify檢查的一個項目：Net Trust，每1000行代碼中大約有12.215個錯誤。

“這對于名字里面帶著一個‘可靠’字眼的項目來說是個巨大的數字，”Chess說。

足夠諷刺的是，Net Trust 是Google的一個項目，用來創建一個針對單點登錄和認證機制的安全機制。“但是他們是學生做的，所以代碼不是很好，”Chess說。

Net Trust是眾多顯示Java安全陷阱的例子中的一個，盡管這件事情公布于眾已經有一段時間了，但是它還是在繼續誘惑更多的程序員將全部時間投入到這種語言的成長中來。

Java 專家 William Pugh同意Chess關于Java安全陷阱變得更糟的看法。“XSS正在逐漸成為一個非常大的問題，”他在Eweek的采訪中說。“類似Fortify公司的工具集的工具可以尋找XSS的問題，但是要在你的代碼中清除XSS(漏洞)是不容易的。我們看到的統計數字表明它正在成為Java應用程序中的最大的安全漏洞，如果不算所有的網絡攻擊的話，”他說。

Pugh是位于College Park的馬里蘭大學計算機科學系的教授，也是Fortify公司用在Java Open Review項目中的FindBUG的作者。

除了XSS之外，Pugh說人們在談論Java安全的時候最經常說的另外2個問題通常就是不被信任的惡意代碼和SQL注入。“在你運行Applet的時候……(問題是，)那些Applet能做什么?它們可以用任何方式修改你正在運行的程序的行為嗎?”

“人們在服務器上運行原始材料，他們不運行不受信任的代碼，”他說。“但是另一種受到更大關注的安全攻擊類型是SQL注入……那些一直都是大問題。”

令問題更嚴重的是安全代碼的教學在最好的情況下，也是良莠不齊的。

要解釋安全編碼指導的缺乏，Chess指出了他最近的發現，就是Java巨人，Sun公司，特別是Sun Servlet編程指導(Sun公司的將Java連接到網絡上的最簡單方法)中包含了跨網站腳本攻擊的內容。

一個關于XSS弱點的例子就是來自Sun的指導中的這些代碼：

try { firstname = request.getparameter("firstname"); } catch (exception
e) { e.printstacktrace(); }
username = firstname;
...
pw.print("
thanks for your feedback, " + username + "!
");

這個代碼可以讓攻擊者向受害人瀏覽器執行的應用程序中注入代碼，Chess說。

“這些代碼期望擁護可以輸入類似bob的名字，”Chess在一封電子郵件中寫道。“但是攻擊者可以輸入一些內容，讓數據看起來這個樣子： ，然后受害人的瀏覽器就開始執行一個名為senddatatomothership()的函數。”

服務器端代碼的安全版本，Chess說，應該對輸入進行檢查，確保它只包含所期望的字符，沒有可執行的腳步。

“SQL注入問題仍然穩坐Java安全陷阱列表的頭把交椅，”他說。“開發人員們信任他們不應該信任的輸入。”

如果這些問題來自Sun，那么我們還能信任誰?“你將會看到，指導手冊從未提到過安全措施，”Chess說。“記住這一點，那么指導手冊中包含跨網站腳本攻擊漏洞就一點也不令人驚奇了。”

問題是Java——以及其他網絡編程語言——都把XSS列為“確實容易犯的錯誤，”他說。“想想寫出來的最簡單的網頁：當你構建Java網絡語言程序的時候最先做的事情。你輸入你的名字，然后它輸出你好，brian。Java提供的實現‘你好，世界’功能的函數就允許XSS。”

構建到Java語言的網絡框架也容易在Java代碼中寫入XSS漏洞，他說。

“比這更糟的是，當我們開始教人們如何編寫Java代碼的時候，我們給他們的是帶有XSS漏洞的代碼范例，”他說。

正如它現在承擔的，注意最常見的Java安全陷阱的責任完全在開發人員身上。

那么這種情況是否可以得到矯正?可以，但是沒有那么容易，Chess說。朝著解決方案前進的一個步驟就是修改瀏覽器，讓XSS更堅固。所要做的就是改變網絡標準，并且讓所有的瀏覽器巨人——微軟，Mozilla，和蘋果——簽署協議。

即使是有人去和他們說要進行這樣的計劃，仍然需要向數百萬的用戶推出一個新的瀏覽器“我們能夠改變得最快的，也需要數年時間，”Chess說。“改變框架或者語言的基礎結構，確實需要很長一段時間。”

XSS理應受到如此抨擊的原因就是，這種情況越來越類似于10年的緩沖器溢出的情況了。這兩個安全漏洞對于攻擊者來說都是如此強大，Chess說，因為它可以為攻擊者提供向系統中注入代碼并且提供徹底的接管。

緩沖器溢出之所以成為這樣的一個問題的原因是C和C++框架讓它們很容易創建，他說。原來發生在緩沖器溢出，現在是發生在XSS身上。

盡管它們之間的區別在于緩沖器溢出是很難被探測的，Chess說，它需要攻擊者相當了解系統的體系結構，以及在這臺機器上的情況。“XSS漏洞則很容易探測，”他說。“只要到你當地的書店去，買一本有關Javascript的書，你就可以在XSS上開始了。”

盡管情況并不好，但是也不是你垂頭喪氣的時候。Fortify已經看到了開源項目中的開發人員毫無疑問正在努力阻止XSS。這樣的項目可能還會有一些XSS漏洞，但是相比較那些數字為50的，無能的開發人員所進行的類似規模的項目，情況已經好很多。

“我們看到，當開發人員將注意力放在上面的時候，他們就可以將它們的數字降低，”Chess說。

然而，Chess說， Fortify還沒有看到開發人員覺醒，開始在Java代碼編寫過程中采用安全措施的翻天覆地的變化。除了依賴那些開發人員之外，一種更有效的方式就是與框架的所有人和軟件制造商討論，讓他們看看，要使網絡變成一個更加安全的編程的所在，還能夠做些什么，Chess說。然而，這也不是一朝一夕可以糾正的。

“還有很長的路要走，”他說。