Web Application核心防禦機制是什麼

為防止惡意輸入，應用程式實作了大量的安全機制，而這些安全機制在概念上都具有相似性。

這些安全機制由以下幾個面向組成：

1、處理使用者存取web應用程式的資料與功能（防止未授權存取）

2、處理使用者對web應用程式功能輸入的資料（防止建構惡意資料）

3、應對攻擊（處理預料外的報錯、自動阻止明顯的攻擊、自動向管理員發送警報、維護程式的存取日誌）

4、管理與維護應用程式

處理存取

通常一個應用程式的使用者有不同類型如，普通使用者、登入驗證使用者、管理員。對不同使用者web應用程式給予不同的權限，他們只能存取不同的資料與功能。

web應用程式是透過三層互相關聯的安全機制來處理使用者的存取：

1、驗證（Authentication）

#2、會話管理（Session Management）

3、存取控制（Access Control）

這三個機制處理使用者對應用程式的訪問，同時它也是三個受攻擊面（attack surface ）；而且這三者相互依賴缺一不可，無論哪個地方出了問題都會造成未授權訪問（木桶原理）。

身份驗證

身份驗證是處理用戶訪問的第一道機制，除非網站只有一種用戶，否則必須使用身份驗證。

如今web應用程式大都使用傳統身分驗證模型，即使用者名稱密碼。

在銀行等安全性較高的應用程式中會使用其他憑證、雙因素認證等來強化這個模型；在安全性要求更高的應用程式中可能需要客戶端憑證、智慧卡或詢問-應答機制等其他身份驗證模型。

身份驗證機制往往還需要一系列其他支援功能，如註冊、忘記密碼、修改密碼等。

身份驗證機制存在一些普遍的漏洞，如遍歷使用者名稱、弱口令、邏輯缺陷避開登入、社工庫查詢等等。

會話管理

通過驗證之後，就是管理使用者的會話了。為了實施存取控制，應用程式需要識別不同使用者提交的各種請求；為此，應用程式需要為每個使用者建立一個會話，並向使用者發送一個表示會話的令牌即session token。會話本身是保存在伺服器上的一組資料結構，用於追蹤使用者和應用程式的互動狀態。

會話令牌一般在cookie中傳遞，有時也會出現在隱藏表單欄位或url查詢字串上，會話令牌會在停止請求後一段時間內失效。

有些應用程式不使用會話令牌來識別會話，而是透過重複提交使用者憑證識別會話（http內建身分驗證機制就是這樣，透過重複提交透過base64加密的帳號密碼來識別會話）。在某些情況下會話資訊不會保存在伺服器上，而是保存在客戶端，為了防止使用者修改，一般會對其進行加密。

會話管理的受攻擊面就是會話令牌本身，推測出會話令牌的生成規則或截獲到其他使用者的會話令牌便可以以他人身分存取未經授權的功能與資料。

存取控制

如果前面的驗證與會話管理運作正常，應用程式便可透過每個要求中的會話令牌確認每個使用者的身分與互動狀態，所以便可決定是否同意用戶的請求。

因為典型存取控制的要求比較複雜，每個角色有不同的權限，每個使用者只允許存取應用程式中的一部分資料與功能，因此這個機制中一般存在大量漏洞，可以造成未授權存取。

處理輸入

所有的使用者輸入都不可信，大部分對web應用程式的攻擊都與攻擊者專門建構的輸入有關，所以安全的處理使用者的輸入是保障應用程序安全的關鍵。

輸入的多樣性

web應用程式可能會對一些特殊的輸入執行非常嚴格的檢查，例如長度限制、字元限制等；有時則可能需要接受使用者提交的任意輸入；而隱藏表單欄位和cookie等是在伺服器上產生傳回客戶端，再由使用者的請求傳回伺服器，在這個過程中攻擊者卻可以檢視並修改它們。

輸入處理方法

不同的情況使用不同的處理方法，或搭配使用。

