阿碼外傳－阿碼科技非官方中文 Blog: 談源碼檢測: CodeSecure的架構與技術

源碼檢測在這幾年十分的火熱，難得的是這股源碼檢測熱潮不是資安廠商造勢呼口號或恐嚇取財的結果，而是來自用戶的迫切需求與怒吼。越來越多企業發現防火牆沒辦法以一擋百，入侵偵測系統在緊要關頭都不會叫，紮紮實實地買了一堆資安設備卻還是讓駭客輕鬆地從網站騙取網管權限、盜竊資料庫、網頁掛馬...，這才發現過去的資安防護重心過渡傾斜在建置資安"防堵"設備，想說當網站或應用程式出現安全漏洞時，要立即地提供防堵措施 (擋 IP、擋網址、擋關鍵字、擋 OOXX 等等)，但這樣的實務經驗往往還是被駭得滿頭包，尤其有部分受駭者因而以為問題出在防堵規則不夠多、不夠細，那更慘了，又繼續買更多更高階的防堵設備，與駭客進行無止盡的軍備戰。

其實說穿了，就是網站的程式碼寫得不安全啊!駭客這幾年就專挑這些點來攻擊，而不再只是打伺服器的漏洞。從美國 CVE 常見漏洞列表就可觀察到近年所發現的漏洞幾乎都跟程式撰寫缺失有關，像是排名第一的跨網站入侵字串 ( XSS，亦稱跨站腳本攻擊)，以及第二的資料隱碼 ( SQL Injection，亦稱 SQL 注入攻擊)。

撇開血拼資安設備以自保的衝動，及憂心受駭的焦慮，靜下心想想，假設今天擔心保險箱內的金銀財寶被偷，而偏偏這保險箱又擺在公共場所( Web 網站也是擺在單位的外網讓公眾存取)，那麼當務之急是應該檢視保險箱的設計瑕疵，還是要檢討如何在方圓百里內加派更多警衛與加裝更高階保全設備?!我們很慶幸越來越多人發現要作 Web 網站的資安防護就該從源碼檢測著手，從 Web 應用程式揪出這些不安全的程式碼，在最源頭，亦即程式撰寫層次，便避開可能產生安全風險的疑慮，這才是正本清源地之道。美國國家標準局 ( NIST ) 開始在發展軟體開發生命週期中加入安全考量；繼 CVE 之後，美國國土安全部 ( DHS ) 也推出 CWE (常見軟體缺陷列表) 來提醒開發人員各種的不安全程式撰寫，我們的CodeSecure率先支持與支援CWE；在中國的「軟件產業 "十一五" 專項規劃」中指出應採用新的軟件工程方法開發可信的應用軟件，以提高軟件的安全性。台灣也在「政府資安作業共通規範」計畫中重點發展與示範導入的「 Web 應用程式安全參考指引」草案，正是推廣從源碼檢測著手的方向。全世界都動起來了!

當初我們很早就看到這個重大問題，攻擊方 (駭客) 越來越厲害 (自動化工具、大規模攻擊、僵屍網路)，但 Web 應用程式卻無任何自動化工具來協助開發人員發現撰寫缺失，因此我們在2002年實作以自動靜態分析 ( Automated Static Analysis ) 技術為基礎的源碼檢測系統 (稱為 WebSSARI )，並在2003年對上百個知名開放源碼套件進行 XSS 與 SQL Injection 弱點的源碼檢測 (隔年 OWASP Top 10 2004 首次公布才將此二弱點列為十大Web撰寫缺失，而在2007年的 OWASP Top 10 2007 中此二弱點的排名更提升為第一位與第二位)，在2003年寫完論文投稿，被 WWW 2004 接受並提名年度最佳論文，之後就成為阿碼科技的主力產品 CodeSecure 源碼檢測。下圖直接將當初論文中的架構圖剪下貼出：

