GSS 資安電子報0016期【Java開放源碼應用程式的安全性 】

開放源碼(OSS) 的快速成長,使用成本是很大的一個考量,而開放源碼的可靠度則讓決策人員不單單只能以成本作為最主要的考量依據。

成立於2006年的Java Open Review,提供由Fortify公司捐獻的免費的Java開放源碼,可找出資安弱點,搭配FindBugs能找出品質方面問題。這份報告提出數個常見的Java開放源碼工具,包括Hibernate、Spring、Struts與Tomcat。這些工具並非單獨存在,而必須與其他工具相互搭配。這些工具在Java開發國度裡已經廣泛的使用中。

我們由掃瞄結果可得知:

1. Java可靠度越來越高—Java Open Review(JOR)發現由Java寫出的應用程式比C與C++寫出的應用程式要來的可靠。一般說來,Java元件的臭蟲比商用的C與C++程式要來的少。

2. 最常見的弱點—cross-site scripting—跨網站腳本攻擊是數量遠高於其他風險弱點的一種攻擊方法。

3. 開發人員傾向使用開放源碼的範例程式碼,導致風險弱點出現—JOR發現開發人員重複使用這些範例程式碼。除此之外,某些案例發現,這些範例程式並未含有風險弱點,但是卻導致開發人員寫出有弱點的程式。

例如,Hibernate有一個名為createSQLQuery()的方法,可接受傳入單一字串參數。這個介面鼓勵開發人員以串接方式組成SQL字串,間接的導致風險弱點產生。

Java OSS的安全性到底如何?

當真正要使用開放源碼軟體,安全性是一個重要考量。許多與應用程式串接,帶有機敏資料介面,可能已被駭客鎖定。某個JMP回報網站提到:「企業用戶常會忘了開放源碼的公開性,而部署在重要或機敏資料的網站上。」

我們不厭其煩的勸告用戶這是個很重要的資安問題(來源:JMP Securities, Turning the Software Model Upside Down: The Proliferation of Open Source, June 2006)。

像是作業系統或資料庫這樣軟體基礎架構程式有遭受入侵的可能,但是他們不是駭客最主要的目標。就如同Gartner評論道,「軟體中的『最後一哩』是應用程式。最好的網路設備、主機、資安設備都無法保護脆弱的應用程式。應用程式是資安必先考量的對象(來源:Teresa Lanowitz, Now Is the Time for Security at the Application Level, Gartner, 2005)」。企業使用OSS,必須考量從軟體基礎架構程式的使用轉移到一般的OSS應用程式。過去我們把焦點放在OSS的軟體基礎架構程式,如作業系統(Linux、NetBSD)或資料庫(MySQL、PostgreSQL),而程式語言以C和C++佔大宗。雖然OSS社群仍著重軟體基礎架構程式,但是對於Java,與提供對外服務的應用程式,我們不可掉以輕心。

以Java寫成的開放源碼應用程式遠超過其他語言。事實上,Java寫成的應用程式數量幾乎是第二名PHP的兩倍。下表是Google Directories顯示最常使用的程式語言寫成的應用程式數量:

 

語言

OSS應用程式數量

Java

2752

PHP

1435

Perl

963

C++

852

C

289

來源:http://www.google.com/Top/Computers/Programming/Languages/Open_Source/

關於Java Open Review

Java Open Resource Project網站(http://opensource.fortifysoftware.com)上提供使用Java開發的源碼軟體的臭蟲回報與安全弱點。受惠於這個專案的有:

  • 開放源碼社群—在工具受到歡迎而廣泛使用之前,JOR希望能幫助開放源碼專案先行找出弱點。專案開發人員可以得到Fortify SCA完整的掃瞄結果,並且能很輕鬆的在FindBugs上檢核、註解,與修改問題。
  • 開放源碼使用者—開放源碼使用者可以評估使用不同開放源碼專案所需承受的風險。

JOR專案能找出弱點風險,提供使用者完整的報告,不過,JOR的結果報告不會包含修復建議。

JOR專案由FindBugs與Fortify公司贊助運作。FindBugs為一開放源碼專案,可指出Java程式碼品質問題。FindBugs由馬里蘭大學Bill Pugh教授創立,並受全球大型軟體開發組織採用,下載數超過34萬多次。

Fortify是一家專門找出Java與其他程式語言安全弱點的軟體公司。Fortify旗艦級產品—Fortify SCA可在更短時間內掃瞄更多檔案並加以排序,協助資安專家進行稽核,使開發團隊指出問題所在,盡早修補弱點,達到事半功倍效果。Fortify SCA可支援多種程式語言、framework與作業系統。Fortify SCA適用於每日例行性的掃瞄,或大規模的專案完整掃瞄,自動將掃瞄結果分類,有效並快速的協助開發人員修改。

JOR專案掃瞄的對象是誰—原因為何?

JOR至今掃瞄了數百個專案,經由Fortify公司與FindBugs專案收到的顧客意見回饋,JOR也掃瞄了Hibernate、Spring、Struts與Tomcat。下表是掃瞄的結果:

 

專案

產品用途

弱點數

弱點密度

Hibernate

物件與關連性資料庫對應工具

2

0.007

Spring

Component assembly framework

4

0.037

Struts

MVC framework

8

0.127

Tomcat

J2EE Servlet Container

66

0.111

平均密度= 0.0705

結論

1) Java語言可靠度越來越高

