背 景

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

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

02

HTTP協(xié)議介紹

2.1 HTTP協(xié)議概念

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

圖1

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

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

圖2 HTTP請求報文

HTTP 請求報文由以下內容組成：

◆ 請求行

   · 請求方法

   · 請求URL

   · HTTP協(xié)議版本

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

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

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

圖3 HTTP響應報文

HTTP響應報文由以下內容組成：

◆ 狀態(tài)行

   · HTTP協(xié)議版本

   · 狀態(tài)碼

   · 狀態(tài)短語

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

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

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

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

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

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

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

2.4 HTTP協(xié)議性質

（1）無狀態(tài)

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

（2）無連接

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

（3）靈活性

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

（4）可擴展性

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

03

常見攻擊方式

3.1 SQL Injection（SQL 注入）

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

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

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

而此時，如果前端傳入“1” OR TRUE。后端沒有校驗便傳入參數值并對SQL進行拼接。那么直接拼接的SQL為：

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

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

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

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

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

根據 OWASP，下面看看具體的預防措施：

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

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

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

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

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

大致分為以下幾類：

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

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

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

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

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

防范：

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

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

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

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

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

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

大致分為以下幾類：

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

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

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

防范：

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

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

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

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

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

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

c. 受害者在未經過任何提示的情況下，被惡意代碼引導訪問攻擊者的網站，其中URL中包含了攻擊者構造的惡意參數。

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

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

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

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

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

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

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

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

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

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

參考文獻：