https://newera17031.activehosted.com/index.php?action=social&chash=0245952ecff55018e2a459517fdb40e3.2287&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=0245952ecff55018e2a459517fdb40e3.2287&nosocial=1

觀點

起床號

2009 / 09 / 09
MICHAEL COBB 翻譯 ■ 林佳明
起床號
所有的跡象都顯示,透過攻擊有弱點的網站應用程式來竊取敏感資料的攻擊者數量劇增,就像清晨的起床鬧鈴讓人不堪其擾。企業們已經不能再刻意忽視、繼續打盹了。

  以下的統計數字是令人擔憂的:大約有75%的攻擊是針對網站上應用層的弱點;賽門鐵克在2005年第二季所發現的弱點大部分與網站應用程式上的問題;USCERT資料庫中前20大的弱點,大部分亦都與網站應用程式弱點有關。

  大部分的公司都專注於保護他們網路相關的安全,反而忽略網站應用程式上的弱點讓入侵者有機可乘。網路犯罪已經傾向於有利可圖的攻擊,繞過傳統的網路安全防護機制;透過提升網路協定堆疊(protocol stack)以及應用層的通訊溝通,攻擊者可以直接和應用程式的程序進行互動,並且假造出像是scriptURL以及表單資料這些正常資料的攻擊資料。這樣的方式可以讓入侵者在不需要攻破任何伺服器的狀況下,就輕易的取得有價值的資料。

  每種企業都有各式各樣的網站應用程式攻擊需要擔心。較常見的攻擊包含緩衝區溢位、SQL Injection以及阻斷服務(DoS)攻擊等,以及較少被人知曉的攻擊電子郵件注入(e-mail injection)。入侵者也會利用各式各樣的fingerprint技術來專注於攻擊他們的目標。雖然入侵者使用的戰術不盡相同,但是最後入侵的目標是一致的從竊取機密資料到入侵系統,導致企業商務上的瓦解。

  本文將透過對於這些威脅、攻擊方法以及使用戰術的提點,企業們可以保護他們寶貴的資產。

撰寫不良的程式碼

  雖然許多的網站應用程式安全弱點是產品導向的,但是有更多的弱點是發生在跟產品廠牌無關的設計流程,和應用程式的使用上。根據開放網站應用程式安全計畫(OWASP, According to the Open Web Application Security Project )網站應用程式造成會被攻擊的弱點,可歸類為以下幾種:

· Invalidated input(無效的輸入值)

· Broken access control(存取控制不嚴謹)

· Broken authentication and session management(身分鑑別及連線管理不嚴謹)

· Cross-site scripting (XSS) flaws(跨網站腳本弱點)

· Buffer overflows(緩衝區溢位)

· Injection flaws(注入弱點)

· Improper error handling(不恰當的錯誤處理)

· Insecure storage(儲存不夠安全)

· Denial of service (DoS;阻斷服務)

· Insecure configuration management(不安全的組態管理)

  很清楚的,以上的問題都是因為程式撰寫不良或是執行不當,只有阻斷服務攻擊,才是唯一針對網際網路協定的攻擊。

