https://www.informationsecurity.com.tw/Seminar/2024_PaloAlto/
https://www.informationsecurity.com.tw/Seminar/2024_PaloAlto/

觀點

資安大黑洞

2004 / 09 / 27
文/ James C. Foster 翻譯/李慶發
資安大黑洞

你的Web應用程式確定是安全的嗎?那些每日開著80埠營業的線上企業真該好好想想這個問題。自己寫的應用程式,多是以功能性著眼,顯少考慮到安全的問題,因此常招致緩衝區滿溢(buffer-overflow)、跨網站指令碼(cross-site scripting),以及SQL隱碼(SQL injection)等攻擊。
假如一家公司不好好保護他們的Web應用程式,那隨著公司對Internet或對Intranet應用程式依賴性的增加,以及站台日趨複雜,他們所面臨的風險也將隨之升高。

自製Web應用程式爆炸性的成長,趨使開發人員必需同時具有應用程式安全性的專業,以及高深的程式技巧。面對開發安全應用程式的需求,組織有兩項基本選擇: 一是只提供某些範圍的服務:雇用安全開發專家來設計應用程式、解決問題。二是滲入通常未成熟,但快速成長的領域:在企業應用程式上線之前,先使用能夠找出安全性問題的自動化工具進行檢驗。

安全性程式語言的演化趨向,最終將減緩重要安全性更新的需求,但是至少在未來十年內,安全性應用程式仍是個需要將產品、服務以及訓練相互結合的複雜問題。雖然目前有許多的選擇,但沒有一個是完整的解決方案。

問題在於畏懼。沒有任兩個程式人員的工作方式是一樣的,因此要搞定高度的個人風格與方法,對安全性產品而言是一項挑戰。Web應用程式所使用的程式語言也有很多選擇,而每個程式語言都有自己的缺陷。像C、C++、C#,以及J#等編譯語言可以直接存取記憶體,因此會有像緩衝區滿溢以及字串格式(format string)臭蟲的漏洞問題。而執行時期語言(如Perl、ASP,以及PHP等)則深受攻擊者所害,因為開發人員無法將前端的存取(例如透過要輸入姓名、地址等欄位的表格)鎖定到後端資料庫資源。因此指令檔的錯誤會讓資料受到跨網站指令碼、SQL隱碼以及SQL操作的攻擊。
將品質管控視為服務
Web應用程式的安全性審查是由安全專家與應用程式開發人員一起執行的,它可算是原始碼開發過程中重要的一環。

自動化的應用程式安全工具無法取代安全性審查,它們多是不成熟的群組工具,大約是八、九年前的網路缺陷掃瞄器。它們掃描結果的正確性不足採信。這些工具通常會抓到50%的缺陷,而且有可能出現假陽性。此外,它們的人工智慧還沒強大到可以處理各式各樣的程式語言特色。

相對來說,品質服務商則能找出問題,並提供修復問題的建議。不像掃描器程式所產生出來的改善建議簡直不能看。一般而言,自動化工具只提供關於跨網站指令碼錯誤的一般性描述,但至於要如何修正這類的問題,特別是Perl或ASP,就沒有實用的資訊了。

服務商所提供的服務,是憑藉著有助於客戶並降低其成本的研究以及專利工具。這類服務的先鋒包括了Ernst & Young、Computer Sciences Corporation、Foundstone、Cigital、Security Innovations,以及WhiteHat Security等。

*原始碼審閱 原始碼審閱是最具全面性的應用程式安全服務。安全專家會一行一行的對應用程式進行審閱,找出缺陷,並在原始碼中留下務實、可靠的處理建議。自動化工具在這裡沒有發揮的空間。但是,程式碼審閱也是成本最高的服務,價錢視每個個案所需的時間與技術而有所不同。一個500,000行的應用程式可能需要花兩個工程師四週的時間才審閱的完。

