作者 | 李芷若上海控安可信軟件創(chuàng)新研究院工控網(wǎng)絡(luò)安全組

來源 |鑒源實驗室

社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區(qū)”

01

背 景

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

網(wǎng)絡(luò)安全攻擊利用了 HTTP 協(xié)議的各種漏洞和特性，試圖在數(shù)據(jù)傳輸過程中獲取未授權(quán)的信息、操縱數(shù)據(jù)、擾亂服務(wù)甚至竊取敏感信息。這些攻擊不僅對用戶隱私構(gòu)成威脅，還可能導致嚴重的經(jīng)濟損失和聲譽損害。因此，了解和防范 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é)議初期運行在TCP/IP協(xié)議之上，后期運行在QUIC協(xié)議之上，是應用層協(xié)議。它定義了客戶端（如瀏覽器）和服務(wù)器之間如何傳輸文本、圖像、視頻及其他多媒體內(nèi)容。同時，也是一種客戶端-服務(wù)端（client-server）協(xié)議，也就是說，請求是由接收方—通常是瀏覽器發(fā)起的，客戶端與服務(wù)端之間通過交換一個個獨立的消息（而非數(shù)據(jù)流）進行通信。由客戶端——通常是個瀏覽器——發(fā)出的消息被稱作請求（request），由服務(wù)端發(fā)出的應答消息被稱作響應（response）。

圖1

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

HTTP 報文是面向文本的，報文中的每個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTP 有兩類報文：請求報文和響應報文。

圖2HTTP請求報文

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

◆ 請求行

· 請求方法

· 請求URL

· HTTP協(xié)議版本

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

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

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

圖3 HTTP響應報文

HTTP響應報文由以下內(nèi)容組成：

◆狀態(tài)行

· HTTP協(xié)議版本

· 狀態(tài)碼

· 狀態(tài)短語

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

◆空行：空行用于分隔響應頭部和響應主體。它僅包含回車符和換行符（CRLF），即 rn。

◆

響應主體：

響應主體包含了實際返回的數(shù)據(jù)，通常是 HTML 文檔、圖像、JSON 數(shù)據(jù)等，格式?jīng)]有固定要求。

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

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

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

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

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

2010 年代，許多網(wǎng)站開始使用HTTPS（安全 HTTP），這是由 Netscape Communications Corporation 在1994年開發(fā)的，其中添加了SSL（安全套接字層）協(xié)議到HTTP中，為瀏覽器和服務(wù)器之間提供加密層。

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

（1）無狀態(tài)

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

（2）無連接

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

（3）靈活性

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

（4）可擴展性

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

03

常見攻擊方式

3.1 SQL Injection（SQL 注入）

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

比如后端有SQL如下，需要前端傳入一個id值，以進行信息查詢:

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

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

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

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

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

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

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

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

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

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

◆ White List Input Validation：驗證用戶的輸入。

◆ Escaping All User Supplied Input：

對用戶提供的所有的輸入都進行編碼。

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

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

大致分為以下幾類：

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

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

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

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

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

防范：

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

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

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

◆

速率限制（Rate Limiting）：

對單個IP地址或用戶的請求速率進行限制，防止過多的請求來自同一來源。

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

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

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

大致分為以下幾類：

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

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

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

防范：

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

◆

數(shù)據(jù)編碼：

對所有的數(shù)據(jù)進行適當?shù)木幋a。

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

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

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

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

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

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

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

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

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

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

◆檢查標準頭部，確認請求是否同源：檢查source origin和target origin，然后比較兩個值是否匹配。

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

·Synchronizer Tokens：在表單里隱藏一個隨機變化的token，每當用戶提交表單時，將這個token提交到后臺進行驗證，如果驗證通過則可以繼續(xù)執(zhí)行操作。

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

·Encrypted Token Pattern：對token進行加密。

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

參考文獻：

[1]Gourley D, Totty B. HTTP: the definitive guide[M]. " O'Reilly Media, Inc.", 2002.

[2] 李康,陳清華,盧金星. HTTP協(xié)議研究綜述[J]. 信息系統(tǒng)工程,2021(5):126-129. DOI:10.3969/j.issn.1001-2362.2021.05.050.

[3] 劉文生, 樂德廣, 劉偉. SQL注入攻擊與防御技術(shù)研究[J]. 信息網(wǎng)絡(luò)安全, 2015, 15(9): 129-134.

[4] Prajapati P, Patel N, Shah P. A review of recent detection methods for http ddos attacks[J]. International Journal of Scientific, 2019.

[5]Rodríguez G E, Torres J G, Flores P, et al. Cross-site scripting (XSS) attacks and mitigation: A survey[J]. Computer Networks, 2020, 166: 106960.

[6]Blatz J. Csrf: Attack and defense[J]. McAfee? Foundstone? Professional Services, White Paper, 2007.

審核編輯 黃宇