關於Web安全趨勢與核心防禦機制

Joker_Ye發表於2016-07-14

一. WEB安全技術產生原因

早期:全球資訊網(World Wide Web)僅有Web站點構成,這些站點基本上是包含靜態文件的資訊庫。這種資訊流僅由伺服器向瀏覽器單向傳送。多數站點並不驗證使用者的合法性。

如今:已與早期的全球資訊網已經完全不同,Web上的大多數站點實際上是應用程式。他們功能強大,在伺服器和瀏覽器之間進行雙向資訊傳送。他們處理的許多資訊屬於私密和高度敏感資訊。因此,安全問題至關重要,Web安全技術也應運而生。

 

二. Web程式常見漏洞

(1)不完善的身份驗證措施:這類漏洞包括應用程式登陸機制中的各種缺陷,可能會使攻擊者攻破保密性不強的密碼,發動蠻力攻擊或者完全避開登陸。

(2)不完善的訪問控制措施:這一問題涉及的情況包括:應用程式無法為資料和功能提供全面保護,攻擊者可以檢視其他使用者儲存在伺服器中的敏感資訊,或者執行特權操作。

(3)SQL隱碼攻擊:攻擊者可通過這一漏洞提交專門設計的輸入,干擾應用程式與後端資料庫的互動活動。攻擊者能夠從應用程式中提取任何資料、破壞邏輯結構,或者在資料庫伺服器上執行命令。

(4)跨站點指令碼:攻擊者可利用該漏洞攻擊應用程式的其他使用者、訪問其資訊、代表他們執行未授權操作,或者向其發動其他攻擊。

(5)資訊洩露:這一問題包括應用程式洩露敏感資訊,攻擊者利用這些敏感資訊通過有缺陷的錯誤處理或其他行為攻擊應用程式。

三. 核心安全問題

如今的Web程式的核心安全問題為:使用者可提交任意輸入。具體為:

(1)使用者可干預客戶與伺服器間傳送的所有資料,包括請求引數、cookie和HTTP資訊頭。

(2)使用者可按任何順序傳送請求。

(3)使用者並不限於僅使用一種Web瀏覽器訪問應用程式。大量各種各樣的工具可以協助攻擊Web應用程式,這些工具既可整合在瀏覽器中,也可獨立於瀏覽器運作。這些工具能夠提出普通瀏覽器無法提供的請求,並能夠迅速生成大量的請求,查詢和利用安全問題達到自己的目的。

四.目前針對Web安全問題提出的核心防禦機制

Web應用程式的基本安全問題(所有使用者輸入都不可信)致使應用程式實施大量安全機制來抵禦攻擊。儘管其設計細節與執行效率可能千差萬別,但幾乎所有應用程式採用的安全機制在概念上都具有相似性。

Web應用程式採用的防禦機制由以下幾個核心因素構成。

(1)處理使用者訪問應用程式的資料與功能,防止使用者獲得未授權訪問。

(2)處理使用者對應用程式功能的輸入,防止錯誤輸入造成不良行為。

(3)處理攻擊者,確保應用程式在成為直接攻擊目標時能夠正常運轉,並採取適當的防禦與攻擊措施挫敗攻擊者

(4)管理應用程式本身,幫助管理員監控其行為,配置其功能。

五.    理論具體措施

針對以上四種原因,還有一些理論做法:

5.1處理使用者訪問

幾乎任何應用程式都必須滿足一箇中心安全要求,即處理使用者訪問其資料與功能。大多數Web應用程式使用三層相互關聯的安全機制處理使用者訪問:

(1)身份驗證

(2)會話管理

(3)訪問控制

5.2處理使用者輸入

許多情況下,應用程式可能會對一些特殊的輸入實行非常嚴格的確認檢查。例如,提交給登陸功能的使用者名稱的最大長度為8個字元,且只能包含字母。

在其他情況下,應用程式必須接受更廣泛的輸入。例如,提交給個人資訊頁面的地址欄位可合法包含字母、數字、空格、連字元、撇號與其他字元。但是仍然可以對這個欄位實施有效的限制。例如,提交的資料不得超過某個適當的長度限制(如50個字元),並不得包含任何HTML標記(HTML mark-up)。

輸入處理的幾種方法:

(1)“拒絕已知的不良輸入”

(2)“接受已知的正常輸入”

(3)淨化輸入的資料:資料中可能存在的惡意字元被徹底刪除掉,只留下已知安全的字元,或者再進一步處理前對他們進行適當編碼或“轉義”。

(4)安全資料處理:以不安全的方式處理使用者提交的資料,是許多Web應用程式漏洞形成的根本原因。有些時候,可使用安全的程式設計方法避免常見問題。

(5)語法檢查:為防止未授權訪問,應用程式必須確認所提交的賬號屬於之前提交該賬號的使用者。

(6)邊界確認:伺服器端應用程式第一次收到使用者資料的地方是一個重要的信任邊界,應用程式需要在此採取措施防禦惡意輸入。

 

5.3邊界確認的必要性

當我們開始分析一些實際的漏洞時,執行這種簡單的輸入確認是不夠的,原因為:

(1)基於應用程式所執行功能的廣泛性以及所採用技術的多樣性,一個典型的應用程式需要防禦大量各種各樣的基於輸入的攻擊,且每種攻擊可能採用一組截然不同的專門設計的資料,因此,很難在外部邊界建立一個單獨的機制,防禦所有這些攻擊。

(2)許多應用程式功能都涉及組合一系列不同型別的處理過程。

(3)防禦不同型別的基於輸入的攻擊可能需要對相互矛盾的使用者輸入執行各種確認檢查。例如:防止跨站點指令碼攻擊可能需要將“>”字元HTML編碼為“>”,而防止命令注入攻擊則需要防止包含 & 與 ; 字元的輸入。有時候,想要在應用程式的外部邊界同時阻止所有型別的攻擊幾乎是不可能的事情。

 