*Web滲透測試 Web滲透測試與網路邊界測試類似。作法是針對應用程式的前端或使用者界面,進行自由地攻擊,以便找出可能的漏洞。測試者會利用自動化攻擊指令檔,或是像@stake的WebProxy之類的proxy工具,還有Achilles的免費工具等,以便在存入cookie之前先進行檢視或變更封包內容。Web滲透測試的對象是已開發完成,甚至是已發行的應用程式,它不像原始碼審閱那麼全面(或是說昂貴)。測試者常常不會建議客戶要如何修改錯誤的程式碼,但隨著需求的增加,這也快變成標準程序了。

*架構審閱 架構審閱是組織的最超值方案。程式安全大師在計畫初始時期,便直接進入「圓桌會議」,而不是在程式完成之後再進行解剖。這種主動的策略確保了產品事前的設計與實作安全無虞,如果運作得當,還可能節省數千美元。這種設計與審閱應包含外部連結的軟體(資料庫、多媒體伺服器等)、開發計畫、協力廠商保全軟體(防火牆、IPS等)、外部程式庫的使用,並討論要如何將安全性注入到軟體開發週期中。

*Web應用程式評估服務 Web應用程式評估服務通常結合了網路以及應用程式掃描等技術。服務商一般會進行通訊埠掃描,以取得基本的OS設計並了解Web應用程式的架設環境,然後再使用專用或市面上的Web應用程式掃描器來偵測缺陷。



方興未艾的自動化解決方案
Web應用程式是以多種程式語言所寫成,這也意謂著程式風格具有無限的可能性。因此,應用程式安全性產品的花樣也不少,從主動的應用程式與程式碼掃描器,到被動的二進位檔分析工具皆有之。

這些產品約略可分為四個族群:原始碼掃描器、應用程式掃描器、編譯時期分析器,以及安全性開發資源等。前三項可讓程式團隊驗證他們原始碼樹狀結構的安全性,而第四項則是由開發者的觀點來處理程式的安全性問題。

Nessus以及Internet Security Systems的ISS Scanner等網路掃描器,最常用來掃描Web應用程式,但是它們能做的不過是掃描靜態的攻擊,因此很難在線上應用程式上取得一席之地。

*原始碼掃描器 原始碼掃描器是開發人員與品質的保障工具,它可以找出潛在的危險功能及函式,並且能根據經驗預測應用程式中的缺陷。全新開發的掃描器產品(一些專業顧問在實務上也會利用相似的工具)能穿梭於原始碼樹狀結構之中,並找出缺陷所在,與之前的免費軟體比較起來,假陽性的狀況也更少了。

Ounce Lab的Prexis可以掃描C、C++,以及即將能夠掃描Java等程式碼。Prexis使用文意分析來找出函式呼叫是否正確與安全。舉例來說,它可以找尋strcpy()函式,這個函式在C以及C++中常遭到誤用而導致緩衝區滿溢的問題。Prexis會將其標示為具風險性的函式,並會判斷輸入變數是否太寬鬆,而容易讓攻擊者造成緩衝區滿溢的錯誤。

它還可以為程式的整體風險進行「評分」。雖然這對開發人員沒什麼助益,但對於產品經理來說卻是大有用處,產品經理可利用這個分數來評斷程式距離可上市的安全品質還差多遠。

*應用程式掃描器 應用程式掃描器借助了介面掃描或是二進位檔分析的功能。介面掃描器可進入Web網站,對原始碼進行篩檢,以找出可能的機密資訊,並且判斷如跨網站指令碼、SQL隱碼,或是目錄周遊攻擊的可能性。 雖然這些工具不善於偵測競賽狀況(race condition)或緩衝區滿溢,但它們可以在企業Web應用程式發行之前,偵測出許多常見的弱點及重大缺陷。Sanctum(最近已被Watchfire併購)的AppScan、Kavado的ScanDo、SPI Dynamics的WebInspect以及Application Security的AppDetective都是掃描器的領導品牌。它們都具有Web攻擊的資料庫,資料庫中還記錄了分析網路蜘蛛原始碼以及攻擊站台表單用的多種特徵。