緩衝區溢位&路徑跳脫攻擊

  因為程式撰寫不良最常見的弱點就是緩衝區溢位,當程式程序沒有限制使用者所提供資料的大小所造成的弱點,讓攻擊者可以強迫程序儲存比預期中還要多的資料。而這個過大的資料覆寫到記憶體中儲存的重要值,讓攻擊者可以控制這個程序進行插入或者執行惡意的指令 。

  透過第三方廠商產品保護不被此一弱點攻擊的方法,就是安裝系統最新的安全更新程式(patch),並且監看你網站伺服器上,所有執行應用程式最新的安全通告以及更新程式。

  一般網站伺服器會設定限制,只允許公開存取網站伺服器上特定的檔案系統,一般稱之為「網站文件根目錄(web document root)」。該目錄會存放可供任意人存取的檔案,以及網站應用程式所需要執行的腳本程式。然而,攻擊者可以透過路徑跳脫攻擊,來存取不是在這些目錄裡面的密碼列表、機密資料等檔案,這個攻擊會在URL輸入參數、cookies以及HTTP請求標頭中使用一連串的特殊符號。

  為了避免路徑跳脫攻擊,你必須透過存取控制列表進行最小權限(least privilege)管理,來鎖定並強化你的網站伺服器。微軟IIS網站伺服器避免此類攻擊最簡單的方法,就是執行IIS Lockdown工具。(下載網址http://download.microsoft.com)

資料隱碼&電子郵件攻擊

  有一種攻擊方式很明顯地正在增加當中,該攻擊方式會造成伺服器嚴重的毀損─就是injection attack。SQL injection(資料隱碼)攻擊對於一個僅開80通訊埠,並使用資料庫為基礎的網站來說,是一個很嚴重的威脅。此種攻擊的技巧非常的容易學習,甚至是在系統已經安裝所有更新程式的狀況下還是可以造成整個系統被入侵。

  如果網站會利用使用者輸入的資料來組成SQL查詢語句,而沒有對輸入資料進行正確性的檢查,攻擊者就可以利用這樣的弱點發起SQL Injection攻擊。透過修改預期中的網站應用程式參數,攻擊者可以傳送SQL查詢語句,並且直接傳送命令給資料庫。

  另一個同樣起因於缺乏使用者輸入值檢查,卻較少被人知道的注入攻擊是電子郵件注入( e-mail injection)。如果網站上存在電子郵件表單(e-mail form)─像是意見回函或是聯繫表單─這個功能就類似一個SMTP proxy(簡單信件傳輸協定代理伺服器)。垃圾郵件寄件者就會試著劫持這個功能,利用你網站上的表單來寄廣告信件。這類型的攻擊不容易被發現,常是在伺服器的IP位址被列為反垃圾郵件的黑名單時才警覺。

  e-mail injection發生在程式碼會對網站表單輸入資訊,產生電子郵件標頭的狀況下。例如,PHP電子郵件功能會要求輸入目標地址、信件主旨以及信件內容。額外的參數可以允許你產生其他特殊的電子郵件標頭,像是寄件者(From)副本(Cc)以及密件副本(Bcc)。許多PHP電子郵件腳本會使用第四個的參數,來插入傳送者的電子郵件位址,並提供給表單標頭。如果程式腳本會從表單欄位中取得名字、電子郵件位址和其他標頭資料,垃圾郵件寄件者就可以使用這些表單的欄位,來操作電子郵件標頭並且插入新的主旨、信件內容以及額外的電子郵件位址。

  再一次的,這個問題一樣是因為沒有對使用者輸入值進行預先檢查才會發生,所以這也警告了網站開發者必須完全了解他們所使用的伺服器端程式。為了確保你的電子郵件表單不會被濫用,你的腳本程式應該使用正規表示式(regular expressions)或者字串函數,過濾所有使用者的輸入值、移除任何破壞行為。

跨網站腳本程式(Cross-Site Scripting)

  不同於其他的應用層攻擊,XSS攻擊的對象是應用程式的使用者,而這樣的攻擊經常用來進行個人資料的竊取。這個攻擊將影響所有使用腳本程式的網站應用程式,並且間接攻擊應用程式的基礎架構。

  腳本程式攻擊透過注入程式碼運行,這些程式碼通常是JavaScript之類的客戶端腳本程式,並且這些程式碼影響網站應用程式的輸出。只要瀏覽這些網頁就會執行腳本程式,而這些被執行的程式,就好像是你所信任的網站要求你去執行的一樣;瀏覽器是無法分辨網站應用程式所提供的內容─哪些是合法的、哪些是惡意的。在很多的狀況下,這些腳本程式都是在使用者不會察覺的狀況下被執行。

  大部分的網站都可能會有很多的可被注入點,讓伺服器容易被這類的方式攻擊。雖然客戶端的腳本程式並不會直接的影響伺服器端上的資訊,但是攻擊者依然可以透過修改表單中的內含值,或者表單的傳送行為,來讓使用者輸入的表單資料傳送到攻擊者的網站,而影響到網站安全。大部分XSS攻擊的目的都是在竊取使用者的cookie資料。Cookie常常被錯誤的使用及存放,像是session ID等browser sessions用的敏感資料、使用者偏好資訊、以及登入資訊。如果輸入到動態產生網頁的資料,在被使用或公佈之前沒有進行任何驗證動作的話,就很有可能會被XSS攻擊。

分散式阻斷服務攻擊(DDoS attacks)

  其目的不像是在竊取資訊的跨網站腳本程式攻擊、SQL注入攻擊以及其他攻擊方式,分散式阻斷服務攻擊主要的目標在於「阻斷」任何人去使用應用程式,而且是透過大量的網路流量,來攻擊這些伺服器以及網路裝置上的應用程式。DDoS攻擊用來對特定的公司或組織攻擊,進行勒索或破壞他們的電子保護機制,而且任何人都可以在網際網路蒐集到各式各樣用來發起DDoS攻擊的工具。根據最近的調查,全世界90%的ISP都說自己每天都要付出人力,來處理繁雜的分散式阻斷流量工作。某些調查估計,DDoS攻擊的流量已經佔據了網路網路骨幹上一半的網路流量。

  很不幸的,DDoS攻擊利用網際網路基礎架構設計上的缺點,也由於是透過網際網路協定的缺點所造成的防禦困難。目前有許多種類型的DDoS攻擊,但是他們所使用的方式是很相似的─都是利用先前已經入侵的大量系統來對一個特定的目標攻擊。 兩種最基本的DDoS攻擊類型是頻寬和應用程式攻擊。頻寬攻擊是利用消耗頻寬資源的作法,例如使用快速成長的封包來佔據網路頻寬或者設備。應用程式攻擊,另一方面來說,就是破壞掉TCP以及HTTP協定會發生的預期行為,阻擋住應用程式的功能,讓程式無法處理或回應使用者的請求。HTTP half-open以及HTTP錯誤攻擊就是一組應用程式攻擊的例子。 評估你的防火牆規則和過濾器,是否可以有效的過濾這些攻擊是很重要的。例如,嚴格限制對外開放伺服器的向外連接要求(Egress filter),可以預防你的網路遭受假冒來源封包的攻擊,並且可以很容易的發現內部代理裝置的來源。

作業系統類型探測 ( OS fingerprinting)

  駭客在發動可以成功入侵網站應用程式的行動之前,必須盡可能的蒐集被攻擊目標應用程式以及基礎架構的資訊。 辨識遠端網站伺服器是執行何種應用程式的技術,就被稱呼為OS fingerprinting。進行OS fingerprinting最簡單的方法,就是發送一個服務請求給伺服器,並分析回傳封包的標頭資訊,通常都會包含該伺服器是執行哪一種版本網站伺服器軟體的訊息。這種格式的資訊洩漏,可以透過伺服器的組態來設定不顯示這些資訊公告(banner),或者是修改這些資訊公告,讓他看起來像是其他軟體的資訊公告。也有一些工具可以用來協助製造假造的資訊公告,像是IIS網站伺服器的URLScan以及Apache網站伺服器的mod_security。

  很不幸地,有很多工具可以在不取得網站伺服器資訊公告的狀況下來進行fingerprint,同時駭客現在甚至可以使用像是Google之類的搜尋引擎來進行fingerprint。這樣的攻擊方式被稱為Google hacking。(請參考資安人雜誌2006年4月號 “Google Hacking”一文來取得更多相關資訊。)

  透過Google的進階搜尋選項,駭客可以在不直接連線被攻擊目標的狀況下,從Google的快取來取得fingerprint的資訊。Google hacking也可以用來尋找可能存在弱點的網站。舉例來說,使用「allinurl:/隨機的資訊公告/index.cgi 」這樣的查詢條件,可以找到可能存在某種特定 CGI (Common Gateway Interface)腳本程式弱點的網站列表,而這個CGI也許可以用來存取網站伺服器上的任何檔案。

  你可以使用http://johnny.ihackstuff.com 網站上的Gooscan工具來了解駭客會在你的網站上發現什麼資訊,該網站也維護了Google Hacking Database。同時,你也可以查詢 http://www.google.com/webmasters 網站上的Google Webmasters FAQ(Google網站資源管理員問與答)─該網站提供如何保護你的網站資訊不當的被Google揭露的方法。

整體防護(Holistic protection)

  為了能夠有效的對抗網站應用程式攻擊,你需要進行整體防護;對付某一個弱點時,通常可以增強你另一個弱點的防護強度。應用程式安全策略的核心,應該是制訂出要求撰寫安全程式的政策,確保弱點的偵測和評估必須在任何應用程式發展或佈署的時候就被進行。

  第一個步驟就是先找出資料進入以及離開應用程式的位置,然後確保這些HTTP中的資料在被存取、執行腳本程式、組合成SQL命令之前,都有被檢驗過正確性、安全性。接下來,你必須再次檢視應用程式對於進出點的信任層級,並且定義清楚外部使用者權限,以及應用程式在系統中被賦予的權限。在此可分享一個很好經驗─利用資料流程圖來追蹤資料透過應用程式可能流向。如果系統或者應用程式發生任何錯誤,必須確定你的應用程式不會回應對駭客入侵有幫助的任何詳細錯誤資訊。

  網站應用程式本身必須在能正常運作下,使用最小需求的權限來執行。千萬不可以使用預設的帳號,像是SQL伺服器的SA帳號。還必須確保任何連線到資料庫,或者其他資源的連線也是使用最低權限(least-privileged)的帳號;你必須鎖定你的資料庫伺服器以及網站伺服器。移除不需要的資源,像是範例資料庫以及測試網頁,如同你對網站伺服器所做的監控,並備份你的資料庫伺服器。

  整體防護的程序中應該包含定期執行弱點掃描。現在許多的掃描器都已經自動化,其中許多工具的功能也包含掃描XSS弱點和進行Google hacks。SANS網站上http://www.sans.org/top20/2005/tools.pdf列出了許多的工具以及服務,幫忙IT人員找出並修復前20大弱點。

  如果使用第三方產品,像是訊息傳遞工具等,應該在安裝之前先確認廠商是否會釋放相關弱點資訊,並留意該產品安全通告,以及保持安裝到最新修補程式的狀態。甚至在佈署之初,你的網站應用程式已經是處於相對安全的狀態,但是經過系統架構的變更,或者組態設定的修改網站應用程式就無法一直保持在安全的狀態下。因此,為了讓安全政策可以有效和適宜就必須定期的重新檢視。

  防禦機制必須有一部份是檢視防火牆是否保持有效,像是封包過濾型防火牆,已經無法對網站應用程式提供足夠的保護能力。雖然佈署路由器以及網路層封包狀態過濾型防火牆可以保證只有被允許的通訊埠以及協定可以被使用,攻擊者就被強制僅能使用應用層所提供的命令和資料。而只有使用應用層防火牆,才能了解特定內容中所代表真正含意。發展事件處理計畫是很重要的;擁有詳細並經過沙盤推演的計畫可以幫助你有步驟的處理任何的攻擊行為,並且降低攻擊事件對網路所造成的衝擊到最小。

持續改進

  因為現在許多的應用程式與服務都已經是透過網際網路傳送,因此應用程式安全必須是被內建在組織的安全政策中。值得慶幸的,網站社群也正熱衷於協助增進網站應用程式安全的方法。

  網站應用程式安全聯合會( WASC , The Web Application Security Consortium)的網站安全威脅分類以及安全統計資料計畫,可以實際幫助應用程式發展者與安全人員了解這些弱點,進而增強應用程式開發過程,並且加快對於弱點的回應時間。同時,弱點分類可以用來評估網站應用程式流程中可能發生的威脅。

  除非以上的防護行為都被採用,否則網站應用程式會繼續是攻擊者最愛的攻擊方法之一。企業們應該隨時保持警戒,避免成為下一個犧牲者。

預防SQL Injection

  使用單引號注入是檢查你的網站是否有SQL Injection弱點的簡單方法:完成你網站上表單的資料輸入,但是在資料中增加單引號符號到輸入框格中。

  舉例來說,如果表單要求輸入使用者名稱,你可以輸入“John Doe.”。這樣的輸入可能會得到網站特殊的錯誤回應,類似 “Page Not Found,”,或者是得到可能包含以下字串“unhandled exception.”的SQL或程式執行錯誤訊息。如果網站會回應以上的狀況,那就代表你的網站很有可能有SQL injection的弱點,因為這樣的錯誤訊息表示使用者輸入資料並沒有被程式正確、適當的處理過。

  你應該驗證所有使用者輸入的資料,包含資料的類型、長度、格式、和範圍。並且也要清楚了解任何字元或字串是否可以被惡意的使用。過濾資料最好的方法是使用正規表示式(regular expression)來阻絕非定義內的資料。過濾必須是嚴謹的,僅允許應用程式所需要以及期望的資料類型。如果你期望程式會得到整數型態的資料,就檢查取得的資料是否是整數型態。如果資料不是整數型態,就拒絕這項資料。如同以下表單的範例,除非程式會驗證PIN號碼是否只由數字組成的,否則攻擊者就可能會注入「OR」命令到SQL查詢語句中,造成WHERE條件式永遠會得到true的回應。
 Logon Form
Name: False Name
PIN: 1234 OR 1=1

  舉例,SELECT * FROM users WHERE Name=''FalseName'' AND PIN=1234 OR 1=1. 這樣的命令將會允許攻擊者在不知道使用者名稱以及PIN號碼的狀況下也可以進行登入。

  千萬不要只使用一種檢查程式來檢查你整個網站的使用者輸入資料,因為不同的資料會需要不同的檢查方式。舉例來說,使用者名稱、密碼的檢查方式就會和ID號碼的檢查方式完全不同。所有資料檢查的程序都必須在可信任的伺服器上執行或者是在你應用程式的控制之下。你的應用程式千萬不能相信使用者端的資料驗證程序,因為使用者端的驗證機制可以很輕易的被跳過。使用者端的程式只能用來降低伺服器的負荷,以及增進使用者使用環境的體驗。
                       
   —MICHAEL COBB

資源和工具

開放網站應用程式安全計畫
Open Web Application Security Project (OWASP)
http://www.owasp.org/index.jsp

網站應用程式安全聯合會
The Web Application Security Consortium (WASC)
www.webappsec.org

IIS Lockdown工具
http://download.microsoft.com

Google網站資源管理員問與答
Google Webmasters FAQ
http://www.google.com/webmasters

SANS前20大弱點
SANS Top 20 Vulnerabilities
http://www.sans.org/top20/2005/tools.pdf


Michael Cobb,擁有 CISSP-ISSAP, MCDBA證照,是Cobweb Applications公司的創立人,亦是 IIS Security一書的共同作者。