GSS資安電子報0117期【一次弄懂網頁應用系統 (Web Application) 5 種資安防護措施: PT、WAF、DAST、SAST、IAST】

2015年六月05日(五) PM 03:25

 來源: Checkmarx 提供  

 翻譯整理: 叡揚資訊 資訊安全事業處

透過特定網站散播惡意軟體給特定的使用者 (也稱做水坑攻擊 (Watering hole attacks) 、政治激進份子如匿名者(Anonymous)的駭客攻擊、以及針對CMS系統的大型攻擊等等事件層出不窮,使得網頁應用系統的安全性成為近幾年來的熱門話題。

正當這些網頁攻擊專注在應用層的時候,多數組織持續地把他們的安全防護資源投入在網路層,例如:IDS和防火牆。雖然網路層的解決方法能夠過濾出不合法的連線、甚至可以防禦常見的DDOS攻擊,但是這些解決方法仍然使得應用層暴露在來自於被稱為合法Session的攻擊之中。舉例來說,SQL隱碼攻擊(SQL Injection attack)能夠操作後端資料庫去取出機敏資料,而查詢(Query)本身則似乎是來自於合法的來源;跨站指令碼攻擊(Cross-Site Scripting attack或XSS attack)允許攻擊者執行竊取Session或是偽裝成未知的使用者進行的交易,這種行為對IPS來說是合法的行為,並不會視為攻擊。讓我們將某個組織的伺服器比喻為一個公開的俱樂部,警衛可能會拒閒雜人等於門外(i.e., 網路層防護),但是重點應該放在那些可以進入派對(通過第一層防護)、而且可能做出失態舉動的人身上。相同地,應用層的防護旨在保護網頁伺服器。

一個完善的資訊安全策略必須包含網頁應用層(Web application layer)的防護,所幸現存的技術之中仍有一些的目的是為了保護這個層級,而且這些方法不只是為了靜態網站所設計,他們也考慮到了現今動態網頁應用系統的生態。

本文所要介紹的是各種網頁應用系統的安全工具,而標示出重要的選擇依據來幫助各位選擇適合自己環境的應用系統安全技術。

五種網頁應用系統安全措施

網頁應用系統防護措施包含了五種主要的方案:

  1.  滲透測試 (Penetration Testing, PT)
  2.  網頁應用系統防火牆 (Web Application Firewall, WAF)
  3.  動態應用系統安全測試 (Dynamic Application Security Testing, DAST)
  4. 靜態應用系統安全測試 (Static Application Security Testing, SAST)
  5. 互動式應用系統安全測試 (Interactive Application Security Testing, IAST

其實還有其他正在成長中的方案,但是他們的成熟度還不足以讓大型企業採用,因此我們把重點放在這五種廣為人知的安全措施上。

 

1. 滲透測試 (Penetration testing, PT)

滲透測試是一種用以評估組織安全情況的程序,它透過模擬駭客行為來操作組織的系統及程序。滲透測試包含了橫跨所有層級的手動及自動程序。

對於網頁應用系統,滲透測試員藉由遠端竊取Session cookies、上傳惡意軟體到網站上、攻擊安全驗證機制的漏洞以及其他類似的攻擊模擬進行安全穩定性測試,攻擊模擬大多是自動進行再加上一些手動調教來增加精確度。

各個組織可能會擁有他們自己的滲透測試小組或是委外顧問服務,不管是使用哪一種方式,滲透測試基本上都是會定期進行的。

滲透測試的效益:

  • 測試範圍很廣,且提供了很好的應用系統安全健康診斷報告。優秀的滲透測試員甚至會提供建議及修改方法。
  • 人工測試比起照表操課的程序更靈活。滲透測試員具備開發經驗、同時又擁有破壞性的駭客想法,熟悉各種平台並能建立新的工具且擅長尋找程序間傳遞的會話。

滲透測試的缺點:

  • 滲透測試只能提供特定範圍、時間點內運行時的安全狀態,但是網頁應用系統會隨著時間而變動成長,而滲透測試一般來說無法完全囊括這些變動。
  • 滲透測試員無法在合理的時間內針對所有程序、平台、情境進行測試,因此多數的滲透測試員選擇以自動化程式來增進他們的工作效率。
  • 費時。完整的滲透測試再加上結果的解讀需要很多時間,而且滲透測試中包含了不少人工測試,一位滲透測試員平均需要花上3個星期去測試20個大型網頁。
  • 滲透測試需要特殊的專業知識和時間,而且必須定期的去執行,導致進行滲透測試的價格高昂。

2. 網頁應用系統防火牆 (Web Application Firewall, WAF)

網頁應用系統防火牆 (WAF) 被放置在應用系統之前,用來即時檢查來自網路的請求內容,若請求內容有攻擊傾向即將其阻擋,否則使其正常運作。WAF可以是一種設備,也可以是一種將流量重新導向至雲端服務來做請求過濾的SaaS。

WAF的效益:

  • 當WAF的阻擋模式運作時能夠即時保護組織架構,這表示即使有漏洞被發現,WAF也能防止目標受到攻擊。
  • 深入觀察實際的威脅,有下列兩個好處:
  1. 可以排定漏洞的優先修復順序。因為可以看到最常遭受到的攻擊種類,所以可以針對該種類的攻擊投入資源。

  2. 提供及時的威脅情報。觀察攻擊請求可以幫助WAF及早阻擋攻擊,舉例來說:如果WAF偵測到一個SQL隱碼攻擊來自於某個切確的位址,則WAF可以自動將所有來自該位址的請求視作惡意請求。

  • 能夠阻擋商業邏輯攻擊 (Business Logic Attacks, BLAs),例如應用層的阻斷服務攻擊(DDoS),甚至是一些偽裝的例子。以網路售票系統為例,攻擊者可以從不同電腦偽裝成合法的使用者訂票來塞滿系統的佇列以造成DDoS。
  • 受開發者歡迎。開發者通常想要專心做開發,而不用為了迎合應用程式安全檢測工具阻礙他們的動作。WAF能夠減輕資訊安全及開發組之間因安全的程式撰寫而產生的隔閡。
 

WAF的缺點:

  • WAF不能解決問題,就算WAF阻擋了攻擊,但它並沒有實際解決問題,只是暫時性的而已。所以若攻擊模式改變、或是規則定義不完整、甚至是WAF運行錯誤,這些都可能使弱點暴露在攻擊下。
  • WAF為其所保護的應用系統客製化。這表示每次應用系統修改,WAF都必須重新設定,在像是Agile和DevOps這種新式迅速發佈的開發環境下,為了調教安全設定而延後發佈是不可行的。
  • WAF可能也會阻擋合法的請求。合法的請求可能因為誤判而無法執行。
  • WAF如其名,它們只對網頁應用系統有效,但是如果今天開發的是一個即時系統、手持應用系統、嵌入式裝置、或是汽車呢?
 

3. 動態應用系統安全測試 (Dynamic Application Security Testing, DAST)

動態應用系統安全測試(DAST)對網頁應用系統輸入不同的輸入值來檢查應用系統是否有暴露的漏洞。DAST會依照一份事先定義的弱點清單去嘗試破解目標的網頁應用系統。市面上的「應用系統網站弱點掃描」多指DAST,也稱為黑箱動態測試。

DAST的效益:

  • 揭露一些只有在運行中才會顯露出的漏洞。舉例來說:它可以找出設定錯誤的地方,或是根據動態反映所產生的問題。
  • 與第三方程式整合。應用系統常常都會參考到外部套件或是函式庫,在這種情況下去檢查原始碼並理解它的行為幾乎是不可能的。然而根據應用系統的功能去輸入各種的值來測試可以幫助使用者了解這個應用系統的運作。
 

DAST的缺點:

  • 能找到的漏洞有限。DAST工具僅針對請求與回應進行分析,因此DAST無法找出像是設計瑕疵、或是無聲攻擊(non-reflective attacks)之類的隱藏問題。
  • 無法完整包含整個應用系統。DAST會掃描整個應用系統來尋找它的進入點,但是有些DAST工具已經被發現它們會忽略較小或是不常使用的頁面,導致這些頁面不會被測試到。
  • 任何程式改動都需要重新掃描。重點在於DAST必須在完整的網頁應用系統上運行,如果程式碼有所變更,則它必定要被封裝成應用系統來進行動態掃描。在一般新版本釋出的環境下,沒有任何安全計畫可以為了進行DAST檢測流程而延後版本的釋出。(DAST檢測流程:封裝應用系統以進行掃描、將結果給開發組進行修正、然後再重新封裝進行二次掃描)
 

4. 靜態應用系統安全測試, 亦即源碼檢測 (Static Application Security Testing, SAST)

靜態應用系統安全測試(SAST)不是去測試最後完成的程式,而是藉由檢查應用系統的原始碼來找出漏洞。部分的SAST是在編譯完成的二進位碼(Binary code)上運作,另外一部分則是會去分析未編譯的原始碼。理所當然地,SAST能夠以更多元的角度去檢查程式流中可能被攻擊者所發現的漏洞。SAST 屬於「應用系統網站弱點掃描」的一種,亦稱為白箱測試、源碼檢測

SAST的效益:

  • 在開發階段就及早修復問題比起之後再回頭來修正更容易,安全漏洞的問題就如同一般Bug的情況,舉例來說:在開發階段越早找到弱點,修正所花費的資源就越少。大多數的SAST工具都能夠和開發環境整合,使得開發者能夠在撰寫程式時去測試其安全性。針對原始碼進行掃描的SAST工具讓開發者們能夠在編譯前就對程式的安全性進行測試。
  • 弱點被直接從原始碼中修正。SAST工具結果會指出有問題的程式片段,某些工具甚至提供了最佳修復點的功能,指出某種弱點產生的源頭並做出有效的修正。
  • 測試範圍包含了各種程式語言。SAST不僅能對網頁應用系統進行掃描,還能夠於嵌入式系統、電腦程式語言等等的掃描。在這邊我們以惡意軟體的感染為例來說明橫跨所有系統的安全開發的重要性;惡意軟體常常都是藉由使用者的瀏覽器漏洞散播,也有其他通過像是Adobe之類的常見應用系統中的漏洞來感染系統的方法。軟體供應商能提供給他們的客戶最顯而易見的惡意軟體防護建議就是一開始就不要讓瀏覽器或應用系統有漏洞。其實在這類系統中建立安全開發也是有實質上的益處的,現在很多公司像是Google、Facebook、Yahoo等等都提供了「Bug獎金」的機制,如果發現應用系統漏洞即提供報酬。所以程式越安全,所需付出的Bug獎金就越少。
  • SAST適合穿插在各種開發環境和模型中,包括Waterfall、Agile和DevOps。

SAST的缺點:

  • 誤判。SAST工具可能會將安全的程式碼誤判為弱點,導致「狼來了」症狀發生。因此擁有高精確度且能夠簡單、快速的篩選出誤判的SAST工具是很重要的。
  • 會回報一些不會被外部所揭露的問題。就算應用系統真的含有弱點,這並不代表該弱點就會被外部所發現。
  • 結果是根據風險層及分類的,你並不知道哪個弱點是受攻擊者鎖定的,所以只能針對現在看到的風險而不能針對實際上造成的風險去做優先排序。
 

5. 互動式應用系統安全測試(Integrated/Intrinsic/Interactive Application Security Testing, IAST)

互動式應用系統安全測試 (也稱做整合式應用系統安全測試 IAST) 是結合了SAST和DAST的技術,我們可以從它多樣化的名稱來知道這種技術還沒有很多成果,不過很巧的它們都不約而同可以縮寫成IAST。有些IAST工具提供了能夠在運行時觀察程式流的功能,其它的則會去針對攻擊模擬中成功的部分測試。先別看這些成果,IAST需要受檢測的應用系統所需的設備或是運行環境,這代表除了原始碼之外還需要各種監控設備,這些監控設備會根據事先定義的請求而觸發。

IAST的效益:

  • IAST擁有和DAST相同的效益,再加上兩個額外的功能:能夠回報無聲攻擊而且能指出產生弱點的程式碼位址。

IAST的缺點:

  • 需要安裝Agent軟體。應用系統所使用到的設備需要植入Agent(例如:監控設備),這會增加工具設定複雜度和測試速度。
  • 缺乏自動化。有些對應到程式流程的請求必須要手動設定,因此該應用系統的測試範圍就會受限於人類的操作。再者,缺乏自動化可能還會導致矛盾的結果產生。
  • 精確度及較少的弱點覆蓋率問題。根據IAST的實作方法,這項工具可能會產生誤判或是漏判。IAST工具在檢查程式流程時可能會產生誤判;另一方面,IAST工具在一連串預設的攻擊情境下可能會產生漏判。

建立階層式的防禦

總歸來說,您不得不選擇上述的防禦技術,否則等於是坐以待斃。

另一個重點是沒有任何一個解決方法是可以百分之百給予你保護的,理想的應用系統安全策略應該從開發階段開始,接著在主要系統上放置WAF、週期性地進行滲透測試,然後在程式碼變動時檢查程式碼。我們發現在大多數的環境裡,像是錢、誤判還有時間跟資源都在建立理想策略上佔有一席之地。因此我們建議從上述防禦技術中挑選一到兩項,然後從中挑選出最適合您環境及商業需求的工具。

相關分類主題: 軟體安全Mobile 安全
 

Follow us

立即訂閱以收到最新資安文章