Cenzic的Hailstorm的特徵資料庫比它的競爭對手較小,但它也是個「fuzzer」,這意謂著它利用了fuzzy邏輯技術,使它精於找出緩衝區滿溢的錯誤。

對於尚未發達的軟體公司,以及開發商用級獨門軟體的大型公司而言,二進位檔分析常被當做最終的品質確認之用。這些工具可以分析編譯過的應用程式二進位檔,以便找出記憶體漏洞、緩衝區滿溢侵入點、字串格式臭蟲,以及競賽狀況等問題。產品包括了@Stake的SmartRisk Analyzer、HB Gray的BugScan,以及Halvar Flake開放源碼的BugScam計畫。Security Innovations也計畫將其自行開發,用於自家服務的指令檔與工具,發展成二進位檔分析產品。

*編譯時期分析器 市場上第一套編譯時期分析器是Fortify Software的Fortify Source Code Analysis Suite,雖然它所費不貲,但卻可以在產品發行前,自動找出近75%的臭蟲。這套工具利用模擬的編譯器來找出不安全的程式碼模式。無論是不當的系統呼叫,還是可能發生SQL隱碼或競賽狀況的弱點,Fortify的1,500個追蹤路徑特徵(也就是規則)都可以找的出來。

雖然這項工具是後開發時期最棒的程式碼分析工具,但Fortify目前只出了C/C++以及Java的版本。

*安全性開發資源 安全性開發資源在本質上更接近安全性程式語言與函式庫的目標。最好的程式碼安全工具就是你可以不需要的工具。要等完全安全的程式語言上市,還有好長的一段路要走,但在SPI Dynamics以及Microsoft的帶領之下,應用程式安全性開發也開始有了些進程。 Microsoft的.NET framework的學習曲線很陡,但對於那些開發完全.NET以及C#的工匠來說,潛在的漏洞已少了一大半。緩衝區滿溢的問題不見了,同時也去除了三分之一的嚴重漏洞。其他的優點還包括了應用程式權限管理,以及更容易地將安全性加密程式庫整合進資料傳輸與儲存中。

SPI Dynamics發行給Visual Studio .NET物件用的Secure Objects套件,可以輕易地實做套進全新或已存在的程式中。只要使用這些物件便可立即讓開發人員快速地開發應用程式,因為它的物件與方法都已確定是安全的了。Secure Objects在驗證使用者輸入方面做的很不錯。它可以自動攔截或禁止可疑的字元,以及目前已知可用來騙過驗證表單的攻擊方法。

Catalyst Development出品的安全socket程式庫可用於商用軟體中。想想看有多少的缺陷都是從收到不正常的網路輸入而來的,由此可知它是個絕佳的資源。這些函式庫可確保透過網路餵給程式的資料,都會被解析成適當的格式,並儲存在執行時可安全取用的地方。

責任不全在科技
無論公司是低成本還是大製作,都沒有理由花費10萬美元來保護一個年收益不到50萬美元的產品。想想80/20法則吧(20%的缺陷會導致80%的風險),只要專注在那些已包裝進自動化攻擊工具的常見缺陷就好了。

即使有了全新且「更具智慧」的技術,還是要記住一個重點,所有缺陷都是由訓練不精的開發人員所做出來。因此,你必須將最大的投資,對辦公室隔間的沉默工程師們進行持續性的教育。


本文作者James C. Foster(jfoste24@csc.com)是Computer Sciences Corp.公司的全球安全開發副主任。他是Hack the Code(Syngress,2004)一書的技術顧問,也是即將推出的Advanced Security Code development(Addison-Wesley,2004)與The Programmer’s Ultimate Security DeskRef(Syngress,2004)等書的首席作者。