今天就跟大家聊聊有關(guān)Web Application核心防御機制是什么,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
創(chuàng)新互聯(lián)成立與2013年,先為城口等服務(wù)建站,城口等地企業(yè),進行企業(yè)商務(wù)咨詢服務(wù)。為城口企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
為防止惡意輸入,應(yīng)用程序?qū)嵤┝舜罅康陌踩珯C制,而這些安全機制在概念上都具有相似性。
這些安全機制由以下幾個方面組成:
1、處理用戶訪問web應(yīng)用程序的數(shù)據(jù)與功能(防止未授權(quán)訪問)
2、處理用戶對web應(yīng)用程序功能輸入的數(shù)據(jù)(防止構(gòu)造惡意數(shù)據(jù))
3、應(yīng)對攻擊(處理預(yù)料外的報錯、自動阻止明顯的攻擊、自動向管理員發(fā)送警報、維護程序的訪問日志)
4、管理與維護應(yīng)用程序
通常一個應(yīng)用程序的用戶有不同類型如,普通用戶、登錄驗證用戶、管理員。對不同用戶web應(yīng)用程序給予不同的權(quán)限,他們只能訪問不同的數(shù)據(jù)與功能。
web應(yīng)用程序是通過三層互相關(guān)聯(lián)的安全機制來處理用戶的訪問:
1、身份驗證(Authentication)
2、會話管理(Session Management)
3、訪問控制(Access Control)
這三個機制處理用戶對應(yīng)用程序的訪問,同時它也是三個受攻擊面(attack surface);而且這三者相互依賴缺一不可,無論哪個地方出了問題都會造成未授權(quán)訪問(木桶原理)。
身份驗證是處理用戶訪問的第一道機制,除非網(wǎng)站只有一種用戶,否則必須使用身份驗證。
如今web應(yīng)用程序大都使用傳統(tǒng)身份驗證模型,即用戶名密碼。
在銀行等安全性較高的應(yīng)用程序中會使用其他證書、雙因素認證等來強化這個模型;在安全性要求更高的應(yīng)用程序中可能需要客戶端證書、智能卡或詢問-應(yīng)答機制等其他身份驗證模型。
身份驗證機制往往還需要一系列其他支持功能,如注冊、忘記密碼、修改密碼等。
身份驗證機制存在一些普遍的漏洞,如遍歷用戶名、弱口令、邏輯缺陷避開登錄、社工庫查詢等等。
通過驗證之后,就是管理用戶的會話了。為了實施訪問控制,應(yīng)用程序需要識別不同用戶提交的各種請求;為此,應(yīng)用程序需要為每個用戶建立一個會話,并向用戶發(fā)送一個表示會話的令牌即session token。會話本身是保存在服務(wù)器上的一組數(shù)據(jù)結(jié)構(gòu),用于追蹤用戶和應(yīng)用程序的交互狀態(tài)。
會話令牌一般在cookie中傳遞,有時也會出現(xiàn)在隱藏表單字段或者url查詢字符串上,會話令牌會在停止請求后一段時間內(nèi)失效。
有些應(yīng)用程序不使用會話令牌來識別會話,而是通過反復(fù)提交用戶證書識別會話(http內(nèi)置身份驗證機制就是這樣,通過反復(fù)提交通過base64加密的賬號密碼來識別會話)。在一些情況下會話信息不保存在服務(wù)器上,而是保存在客戶端,為了防止用戶修改,一般會對其進行加密。
會話管理的受攻擊面就是會話令牌本身,推測出會話令牌的生成規(guī)則或者截獲到其他用戶的會話令牌便可以以他人身份訪問未經(jīng)授權(quán)的功能與數(shù)據(jù)。
如果前面的身份驗證與會話管理運行正常,應(yīng)用程序便可以通過每個請求中的會話令牌確認每個用戶的身份與交互狀態(tài),于是便可決定是否同意用戶的請求。
因為典型訪問控制的要求比較復(fù)雜,每個角色有不同的權(quán)限,每個用戶只允許訪問應(yīng)用程序中的一部分數(shù)據(jù)與功能,因此這個機制中一般存在大量漏洞,可以造成未授權(quán)訪問。
所有的用戶輸入都不可信,大部分對web應(yīng)用程序的攻擊都與攻擊者專門構(gòu)造的輸入有關(guān),所以安全的處理用戶的輸入是保障應(yīng)用程序安全的關(guān)鍵。
web應(yīng)用程序可能對一些特殊的輸入執(zhí)行非常嚴格的檢查,例如長度限制、字符限制等;有時候則可能需要接受用戶提交的任意輸入;而隱藏表單字段和cookie等是在服務(wù)器上生成傳回客戶端,再由用戶的請求傳回服務(wù)器,在這個過程中攻擊者卻可以查看并修改它們。
不同的情況使用不同的處理方法,或者搭配使用。
1、黑名單
黑名單包含一組在攻擊中會使用的字符串或模式,所有與黑名單匹配的數(shù)據(jù)都會阻止。
黑名單是輸入確認效果最差的方法。原因有二:
1)用戶的輸入可以通過各種編碼或者其他的表現(xiàn)形式進行繞過,比如遺漏一些有相同作用的字符。例如alert(‘xss’)被阻止,還可以使用prompt(‘xss’)、例如web應(yīng)用防火墻常受到空字節(jié)(null)攻擊,這是因為在托管與非托管情況下處理字符串的方式不同。
2)術(shù)飛速的發(fā)展,使之產(chǎn)生一些新型的漏洞利用方法。
2、白名單
白名單包含一組良性的字符串、模式或一組標準。所有不與白名單匹配的數(shù)據(jù)都會被阻止。
白名單是輸入確認效果最好的方法,因為指定白名單時只會留下安全的字符串,攻擊者無法構(gòu)造輸入。
但是白名單具有局限性。在許多情況下web應(yīng)用程序必須接受一些不符合安全標準的字符,例如應(yīng)用程序需要用戶以真實姓名注冊,但是姓名中卻包含一些連字符、撇號等可能對數(shù)據(jù)庫造成攻擊的字符。所以白名單具有局限性,并非解決不安全輸入的萬能方法。
3、凈化
這種方式解決了白名單無法處理的部分,它接受一些無法保證安全的數(shù)據(jù)輸入,但是會對其進行凈化,例如刪除、轉(zhuǎn)義、編碼等
凈化可以作為一種通用的方法,但是需要注意的是如果一個輸入項中需要容納幾種可能的惡意數(shù)據(jù),就很能對其進行有效的進化。這時需要使用邊界確認。
4、安全數(shù)據(jù)處理
以不安全的方式處理用戶提交的數(shù)據(jù),是許多web應(yīng)用程序漏洞形成的根本原因。
安全的數(shù)據(jù)處理方式,不需要糾結(jié)于對用戶輸入數(shù)據(jù)的確認,轉(zhuǎn)而確保處理過程的絕對安全。例如防止sql注入的參數(shù)化查詢。
但是這項方法不適用于web應(yīng)用程序需要執(zhí)行的每一項任務(wù),如果適用,它就是處理惡意輸入的通用處理方法了。
5、邏輯檢查
在一些漏洞中攻擊者與正常用戶的輸入完全相同,僅僅是動機不同,在這種情況下,以上機制幾乎完全無效。例如攻擊這通過修改隱藏表單字段提交的賬號,企圖訪問其他用戶賬號。此時再多的輸入確認也無法區(qū)別攻擊者與正常用戶的數(shù)據(jù)。為防止未授權(quán)訪問,應(yīng)用程序必須確認所提交賬號屬于之前提交該賬號的用戶。
鑒于核心安全問題的本質(zhì)(所有用戶輸入皆不可信),可以將因特網(wǎng)(不可信)與服務(wù)器應(yīng)用程序(可信)之間作為邊界,然后在邊界凈化所有來自因特網(wǎng)的輸入,將凈化后的數(shù)據(jù)交給服務(wù)器應(yīng)用程序。以上,是一種簡單的邊界確認,在分析實際的漏洞時發(fā)現(xiàn)執(zhí)行這種簡單的輸入確認是不夠的。
基于應(yīng)用程序執(zhí)行功能的廣泛性及其采用技術(shù)的多樣性,一個典型的應(yīng)用程序需要防御大量的各種各樣的輸入攻擊,每種攻擊可能采用一種截然不同的專門設(shè)計的數(shù)據(jù),因此很難在外部邊界建立一個簡單的機制防御所有的攻擊。
許多應(yīng)用程序功能都設(shè)計組合一系列不同的處理過程,用戶的一個輸入,可能在許多組件中執(zhí)行許多操作,其中前一個操作的輸出結(jié)果被用于后一個操作。數(shù)據(jù)經(jīng)過轉(zhuǎn)換后與原始輸入完全不同。而經(jīng)驗豐富的攻擊者卻能利用這種不同,在關(guān)鍵步驟生成惡意數(shù)據(jù),攻擊接受數(shù)據(jù)的組件。因此很難在外部邊界建立一個簡單的機制防御所有的攻擊。
邊界確認是一種更加有效的模型。這里的邊界不在局限于因特網(wǎng)與web應(yīng)用程序之間的邊界,web應(yīng)用程序的每個組件或功能單元都有邊界。如此,每個組件都可以防御它收到的特殊類型的專門設(shè)計的輸入。當數(shù)據(jù)通過不同的組件,即可對前面生成的數(shù)據(jù)執(zhí)行確認檢查,而且由于不同的處理階段執(zhí)行不同的確認檢查,它們之間不可能發(fā)生沖突。
例如下圖:
在確認檢查過程中,當需要在幾個步驟中處理用戶的輸入時,就會出現(xiàn)一個輸入機制經(jīng)常遇到的問題。當應(yīng)用程序試圖通過刪除或者編碼某些字符達到凈化用戶輸入時,就會出現(xiàn)這種問題。如果不謹慎處理這個問題,攻擊者就能構(gòu)造專門的輸入,使惡意數(shù)據(jù)成功避開確認機制。例如雙寫繞過、利用步驟執(zhí)行順序繞過。
數(shù)據(jù)規(guī)范化會造成另一個問題。為了通過http傳送一些不常見的字符和二進制數(shù)據(jù),通常會通過編碼對其進行規(guī)范化,但是如何在實施過濾之后才進行解碼,攻擊者就可以通過編碼避開確認機制。
除了供web應(yīng)用程序使用的標準編碼方案外,其他情況下,如果應(yīng)用程序的組件將數(shù)據(jù)從一個字符集轉(zhuǎn)換為另一個字符集,這也會導(dǎo)致規(guī)范化問題。例如?和?則被轉(zhuǎn)換為Y和A,攻擊者經(jīng)常使用這種方法傳送受阻止的字符和關(guān)鍵字。
有時候很難避免多步確認和規(guī)范化造成的問題,也不存在解決和這類問題的唯一方案。如何可能一般避免凈化不良輸入,而是完全拒絕這種輸入。
以上我們已經(jīng)盡可能的阻止了攻擊者的入侵,但是沒有一個絕對安全的系統(tǒng),若發(fā)生安全事件web應(yīng)用程序應(yīng)當如何應(yīng)對攻擊呢,處理措施一般為以下幾條:
1、處理預(yù)料外的報錯
2、自動阻止明顯的攻擊
3、自動向管理員發(fā)送警報
4、維護程序的訪問日志
處理錯誤
應(yīng)用程序的一個關(guān)鍵機制就是如何處理意料之外的錯誤。一般在生產(chǎn)環(huán)境下,應(yīng)用程序不應(yīng)該向用戶返回任何系統(tǒng)生成的信息或者其他調(diào)試信息。這些信息對于攻擊者而言是為下一步的進攻提供了很好的參考信息。而且意料之外的錯誤往往指明了程序的防御機制中的一些缺陷。錯誤處理機制通常與日志機制整合在一起。
應(yīng)對攻擊
很多攻擊都會發(fā)送大量的常見惡意字符,遇到這類情況應(yīng)用程序應(yīng)采取自動反應(yīng)措施阻止攻擊者的探查。例如終止會話、要求重新登錄、禁止ip等等
維護日志
日志會對入侵情況進行記錄,入侵過后仍能還原入侵過程。
重要的應(yīng)用程序日志應(yīng)記錄所有請求。一般情況下應(yīng)至少包括一下幾項:
1、所有與身份驗證相關(guān)的事件,如成功或失敗的登錄、密碼修改
2、關(guān)鍵操作,如轉(zhuǎn)賬等
3、被訪問控制阻止的請求
4、包含已知攻擊字符串
日志會記錄每個事件的時間、ip、用戶賬戶。日志需要嚴格保護,避免未授權(quán)的讀取。寫入,修改等等
日志同樣也會成為一個攻擊面,例如可以未授權(quán)訪問的日志會為攻擊者提供會話令牌、請求參數(shù)等等敏感信息。
向管理員發(fā)出警報
核心問題就是誤報和漏報,將警報機制與確認機制和其他控制方法結(jié)合起來可以得到一些改善。
一般而言監(jiān)控到的反常事件包括以下幾種:
1、應(yīng)用反常,如接收到一個ip的大量的請求
2、交易反常,如一個銀行賬戶所轉(zhuǎn)入轉(zhuǎn)出的資金數(shù)量出現(xiàn)異常
3、包含已知攻擊字符串
4、請求中普通用戶無法查看的數(shù)據(jù)被修改
管理程序可以幫助管理員管理用戶賬戶與角色、應(yīng)用監(jiān)控與審計功能、執(zhí)行診斷任務(wù)并配置應(yīng)用程序的各種功能。
管理機制是應(yīng)用程序主要受攻擊面之一,管理機制往往都擁有很高的權(quán)限。獲得了管理機制控制權(quán),就是獲得了應(yīng)用程序的控制權(quán)。而且管理機制中往往會存在一些比較明顯的漏洞和敏感的功能。獲得管理員的權(quán)限的漏洞一般出現(xiàn)在處理用戶訪問機制上,如未授權(quán)訪問、弱口令等,如果管理后臺可以處理普通用戶發(fā)送的請求,可以嘗試xss漏洞盲打后臺。
看完上述內(nèi)容,你們對Web Application核心防御機制是什么有進一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝大家的支持。
新聞名稱:WebApplication核心防御機制是什么
文章位置:http://jinyejixie.com/article28/pocpcp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供App設(shè)計、建站公司、面包屑導(dǎo)航、服務(wù)器托管、定制網(wǎng)站、域名注冊
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)