觀點

案例解析10大台灣系統開發安全謬誤

2014 / 04 / 11
施汎勳
案例解析10大台灣系統開發安全謬誤

多數企業決心做好資安往往都在發生資安事件以後,病急投醫常導致治標不治本的結果,有些問題若能在初期規劃就考慮,可有效節省未來修補所花的費用,透過安全檢測能達到及早發現及早治療的效果,筆者將在本文中分享過去檢測所見所聞,供各位參考。
  過去五年來,敝公司檢測團隊從6人團隊擴增到目前17人成長了三倍,從需求面可看到台灣企業與政府機關對資安的重視是正面成長的,讓我們回過頭來看,台灣企業的資訊系統是否安全?本團隊對現有客戶檢測的結果(2011-2014)進行統計,可以發現以下現象:
1. 首次購買滲透測試服務的網站,平均存在6個高風險漏洞、11個以上的中低風險漏洞(風險等級定義請參考OWASP風險評分方法)。
2. 網站程式漏洞發現數量是系統漏洞的12倍。
3. 網站漏洞前三大分別是:跨網站腳本攻擊漏洞(XSS)、注入類攻擊漏洞與應用程式身份驗證授權缺失漏洞。
4. 系統漏洞前三大分別是:作業系統/第三方程式版本過舊、弱密碼與使用預設不安全設定。
5. 複測時漏洞修補失敗前3名分別是:跨網站腳本攻擊(XSS)、注入類攻擊漏洞與未經驗證的網址重導。
  從統計結果可規納出兩點結論:一、企業自行開發的網站系統普遍存在高風險漏洞。二、多數漏洞造成主因是程式對用戶輸入的資料未進行妥善處理,甚至在修補時使用錯誤的防禦方式,因此容易被繞過進行攻擊。下面文章將分享常見的十大台灣系統開發安全謬誤(Mistake in Taiwan TOP 10),與各位進行案例分享。

一、黑名單字串過濾造成修補失效
  從前面統計數據看到,最常見的漏洞是XSS與SQL 注入漏洞,成因是程式並未對使用者輸入進行適當處理。在台灣,這兩種漏洞算是耳熟能詳,過去的案例中只有少數網站對這類攻擊不做任何防禦,而剩下約一半的網站都有「過濾」,只是方法是錯誤的。下圖 1這種修補方式常因為黑名單的不完整造成防禦漏洞,正確的修補方式應透過 Prepared Statements或者隨不同資料庫版本進行保留字元跳脫。事實上,正確的漏洞修補方式在Open Web Application Security Project (OWASP)網站上都能找到,但大多數的開發者還是選擇使用網路上的黑名單修補範例直接複製貼上,常造成修補無效。


圖 1、錯誤的黑名單字串過濾修補程式碼 (圖片來源:由本文作者提供)

二、編碼、加密與雜湊誤用
  編碼(encode)、加密(encrypt)與雜湊(hash)其特性與用途存在很大的不同,比較表請參考表1。
  
表 1、編碼、加密與雜湊特性比較表 (表格來源:本文作者整理)

  然而,對於資安概念不足的開發者而言,這三者都是把一串明文轉換成看不懂的密文,因此統稱為「加密」,這種認知是完全錯誤的。下圖2為一網站會員資料庫,案例中工程師將密碼進行Base64編碼,預防密碼明文被直接取得,殊不知有心人士只要使用Base64解碼便可輕鬆獲得明文,正確的設計是運用雜湊演算法無法逆解的特性對密碼做處理,更進一步甚至可以使用加鹽(salt)技術提升密碼破解的難度。

  

圖 2、網站會員密碼以編碼取代雜湊之謬誤 (圖片來源:由本文作者提供)

三、使用JavaScript進行安全防禦之誤用
 現今網頁大量運用JavaScript以增加使用者操作的流暢度,但如果開發者把伺服器端的資安防禦(參數過濾或身分驗證等)改以JavaScript來實作就麻煩大了。JavaScript是客戶端的直譯式語言,在瀏覽器載入網頁內容後執行,若攻擊者利用封包攔截工具對HTTP請求/回應封包中的語法進行竄改,便可成功繞過JavaScript防禦進行攻擊。最常見的案例是某會員網站利用語法「location.href = “index.htm”」將認證失敗的使用者導回首頁,避免未授權人士存取會員功能,攻擊者只要將此語法攔截並移除,便不會被導向,藉此存取會員功能並進行未授權的操作。
 使用JavaScript實作防呆機制、網頁內容的動態處理能將此語言的優點發揮淋漓盡致,但若牽涉到身分驗證、使用者輸入參數的安全性檢查,建議還是使用伺服器端程式處理較安全。

四、編碼/加密過的參數傳遞常造成WAF/IPS防禦失效
 IPS/WAF能抵禦已知的攻擊語法,但如果是加密或編碼過的內容可就不一定了。 記得之前科技部網站遭駭的新聞嗎?當時網友「名無」提供的便是Base64編碼過後的跨網站腳本(XSS)語法如圖3所示,該字串在解碼前是難以判斷為攻擊語法的,因此攻擊者常藉此繞過IPS/WAF防禦。若開發者須對參數進行編碼/加密,建議格外慎重檢視該參數解碼/解密後內容是否合法。


圖 3、編碼後的攻擊字串資安設備難以偵測 (圖片來源:由作者提供,原始測試語法來自)

