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

一． 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.因為管理使用者被視為可信使用者，或者由于滲透測試員隻能通路低權限的賬戶，是以管理功能往往沒有經過嚴格的安全測試。而且，他通常需要執行相當危險的操作，包括通路磁盤上的檔案或作業系統的指令。如果一名攻擊者能夠攻破管理功能，就能利用它控制整個伺服器。