背 景

隨著互聯(lián)網(wǎng)的迅猛發(fā)展，HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）已經(jīng)成為網(wǎng)頁傳輸?shù)幕A(chǔ)協(xié)議。它在客戶端（如瀏覽器）和服務(wù)器之間傳遞信息，使得我們能夠?yàn)g覽網(wǎng)頁、提交表單、下載文件等。然而，HTTP 的普及也使其成為黑客攻擊的主要目標(biāo)之一。HTTP 協(xié)議本身是無狀態(tài)的，這種特性雖然簡化了網(wǎng)絡(luò)通信，但也帶來了不少安全隱患。

網(wǎng)絡(luò)安全攻擊利用了 HTTP 協(xié)議的各種漏洞和特性，試圖在數(shù)據(jù)傳輸過程中獲取未授權(quán)的信息、操縱數(shù)據(jù)、擾亂服務(wù)甚至竊取敏感信息。這些攻擊不僅對用戶隱私構(gòu)成威脅，還可能導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損失和聲譽(yù)損害。因此，了解和防范 HTTP 網(wǎng)絡(luò)安全攻擊顯得尤為重要。

02

HTTP協(xié)議介紹

2.1 HTTP協(xié)議概念

HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）[1]是萬維網(wǎng)（World Wide Web）的核心協(xié)議之一。HTTP協(xié)議初期運(yùn)行在TCP/IP協(xié)議之上，后期運(yùn)行在QUIC協(xié)議之上，是應(yīng)用層協(xié)議。它定義了客戶端（如瀏覽器）和服務(wù)器之間如何傳輸文本、圖像、視頻及其他多媒體內(nèi)容。同時(shí)，也是一種客戶端-服務(wù)端（client-server）協(xié)議，也就是說，請求是由接收方—通常是瀏覽器發(fā)起的，客戶端與服務(wù)端之間通過交換一個(gè)個(gè)獨(dú)立的消息（而非數(shù)據(jù)流）進(jìn)行通信。由客戶端——通常是個(gè)瀏覽器——發(fā)出的消息被稱作請求（request），由服務(wù)端發(fā)出的應(yīng)答消息被稱作響應(yīng)（response）。

圖1

2.2 HTTP協(xié)議報(bào)文格式

HTTP 報(bào)文是面向文本的，報(bào)文中的每個(gè)字段都是一些ASCII碼串，各個(gè)字段的長度是不確定的。HTTP 有兩類報(bào)文：請求報(bào)文和響應(yīng)報(bào)文。

圖2 HTTP請求報(bào)文

HTTP 請求報(bào)文由以下內(nèi)容組成：

◆ 請求行

   · 請求方法

   · 請求URL

   · HTTP協(xié)議版本

◆ 請求頭部：請求頭部包含了多個(gè)頭字段，每個(gè)字段包含一個(gè)名稱和一個(gè)值，用于傳遞客戶端的額外信息和指示。每個(gè)頭字段占一行。

◆ 空行：空行用于分隔請求頭部和請求主體。它僅包含回車符和換行符（CRLF），即 \r\n。

◆ 請求主體：請求主體包含了實(shí)際發(fā)送的數(shù)據(jù)，僅在某些方法（如 POST、PUT）中存在。它可以是任意二進(jìn)制數(shù)據(jù)或文本數(shù)據(jù)，格式?jīng)]有固定要求。

圖3 HTTP響應(yīng)報(bào)文

HTTP響應(yīng)報(bào)文由以下內(nèi)容組成：

◆ 狀態(tài)行

   · HTTP協(xié)議版本

   · 狀態(tài)碼

   · 狀態(tài)短語

◆ 響應(yīng)頭部：響應(yīng)頭部包含了多個(gè)頭字段，每個(gè)字段包含一個(gè)名稱和一個(gè)值，用于傳遞服務(wù)器的額外信息和指示。每個(gè)頭字段占一行。

◆ 空行：空行用于分隔響應(yīng)頭部和響應(yīng)主體。它僅包含回車符和換行符（CRLF），即 \r\n。

2.3 HTTP協(xié)議發(fā)展

HTTP/1.0（于1996年發(fā)布）最初是由Tim Berners-Lee[2]在1989年提出，是“無狀態(tài)”的：每個(gè)客戶端的新請求都建立了一個(gè)新連接，而不是通過特定客戶端和服務(wù)器之間的相同連接處理所有類似的請求。

HTTP/1.1（于1997年發(fā)布）包括持久連接、客戶端瀏覽器對HTML文件的解壓縮，以及多個(gè)域名共享相同的IP地址。