1、黑名單

黑名單包含一組在攻擊中會使用的字串或模式，所有與黑名單相符的資料都會阻止。

黑名單是輸入確認效果最差的方法。原因有二：

1）使用者的輸入可以透過各種編碼或其他的表現形式來繞過，例如遺漏一些有相同作用的字元。例如alert('xss')被阻止,還可以使用prompt('xss')、例如web應用防火牆常受到空字節（null）攻擊，這是因為在託管與非託管情況下處理字串的方式不同。

2）術飛速的發展，使之產生一些新型的漏洞利用方法。

2、白名單

白名單包含一組良性的字串、模式或一組標準。所有不與白名單相符的資料都會被封鎖。

白名單是輸入確認效果最好的方法，因為指定白名單時只會留下安全的字串，攻擊者無法建構輸入。

但是白名單有其限制。在許多情況下web應用程式必須接受一些不符合安全標準的字符，例如應用程式需要用戶以真實姓名註冊，但姓名中卻包含一些連字符、撇號等可能對資料庫造成攻擊的字符。所以白名單有其局限性，並非解決不安全輸入的萬能方法。

3、淨化

這種方式解決了白名單無法處理的部分，它接受一些無法保證安全的資料輸入，但是會對其進行淨化，例如刪除、轉義、編碼等

淨化可以作為一種通用的方法，但是需要注意的是如果一個輸入項中需要容納幾種可能的惡意數據，就很能對其進行有效的進化。這時需要使用邊界確認。

4、安全資料處理

以不安全的方式處理使用者提交的數據，是許多web應用程式漏洞形成的根本原因。

安全的資料處理方式，不需要糾結於對使用者輸入資料的確認，轉而確保處理過程的絕對安全。例如防止sql注入的參數化查詢。

但這項方法不適用於web應用程式需要執行的每一項任務，如果適用，它就是處理惡意輸入的通用處理方法了。

5、邏輯檢查

在某些漏洞中攻擊者與正常使用者的輸入完全相同，僅僅是動機不同，在這種情況下，以上機制幾乎完全無效。例如攻擊這透過修改隱藏表單欄位提交的帳號，企圖存取其他使用者帳號。此時再多的輸入確認也無法區分攻擊者與正常使用者的資料。為防止未授權訪問，應用程式必須確認所提交帳號屬於先前提交該帳號的用戶。

邊界確認

鑑於核心安全性問題的本質（所有使用者輸入皆不可信），可以將因特網（不可信）與伺服器應用程式（可信任）之間作為邊界，然後在邊界淨化所有來自因特網的輸入，將淨化後的資料交給伺服器應用程式。以上，是一種簡單的邊界確認，在分析實際的漏洞時發現執行這種簡單的輸入確認是不夠的。

基於應用程式執行功能的廣泛性及其採用技術的多樣性，一個典型的應用程式需要防禦大量的各種各樣的輸入攻擊，每種攻擊可能採用一種截然不同的專門設計的數據，因此很難在外部邊界建立一個簡單的機制防禦所有的攻擊。

許多應用程式功能設計組合一系列不同的處理過程，使用者的一個輸入，可能在許多元件中執行許多操作，其中前一個操作的輸出結果被用於後一個操作。數據經過轉換後與原始輸入完全不同。而經驗豐富的攻擊者卻能利用這種不同，在關鍵步驟產生惡意數據，攻擊接受數據的元件。因此很難在外部邊界建立一個簡單的機制來防禦所有的攻擊。

邊界確認是一種更有效的模型。這裡的邊界不在局限於網際網路與web應用程式之間的邊界，web應用程式的每個元件或功能單元都有邊界。如此，每個組件都可以防禦它收到的特殊類型的專門設計的輸入。當資料通過不同的元件，即可對前面產生的資料執行確認檢查，而且由於不同的處理階段執行不同的確認檢查，它們之間不可能發生衝突。