JOR發現由Java寫出的應用程式比C與C++寫出的應用程式要來的可靠。一般說來,Java元件的臭蟲比商用的C與C++程式要來的少。依據卡內基美隆大學的CyLab Sustainable Computing Consortium指出,程式開發時通常每千行程式碼會出現20-30個安全弱點與品質問題。相形之下,JOR的掃瞄結果平均弱點密度為0.07,也就是每千行程式會發生0.07個資安與品質問題。開放源碼弱點資料庫預測從2005年到2006年弱點數會有20%的增長,盡可能及早在開發過程中加入安全程式碼編寫考量才是王道。

Java語言的可靠度來自於Java的兩大特點:型態(Type)嚴格檢查與記憶體保護措施。這兩大特點還必須與下列方法搭配:

  • 因為Java編譯器採取型態嚴格檢查,Java開發人員在編譯同時即可自己找出許多問題。
  • Java程式執行時,JVM必須確保尚未被解決的臭蟲不會造成大規模的災難。對C和C++而言,信手拈來都有可能寫出有SQL Injection弱點的程式,但Java不會。

即便Java比C和C++要來的可靠,每個被掃瞄過的專案都還是出現些許問題。Java開發人員不應期待這些開放源碼工具比自己寫的要來的好。開發人員檢查自己程式碼的流程也應該使用在這些開放源碼工具之中。

2) 最常出現的的弱點:Cross-site scripting

JOR掃過的專案中,XSS弱點數量顯然比其他弱點要來的多。XSS弱點允許攻擊者在受害電腦的瀏覽器上執行JavaScript,造成個資遺失,攔截身份證明,或攻擊受害者內部網路電腦。直到2009年XSS仍舊是CVE(Common Vulnerabilities and Exposures)最常出現的弱點之一。除此之外,XSS也高居CWE(Common Weakness Enumeration)與OWASP Top 10的榜首。

為了解發生XSS弱點有多麼簡單,我們來看看下面的JSP程式片段。這段程式碼從網頁讀入代表員工ID的變數eid,並在頁面顯示出來:

<% String eid = request.getParameter(“eid”); %>
...
Employee ID: <%= eid %>

如果使用者輸入的是帶有數字與字元的值,在這個例子裡面可以正常執行。如果攻擊者輸入帶有特殊字元(meta-characters)或程式碼,瀏覽器便會執行,並顯示於頁面。

3) 開發人員傾向使用開放源碼的範例程式碼,導致風險弱點出現
第一種狀況:不安全的範例程式

為了解釋開放源碼工具如何使用,多數的工具都會附上範例程式或是範例工具。JOR找出這類範例程式的弱點比工具本身的弱點還要來的多。

範例程式裡面的弱點要特別注意,因為許多開發人員會拿範例程式當作程式開發的基礎。一旦範例程式成為正式程式碼的一部份,就無法以版本更新方式進行弱點修復。

就範例程式的定位而言,他不應該作為該開發方式的最佳解法,尤其是以資安角度來看。

第二種狀況:程式介面潛藏危機,導致誤用

某些狀況是,工具掃瞄後並未出現弱點,但是卻導致開發人員寫出有弱點的程式碼。例如Hibernate裡有一個方法createSQLQuery()可接受單一字串參數。這個介面鼓勵開發人員以串接方式組成SQL字串,間接的導致風險弱點產生。下面的程式碼是使用Hibernate介面,動態產生SQL查詢條件並加以執行。查詢依照使用者輸入的名稱,程式會限制只有授權的使用者可查詢。

String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter(“itemName”);
String query = “SELECT * FROM items WHERE owner = ‘”
+ userName + “’ AND itemname = ‘”+ itemName + “’”;
List items = sess.createSQLQuery(query).list();

以上的程式碼會組成以下的查詢條件:

SELECT * FROM items WHERE owner = AND itemname = ; 然而,這個查詢條件是由使用者輸入的字串動態組成,這個查詢條件只有在使用者輸入正確的itemName變數值(不包含單引號)才會正確的執行。如果攻擊者在使用者名稱輸入「wiley」,在itemName變數輸入「name」或「’a’=’a”」,那查詢就會變成下面這個樣子:

SELECT * FROM items WHERE owner = ‘wiley’ AND itemname = ‘name’ OR ‘a’=’a’;

上式多加的「OR ‘a’=’a’」查詢條件導致where查詢子句永遠成立(為真),那麼查詢條件就簡化為:

SELECT * FROM items;

這種簡化讓攻擊者取得只有授權過使用者可讀取的資料,回傳items表格所有的內容。

加入Java Open Review

Java Open Review專門對付Java開放源碼,找出臭蟲與程式風險弱點。我們希望能掃瞄多樣的工具軟體,像是Azureus、Tomcat與PetStore。我們會對大眾提供總結報告,對專案維護人員提供詳細的專案掃瞄報告。我們的掃瞄工具為FindBugs與Fortify SCA,如果您也希望能掃瞄您的專案,請瀏覽http://opensource.fortifysoftware.com網站。

關於Fortify公司

Fortify公司資安產品協助您抵禦現今常見的資安風險:執行商業活動的應用程式。Fortify公司結合開發經驗十足的資安專家,定義源碼檢測工具市場標準,並連年獲獎,得到業界肯定。

Fortify公司獲得最高要求客戶青睞,包括世界最大最複雜的程式碼。Fortify公司也是政府機關與財星500企業的首選,產業別橫跨能源、財經服務、保健服務、電子商務、媒體業、通信業、出版業、保險業、系統整合業、與資訊管理業。Fortify公司的客戶包括:

  • 世界前五大商業銀行,與世界前八大銀行中的七家
  • 世界前七大電腦軟體公司的五家
  • 世界前五大軍火公司的三家
  • 世界前六大資安公司的三家
  • 世界前四大會計公司的三家