HTTP/2（于2015年發(fā)布）旨在解決網(wǎng)頁加載緩慢的問題，并且是一種二進(jìn)制協(xié)議，其中使用二進(jìn)制值而不是像以前版本中那樣使用純文本。

HTTP/3 （于2020年發(fā)布）依賴于更快的QUIC協(xié)議而不是TCP，受大多數(shù)瀏覽器支持。

2.4 HTTP協(xié)議性質(zhì)

（1）無狀態(tài)

HTTP是一個(gè)基于請求-響應(yīng)模型的無狀態(tài)協(xié)議。無狀態(tài)意味著每個(gè)請求都是獨(dú)立的，服務(wù)器不會(huì)保留之前請求的狀態(tài)信息。這種設(shè)計(jì)雖然簡化了協(xié)議，但也需要引入額外的機(jī)制來維護(hù)狀態(tài)，如cookies、sessions等。

（2）無連接

HTTP 是一種無連接協(xié)議。每次請求和響應(yīng)都通過獨(dú)立的連接完成，服務(wù)器處理完請求后即關(guān)閉連接。這種特性簡化了服務(wù)器設(shè)計(jì)，但也帶來了連接頻繁創(chuàng)建和關(guān)閉的開銷。

（3）靈活性

HTTP 可以傳輸任意類型的數(shù)據(jù)，只要兩端能處理數(shù)據(jù)的內(nèi)容類型。通過MIME類型（Content-Type）進(jìn)行標(biāo)識(shí)和處理。例如，文本數(shù)據(jù)可以是 HTML、JSON、XML 等，二進(jìn)制數(shù)據(jù)可以是圖像、視頻、應(yīng)用程序數(shù)據(jù)等。

（4）可擴(kuò)展性

HTTP 協(xié)議支持通過添加新的方法、頭字段來擴(kuò)展功能。例如，HTTP/1.1 引入了許多新的頭字段和方法，HTTP/2 和 HTTP/3 引入了更多優(yōu)化和功能改進(jìn)。

03

常見攻擊方式

3.1 SQL Injection（SQL 注入）

原理：SQL注入[3]是一種將惡意代碼插入到程序SQL語句中，從而誤導(dǎo)數(shù)據(jù)庫執(zhí)行惡意邏輯的攻擊技術(shù)。通過SQL注入，攻擊者可以達(dá)到獲取敏感信息，竊取訪問權(quán)限等目的。

比如后端有SQL如下，需要前端傳入一個(gè)id值，以進(jìn)行信息查詢:

SELECT * FROM `MyTable` WHERE `id`="{0}"

而此時(shí)，如果前端傳入“1” OR TRUE。后端沒有校驗(yàn)便傳入?yún)?shù)值并對SQL進(jìn)行拼接。那么直接拼接的SQL為：

SELECT * FROM `MyTable` WHERE `id`="1" OR TRUE

此時(shí)將所有數(shù)據(jù)全部取出。如果后端SQL是DELETE，影響更是不可估量。

防范：SQL 注入得以實(shí)施的因素是：網(wǎng)頁應(yīng)用使用 SQL 來控制數(shù)據(jù)庫，用戶傳入的數(shù)據(jù)直接被寫入數(shù)據(jù)庫。因此，防御 SQL 注入的關(guān)鍵在于：永遠(yuǎn)不要相信用戶的輸入；

在此理念的指導(dǎo)下，對于用戶提交的輸入信息，我們需要進(jìn)行充分的校驗(yàn)，避免其對后端服務(wù)系統(tǒng)造成攻擊。相關(guān)手段可以是正則式檢驗(yàn)參數(shù)合法性、html元素校驗(yàn)、SQL元素校驗(yàn)，對用戶輸入的內(nèi)容進(jìn)行轉(zhuǎn)義（escape）處理，不讓特殊符號(hào)破壞SQL語句的原本結(jié)構(gòu)等，并且可以在前端/后端執(zhí)行。

如果校驗(yàn)邏輯在前端執(zhí)行，確實(shí)不會(huì)對后端性能造成影響，但對于有經(jīng)驗(yàn)的攻擊者，可以修改前端代碼，此屏障就形同虛設(shè)；而如果在后端進(jìn)行校驗(yàn)，多少會(huì)損耗后端性能，如果校驗(yàn)算法比較復(fù)雜耗時(shí)，也許又會(huì)成為攻擊者的另一個(gè)攻擊點(diǎn)。