例如下圖：

多步驟確認與標準化

在確認檢查過程中，當需要在幾個步驟中處理當使用者的輸入時，就會出現一個輸入機制常遇到的問題。當應用程式試圖透過刪除或編碼某些字元達到淨化使用者輸入時，就會出現這種問題。如果不謹慎處理這個問題，攻擊者就能建構專門的輸入，讓惡意資料成功避開確認機制。例如雙寫繞過、利用步驟執行順序繞過。

資料規範化會造成另一個問題。為了透過http傳送一些不常見的字元和二進位數據，通常會透過編碼對其進行規範化，但是如何在實施過濾之後才進行解碼，攻擊者就可以透過編碼避開確認機制。

除了供web應用程式使用的標準編碼方案外，其他情況下，如果應用程式的元件將資料從一個字元集轉換為另一個字元集，這也會導致規範化問題。例如Ÿ和Â則被轉換為Y和A，攻擊者經常使用這種方法傳送受阻止的字元和關鍵字。

有時很難避免多步驟確認和規範化造成的問題，也不存在解決和這類問題的唯一方案。如何可能一般避免淨化不良輸入，而是完全拒絕這種輸入。

應對攻擊

以上我們已經盡可能的阻止了攻擊者的入侵，但是沒有一個絕對安全的系統，若發生安全事件web應用程式應當如何應對攻擊呢，處理措施一般為以下幾條：

1、處理預料外的報錯

2、自動阻止明顯的攻擊

3、自動向管理員發送警報

4、維護程式的存取日誌

處理錯誤

應用程式的關鍵機制就是如何處理意料之外的錯誤。一般在生產環境下，應用程式不應該向使用者傳回任何系統產生的資訊或其他偵錯資訊。這些資訊對於攻擊者而言是為下一步的進攻提供了很好的參考資訊。而且意料之外的錯誤往往指明了程式的防衛機制中的一些缺陷。錯誤處理機制通常與日誌機制整合在一起。

應對攻擊

很多攻擊都會發送大量的常見惡意字符，遇到這類情況應用程式應採取自動反應措施阻止攻擊者的探查。例如終止會話、要求重新登入、禁止ip等等

維護日誌

#日誌會對入侵情況進行記錄，入侵過後仍能還原入侵過程。

重要的應用程式日誌應記錄所有請求。一般情況下應至少包含幾項：

1、所有與身分驗證相關的事件，如成功或失敗的登入、密碼修改

2、關鍵操作，如轉帳等

3、被存取控制阻止的請求

4、包含已知攻擊字串

日誌會記錄每個事件的時間、ip、用戶帳戶。日誌需要嚴格保護，避免未經授權的讀取。寫入，修改等等

日誌同樣也會成為一個攻擊面，例如可以未授權存取的日誌會為攻擊者提供會話令牌、請求參數等等敏感資訊。

向管理員發出警報

核心問題就是誤報和漏報，將警報機制與確認機制和其他控制方法結合起來可以得到一些改善。

一般而言監控到的反常事件包括以下幾種：

1、應用反常，如接收到一個ip的大量的請求

2、交易反常，如一個銀行帳戶所轉入轉出的資金數量出現異常

3、包含已知攻擊字串

4、請求中普通用戶無法查看的資料被修改

管理應用程式

管理程式可以幫助管理員管理使用者帳戶與角色、應用程式監控與稽核功能、執行診斷任務並配置應用程式的各種功能。

管理機制是應用程式主要受攻擊面之一，管理機制往往都擁有很高的權限。獲得了管理機制控制權，就是獲得了應用程式的控制權。而且管理機制中往往會存在一些比較明顯的漏洞和敏感的功能。取得管理員的權限的漏洞一般出現在處理使用者存取機制上，如未授權存取、弱口令等，如果管理後台可以處理一般使用者發送的請求，可以嘗試xss漏洞盲打後台。

以上是Web Application核心防禦機制是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！