邊界確認(boundary validation)是一種更加有效的模型。此時,伺服器端應用程式的每一個單獨的元件或功能單元將其輸入當做來自潛在惡意來源的輸入對待。除客戶與伺服器之間的外部邊界外,應用程式在上述每一個信任邊界上執行資料確認。這種模型為前面提出的問題提供了一個解決方案。每個元件都可能防禦它收到的特殊型別的專門設計的輸入。當資料通過不同的元件時,即可對前面轉換過程中生成的任意資料值執行確認檢查。而且,由於在不同的處理階段執行不同的確認檢查,他們之間不可能發生衝突。

 

5.4 多步確認與規範化

如為防禦某些跨站點指令碼攻擊,應用程式可能會從任何使用者提交的資料中刪除表示式:<script>,但攻擊者可通過應用以下輸入避開過濾器:<scr<script>ipt>。由於過濾無法遞迴執行,刪除被阻止的表示式後,表示式周圍的資料又合併在一起,重新建立惡意表示式。同樣,如果對使用者輸入執行幾個確認步驟,攻擊者就可以利用這些步驟的順序來避開過濾。例如,如果應用程式首先遞迴刪除指令碼標籤,然後刪除引號,就可以使用以下輸入避開確認檢查:<scri*ipt>。

資料規範化(data canonicalization)會造成另一個問題。當使用者瀏覽器送出輸入時,它可對這些輸入進行各種形式的編碼。之所以使用這些編碼方案,是為了能夠通過HTTP安全傳送不常見的字元與二進位制資料。規範化是指將資料轉換或解碼成一個常見字符集的過程。如果在實施輸入過濾之後才執行規範化,那麼攻擊者就可以通過使用編碼避開確認機制。例如,應用程式可能會從使用者輸入刪除撇號,以防止某些SQL隱碼攻擊。但是,如果應用程式隨後對淨化後的資料進行規範化,那麼攻擊者就可以使用URL編碼的輸入避開確認。

有時候可能很難避免多步確認與規範化造成的問題,也不存在解決這類問題的唯一方案。

一種解決方法是遞迴執行淨化操作,直到無法進一步修改輸入。如果可能,最好避免清除某些不良輸入的做法,完全拒絕這種型別的輸入。

 

5.5  處理攻擊者

為處理攻擊者而採取的措施一般由以下任務組成:

(1)處理錯誤

(2)維護審計日誌

(3)向管理員發出警報

(4)應對攻擊

 

5.6  處理錯誤

應用程式的一個關鍵防禦機制是合理地處理無法預料的錯誤,要麼糾正這些錯誤,要麼向使用者傳送適當的錯誤訊息。再生產環境下,應用程式不應在其響應中返回任何系統生成的訊息或其他除錯資訊。過於詳細的錯誤訊息非常有利於惡意使用者嚮應用程式發動進一步攻擊。有些情況下,攻擊者能夠利用存在的缺陷的錯誤處理方法從錯誤訊息中獲得敏感資訊;此時,錯誤訊息成為攻擊者從應用程式中竊取資料的重要渠道。

大多數Web開發語言通過Try-catch塊和受查異常提供良好的錯誤處理支援。應用程式程式碼應廣泛使用這些方法查明特殊與常規錯誤,並作出相應處理。而且,還可以配置大多數應用程式伺服器,使其以自定義的方式處理無法處理的應用程式錯誤,如提供不包含太多資訊的錯誤訊息。

 

5.7  維護審計日誌

審計日誌(audit log)在調查針對應用程式的入侵嘗試時會發揮很大作用。發生入侵後,有效的審計日誌功能能夠幫助應用程式所有者瞭解實際發生的情況。

在任何注重安全的應用程式中,日誌應記錄所有重要事件。一般這些事件應至少包括以下幾項。

(1)所有與身份驗證功能有關的事件,如成功或失敗的登入、密碼修改。

(2)關鍵交易,如信用卡支付與轉賬

(3)任何包含已知攻擊字串,公然表明惡意意圖的請求。

 

5.8  向管理員發出警報

審計日誌可幫助應用程式所有者調查入侵企圖,如有可能,應對侵入者採取法律行動。警報監控的反常事件一般包括以下幾點:

(1)應用反常,如收到由單獨一個IP地址或使用者發出大量請求,表明應用程式正受到自定義攻擊

(2)交易反常:如單獨一個銀行賬戶轉入或轉出的資金數量出現異常

(3)包含已知攻擊字串的請求

(4)請求中普通使用者無法檢視的資料被修改。

 

5.9  管理應用程式

許多應用程式一般通過相同的Web介面在內部執行管理功能,這也是它的核心非安全功能,在這種情況下,管理機制就成為應用程式的主要受攻擊面。它吸引攻擊者的地方主要在於它能提升許可權,舉例說明:

1.身份驗證機制存在的薄弱環節使得攻擊者能夠獲得管理員許可權,迅速攻破整個應用程式。

2.許多應用程式並不對它的一些管理功能執行有效的訪問控制。利用這個漏洞,攻擊者可以建立一個擁有強大特權的新使用者賬戶。

3.管理功能通常能夠顯示普通使用者提供的資料。介面中存在的任何跨站點指令碼缺陷都可能危及使用者會話的安全

4.因為管理使用者被視為可信使用者,或者由於滲透測試員只能訪問低許可權的賬戶,所以管理功能往往沒有經過嚴格的安全測試。而且,他通常需要執行相當危險的操作,包括訪問磁碟上的檔案或作業系統的命令。如果一名攻擊者能夠攻破管理功能,就能利用它控制整個伺服器。

相關文章