五、資安設備不是萬靈丹
  進行檢測結果報告時,客戶很喜歡問筆者直接買資安設備來擋,是否為一勞永逸的方法,但上一段文章才剛出現無法完全防禦的例子,因此筆者也不敢向業者打包票。此外,在過去的經驗中,很多企業的IPS/WAF並未妥善處理SSL inspection,因而留下一個防禦的缺口,所以當客戶問到這問題時,筆者通常建議客戶在能力範圍內,盡量朝向縱深防禦佈署,該修的還是得修,不該將所有的防禦投注在資安設備上。另一方面,資安設備並不是買來放著就心安了,更重要的是企業內部的監控、分析、通報、事件處理等機制是否健全,當配套措施都齊全了,資安設備才能發揮其最大效益。

六、外緊內鬆的資安防禦策略
 基於預算與便利性的考量,外緊內鬆的資安佈署策略在企業中是常見的。根據本團隊統計,內網伺服器開啟的服務埠是外網/DMZ的2倍,而內網伺服器弱密碼或共用密碼的發生率是外網/DMZ的5倍,由此可見內網的管理通常較外網鬆散。資安常在方便性與安全性之間找尋一個平衡點,但即使在內部網路,也應遵循資安之底線。現正火紅的APT郵件攻擊模式,便是因應外緊內鬆的習性而生,攻擊者不再直接從外部攻打牢靠的城牆,而是寄送惡意郵件從脆弱的內部點燃引線。
    面對APT威脅需多點著力,強化資安體質可以參考我國資安設定基準(Taiwan General Configuration Baseline)對終端與伺服器進行安全性設定,對內部重要系統進行網路區隔並限縮存取來源。針對社交郵件攻擊的防禦導入APT郵件縱深防禦方案(如圖 4所示),同時從郵件、連線監控、終端惡意程式檢查三方面下手,降低APT攻擊之威脅。最重要的還是改變自身的心態,威脅已經不完全來自外部了,每個員工都身陷一級戰區。


圖 4、APT郵件縱深防禦示意圖 (圖片來源:中華電信資安監控中心)

七、程式委外開發之風險
  程式開發委外在今天是相當常見的,但開發商的品質有時是參差不齊的,在過去檢測經驗中發現同樣的漏洞存在多個企業中,打聽下才知道是委由同一程式開發商所製作,這種案例不計其數,下圖5為一案例分享,某公司網站被筆者團對發現存在XSS漏洞後,檢測人員嵌入一張駭客圖片顯示攻擊有效性,事後利用關鍵字搜尋,發現類似漏洞可能存在其他數個網站中。因此,在委外開發時,建議將資安的需求納入考量,詳細處理辦法可參考行政院國家資通安全會報技術服務中心發佈的「政府資訊作業委外安全參考指引」,為委外程式開發進行把關。
  
圖 5、XSS漏洞存可能存在多家企業 (圖片來源:由本文作者提供)

  
八、忽略行動應用程式上的威脅
 隨著行動裝置普及,公司行號為提升客戶滿意度,紛紛提供行動應用程式,應用程式之便利性甚至有逐漸取代Web服務的趨勢。然而行動APP在追求便利的同時又有多少人有注意到其安全性?去年開始,本團隊著手探究行動應用程式之檢測方式,現有資料與實際測試顯示,APP的安全須另外檢測在客戶裝置端的設定檔與資料儲存安全性、行動應用程式本身Binary安全性還有APP與伺服器間的安全性,比起原本的系統滲透測試,影響的範圍和目標都複雜了一些,現有的測試案例並不多,但發現利用封包攔截再對後端伺服器進行攻擊可以收到不錯的效果。

九、程式註解或除錯訊息透露機敏資訊
 程式開發過程中留下註解是正確的,但如果把註解甚至除錯資訊直接顯示在上線環境供用戶瀏覽,那就得祈禱駭客不會哪天心血來潮找上門。其實這種案例多到數不完,圖6為某網路銀行的登入頁面網頁HTML原始碼,從圖中看到當使用者登入時,註解包含資料庫查詢語句,並且將用戶密碼明文也寫在註解裡,雖然不是每個案例都向它這麼誇張,但往往能讓攻擊者挖掘到一些重要的系統資訊。我們常建議開發者盡量不要利用這種方式除錯,以免未來程式上線時忘記刪除,但還是很多人改不掉這習慣。

圖 6、註解洩漏SQL語句與用戶密碼 (圖片來源:由本文作者提供)

十、商業邏輯漏洞
 這邊特別把商業邏輯漏洞提出來講,是因為過去檢測過的網路銀行或是電子商城9成都存在此漏洞,這漏洞特別的點在於攻擊者是利用程式設計上邏輯的錯誤進行攻擊,而不是程式本身出現漏洞。這種漏洞常見在匯率轉換、紅利積點/臨時活動兌換卷或金額試算表中,通常是因為網站存在機會讓用戶在流程中任意竄改數值,若企業內部沒有帳目核對機制則可能造成金錢的損失,偏偏這類漏洞難以透過自動化掃描工具發現,因此在滲透測試中相當常見。

結論
 上面文章提到的雖然大多是程式安全漏洞的例子,但幾年檢測經驗看下來,最終資安問題還是要回歸到企業內部的制度與企業主的態度,不少企業還是選擇出事後才找上門,這時檢測的結果通常已是慘不忍睹,面對滿坑滿谷漏洞的修補壓力還有攻擊者的持續活動,蠟燭兩頭燒的局面無論對企業主或系統管理者都造成極大壓力,沒有足夠時間做好風險評估的情況下,多餘的金錢開銷、不完整的資安政策與人力資源的浪費接踵而生,治標不治本,最後還是建議大家接受資安健檢,及早發現及早治療。

本文作者現為ISP滲透測試團隊負責人