Web安全趨勢與核心防護機制

Web安全趨勢與核心防護機制

                  孟飛陽        2012年1月16日

一． 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.由於管理用戶被視爲可信用戶，或者因爲滲透測試員只能訪問低權限的帳戶，因此管理功能每每沒有通過嚴格的安全測試。並且，他一般須要執行至關危險的操做，包括訪問磁盤上的文件或操做系統的命令。若是一名攻擊者可以攻破管理功能，就能利用它控制整個服務器。