根據(jù) OWASP，下面看看具體的預(yù)防措施：

◆ Prepared Statements(with Parameterized Queries)： 參數(shù)化的查詢語句可以強(qiáng)制應(yīng)用開發(fā)者首先定義所有的sql代碼，之后再將每個(gè)參數(shù)傳遞給查詢語句。

◆ Stored Procedures：使用語言自帶的存儲(chǔ)程序，而不是自己直接操縱數(shù)據(jù)庫。

◆ White List Input Validation：驗(yàn)證用戶的輸入。

3.2 Distributed Denial of Service（DDoS，分布式拒絕服務(wù)）

原理：HTTP DDoS攻擊[4]是一種特定類型的DDoS攻擊，旨在通過大量HTTP請求淹沒目標(biāo)Web服務(wù)器，使其無法正常處理合法用戶的請求?？傮w而言，DDoS 攻擊好比高速公路發(fā)生交通堵塞，妨礙常規(guī)車輛抵達(dá)預(yù)定目的地。

大致分為以下幾類：

◆ HTTP Flood攻擊：攻擊者通過發(fā)送大量合法的HTTP GET或POST請求來耗盡目標(biāo)服務(wù)器的資源，如CPU、內(nèi)存和帶寬。GET請求通常用于獲取資源（如網(wǎng)頁、圖片等），而POST請求則用于提交數(shù)據(jù)（如表單數(shù)據(jù)）。

◆ Slowloris攻擊：這種類型的攻擊更多是面向連接層面，以基于線程的Web服務(wù)器為目標(biāo)，通過慢速請求來捆綁每個(gè)服務(wù)器線程，從而消耗服務(wù)器的線程&連接資源。攻擊者與服務(wù)器建立大量連接，每個(gè)連接只發(fā)送部分請求頭，并在接近超時(shí)之前繼續(xù)發(fā)送更多的頭部數(shù)據(jù)，從而保持連接活躍。

◆ Large Payload POST requests攻擊：一般通過POST方法發(fā)送容量大、結(jié)構(gòu)復(fù)雜的請求體到目標(biāo)服務(wù)器，使得目標(biāo)服務(wù)器在解析這些請求內(nèi)容的過程發(fā)生過載(CPU或內(nèi)存)；攻擊者通過構(gòu)造特定的序列化請求體，如xml、json等，在服務(wù)端執(zhí)行反序列化操作時(shí)引起服務(wù)過載。

◆ HTTP請求隨機(jī)化攻擊：攻擊者使用各種隨機(jī)化技術(shù)，改變User-Agent頭、Referer頭、URL參數(shù)等，使請求難以被簡單地識(shí)別和過濾，使每個(gè)HTTP請求看起來都是唯一的，從而繞過基于簽名的防御機(jī)制。

DDoS攻擊一般會(huì)根據(jù)攻擊目標(biāo)的情況，針對性的把技術(shù)手法混合，以達(dá)到最低的成本最難防御的目的，并且可以進(jìn)行合理的節(jié)奏控制，以及隱藏保護(hù)攻擊資源。

防范：

◆ Web應(yīng)用防火墻（WAF）：過濾和阻止惡意HTTP請求。

◆ CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）：使用CDN將流量分散到多個(gè)節(jié)點(diǎn)，提高整體抗攻擊能力。

◆ 流量清洗服務(wù)：使用專門的DDoS防護(hù)服務(wù)來識(shí)別和清洗惡意流量。

3.3 Cross Site Script（XSS， 跨站腳本攻擊)

原理：XSS是一種安全漏洞。攻擊者可以利用這種漏洞在網(wǎng)站上注入惡意的客戶端代碼。當(dāng)受害者運(yùn)行這些惡意代碼時(shí)，攻擊者就可以突破網(wǎng)站的訪問限制并冒充受害者。根據(jù)開放式Web應(yīng)用安全項(xiàng)目（OWASP）的數(shù)據(jù)，XSS是 2017年第七名[5]最常見的Web應(yīng)用程序漏洞。

如果 Web 應(yīng)用程序沒有部署足夠的安全驗(yàn)證，那么，這些攻擊很容易成功。瀏覽器無法探測到這些惡意腳本是不可信的，所以，這些腳本可以任意讀取cookie、session token，或者其他敏感的網(wǎng)站信息，或者讓惡意腳本重寫HTML內(nèi)容。

大致分為以下幾類：