在技術這方面，當時我們採取軟體工程領域中軟體驗證的作法，以自動靜態分析技術達到不影響程式之執行，於編譯期計算出程式在執行時所有可能的狀態。早期的軟體驗證為人所詬病的是執行效能始終無法提升，解析器的速度扮演關鍵的角色。由於程式語言的語法解析與諸多變數狀態，會消耗大量的運算成本與記憶體資源，如何有效降低解析成本便可大幅提昇解析器的執行速度。在過去此部分的實作常受限於狀態擴張 ( State Explosion ) 之問題，而無法有效驗證大量的程式碼。為避免此瓶頸，我們在分析源碼之前，首先將Web應用程式之弱點正規化為安全資料流之問題。我們先解析出程式碼中可疑的進入點，並標示所有惡意函示庫，以及可能的輸出點，這種作法讓我們將複雜的 Web 程式碼資安漏洞正規成一種自動狀態機，即 Latice 模型。正規化之後，我們配合所研究的語法暨設定弱點資料庫，發展出可利用靜態之分析來減少動態分析之需求；換言之，利用靜態分析，我們準確地標出程式中需要動態分析之部分 (也就是可能有弱點之部分)，在程式尚未執行時，我們就能識別這些脆弱點需要特別處理，否則可輕易遭受外部惡意使用者的攻擊，譬如插入惡意腳本字串，含有 XSS 或 SQL Injection 等撰寫缺失。當時的源碼檢測系統 WebSSARI (即 CodeSecure 的前身) 日後被美國微軟專精源碼檢測的研究員 Ben Livshits 博士譽為此領域的開創者，爾後世界各國相繼投入的學術研究均引述我們的成果，迄今已超過上百篇。

理論是如此，講這麼多我小結一下源碼檢測過程中幾個重要的分析步驟(有機會再分享這些步驟的技術細節...):
1. 進入點分析 (哪些是不可信任的資料?)
2. 語言語法分析 (哪些會影響安全參數?)
3. 輸出點分析 (資料會如何離開?)

源碼檢測的出現造福廣大網站建置案的承辦人員、驗收人員與開發人員，因為無論是在徵求建議書( RFP )要求應避免的資安風險，或在檢測報告中增列源碼安全性檢測，或在驗收階段中要求檢附源碼檢測報告，都因為有自動化源碼檢測工具的出現，才得以讓這些流程與控制措施得以落實與順利推動。

其實隨著 CodeSecure 在2007年初正式推出上市至今，堪稱是十國聯軍的在台研發團隊貢獻最多(吸引這麼多頂尖人才到台灣，還讓我們在2008年獲經濟部頒發金根獎! 這獎項的名稱還蠻 kuso 的 XD)，或許美國總部將來會在其他地方成立研發中心，但目前的研發能量主要還是放在台灣的亞洲研發中心。這群人沒日沒夜地持續在精進研發，陸續開發出多個全球首創的源碼檢測功能，包括硬體式架構、純 Web 介面、弱點收斂分析、互動式弱點追蹤、弱點深度分析、受駭機率分析等等(這也讓我們獲頒 Red Herring 全球十大新創企業)，我們就是要讓源碼檢測的操作非常容易使用，檢測結果非常容易瞭解，修補方針非常容易落實。同時，隨著客戶越來越多，我們為這個產品投入的技術支援與人員編制可說是一眠大一吋! 畢竟源碼檢測絕對不是產品的買賣而已，尤其是本地客戶可能會遇到的各種源碼檢測問題，都可經由我們本地的專業顧問直接參與及輔導，迎刃而解。

1. 硬體式架構 (免軟體安裝，所有人都連來這台作分析，不用麻煩地裝一堆有的沒的)
為了達成這個終極目標，每個要檢測的語言我們都得自行撰寫編譯器，這大幅增加我們的研發成本，但堅持這個路線也讓我們與其他競爭對手有所區隔，掌握編譯器攸關源碼檢測的涵蓋率與精確性。話說現在這個年代念資訊科系的學生聽到編譯程式都唯恐避之不及，所以我們的這個決定在競爭對手眼中肯定也是瘋了。

眼尖的人可能發現這只是個 CodeSecure 空殼 XD 沒錯，這個樣品第一天送到公司時大家激動地差點哭了，還鋼琴烤漆耶~ (後來的中高階 CodeSecure 機種則是用其他的機構設計)

這張圖巧妙地將CPU使用率停在2.0 :>

2. 純 Web 介面 (一個網址服務整個單位，所有同仁都可上網直接體驗源碼檢測，"節能省碳"!)

3. 弱點收斂分析 (開發人員需要去修補的弱點源頭是可收斂的，儘管駭客可攻擊的路徑是發散的)
過去的資安生態是作掃瞄的人很開心，「哇，一堆漏洞!」，但要負責修補的人很痛苦，因為有助益的資訊太少(弱點掃瞄、滲透測試最多只能點出結果卻沒有前因)，不知為何要修，且漏洞都沒有進行系統化的收斂，也不知從何修補起，更甭談啥瞇幾百個 XSS 弱點的修補優先順序。源碼檢測搭起資訊安全與程式撰寫兩專業領域的橋梁，讓資安人員與程式人員更順利地共事與共識。