◆ 存儲(chǔ)XSS：注入的腳本永久的存在于目標(biāo)服務(wù)器上，每當(dāng)受害者向服務(wù)器請求此數(shù)據(jù)時(shí)就會(huì)重新喚醒攻擊腳本。

◆ 反射型XSS：當(dāng)用受害者被引誘點(diǎn)擊一個(gè)惡意鏈接，提交一個(gè)偽造的表單，惡意代碼便會(huì)和正常返回?cái)?shù)據(jù)一起作為響應(yīng)發(fā)送到受害者的瀏覽器，從而騙過了瀏覽器，使之誤以為惡意腳本來自于可信的服務(wù)器，以至于讓惡意腳本得以執(zhí)行。

◆ DOM型XSS：有點(diǎn)類似于存儲(chǔ)型XSS，但存儲(chǔ)型XSS是將惡意腳本作為數(shù)據(jù)存儲(chǔ)在服務(wù)器中，每個(gè)調(diào)用數(shù)據(jù)的用戶都會(huì)受到攻擊。但DOM型XSS則是一個(gè)本地的行為，更多是本地更新DOM時(shí)導(dǎo)致了惡意腳本執(zhí)行。

防范：

◆ 輸入驗(yàn)證：從客戶端和服務(wù)器端雙重驗(yàn)證所有的輸入數(shù)據(jù)，這一般能阻擋大部分注入的腳本。

3.4 Cross Site Request Forgery(CSRF，跨站請求偽造)

原理：CSRF攻擊[6]是一種利用用戶在已登錄網(wǎng)站上的身份來偽造用戶請求的攻擊方式，造成用戶數(shù)據(jù)的損失或網(wǎng)絡(luò)安全的風(fēng)險(xiǎn)。也是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

CSRF 攻擊一般是攻擊者通過某些手段，偽造用戶請求，讓用戶在不知情的情況下，達(dá)到攻擊者預(yù)期的目的，主要涉及以下步驟：

a. 攻擊者獲取用戶已登錄的Cookie信息。

b. 攻擊者構(gòu)造一些惡意代碼，將這些代碼注入到受害者的瀏覽器中。

c. 受害者在未經(jīng)過任何提示的情況下，被惡意代碼引導(dǎo)訪問攻擊者的網(wǎng)站，其中URL中包含了攻擊者構(gòu)造的惡意參數(shù)。

d. 受害者瀏覽器訪問攻擊網(wǎng)站時(shí)，將自動(dòng)向受害者之前已登錄過的網(wǎng)站發(fā)送請求（上面存在的請求）。

e. 被惡意代碼引導(dǎo)，受害者訪問攻擊者的網(wǎng)站，正在被他人攻擊造成的后果并不為受害者所知，而瀏覽器會(huì)自動(dòng)發(fā)送包含受害者的Cookie信息的請求，造成CSRF攻擊。

當(dāng)攻擊者偽造了用戶的請求后，服務(wù)器端將無法準(zhǔn)確判斷這個(gè)請求的合法性，導(dǎo)致用戶數(shù)據(jù)被篡改、刪除、操作等，產(chǎn)生極大的安全風(fēng)險(xiǎn)。因此，在設(shè)計(jì)Web應(yīng)用程序時(shí)，需要充分考慮CSRF防御策略以保護(hù)用戶的信息安全。

防范：那怎么預(yù)防CSRF攻擊呢？OWASP推薦了兩種檢查方式來作為防御手段。

◆ 檢查標(biāo)準(zhǔn)頭部，確認(rèn)請求是否同源：檢查source origin和target origin，然后比較兩個(gè)值是否匹配。

◆ 檢查 CSRF Token：主要有四種推薦的方式

   · Synchronizer Tokens：在表單里隱藏一個(gè)隨機(jī)變化的token，每當(dāng)用戶提交表單時(shí)，將這個(gè)token提交到后臺(tái)進(jìn)行驗(yàn)證，如果驗(yàn)證通過則可以繼續(xù)執(zhí)行操作。

   · Double Cookie Defense：當(dāng)向服務(wù)器發(fā)出請求時(shí)，生成一個(gè)隨機(jī)值，將這個(gè)隨機(jī)值既放在cookie中，也放在請求的參數(shù)中，服務(wù)器同時(shí)驗(yàn)證這兩個(gè)值是否匹配。

   · Encrypted Token Pattern：對token進(jìn)行加密。

   · Custom Header：使用自定義請求頭部，這個(gè)方式依賴于同源策略。其中最適合的自定義頭部便是："X-Requested-With: XMLHttpRequest"。

參考文獻(xiàn)：