作者 | 李芷若上海控安可信軟件創(chuàng)新研究院工控網(wǎng)絡(luò)安全組
來源 |鑒源實(shí)驗(yàn)室
社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區(qū)”
01
背 景
隨著互聯(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)容。同時,也是一種客戶端-服務(wù)端(client-server)協(xié)議,也就是說,請求是由接收方—通常是瀏覽器發(fā)起的,客戶端與服務(wù)端之間通過交換一個個獨(dú)立的消息(而非數(shù)據(jù)流)進(jìn)行通信。由客戶端——通常是個瀏覽器——發(fā)出的消息被稱作請求(request),由服務(wù)端發(fā)出的應(yīng)答消息被稱作響應(yīng)(response)。
圖1
2.2 HTTP協(xié)議報文格式
HTTP 報文是面向文本的,報文中的每個字段都是一些ASCII碼串,各個字段的長度是不確定的。HTTP 有兩類報文:請求報文和響應(yīng)報文。
圖2HTTP請求報文
HTTP 請求報文由以下內(nèi)容組成:
◆ 請求行
· 請求方法
· 請求URL
· HTTP協(xié)議版本
◆ 請求頭部:請求頭部包含了多個頭字段,每個字段包含一個名稱和一個值,用于傳遞客戶端的額外信息和指示。每個頭字段占一行。
◆ 空行:空行用于分隔請求頭部和請求主體。它僅包含回車符和換行符(CRLF),即 rn。
◆ 請求主體:請求主體包含了實(shí)際發(fā)送的數(shù)據(jù),僅在某些方法(如 POST、PUT)中存在。它可以是任意二進(jìn)制數(shù)據(jù)或文本數(shù)據(jù),格式?jīng)]有固定要求。
圖3 HTTP響應(yīng)報文
HTTP響應(yīng)報文由以下內(nèi)容組成:
◆狀態(tài)行
· HTTP協(xié)議版本
· 狀態(tài)碼
· 狀態(tài)短語
◆響應(yīng)頭部:響應(yīng)頭部包含了多個頭字段,每個字段包含一個名稱和一個值,用于傳遞服務(wù)器的額外信息和指示。每個頭字段占一行。
◆空行:空行用于分隔響應(yīng)頭部和響應(yīng)主體。它僅包含回車符和換行符(CRLF),即 rn。
◆
響應(yīng)主體:
響應(yīng)主體包含了實(shí)際返回的數(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)頁加載緩慢的問題,并且是一種二進(jìn)制協(xié)議,其中使用二進(jìn)制值而不是像以前版本中那樣使用純文本。
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是一個基于請求-響應(yīng)模型的無狀態(tài)協(xié)議。無狀態(tài)意味著每個請求都是獨(dú)立的,服務(wù)器不會保留之前請求的狀態(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ù)據(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如下,需要前端傳入一個id值,以進(jìn)行信息查詢:
SELECT * FROM `MyTable` WHERE `id`="{0}"
而此時,如果前端傳入“1” OR TRUE。后端沒有校驗(yàn)便傳入?yún)?shù)值并對SQL進(jìn)行拼接。那么直接拼接的SQL為:
SELECT * FROM `MyTable` WHERE `id`="1" OR TRUE
此時將所有數(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)處理,不讓特殊符號破壞SQL語句的原本結(jié)構(gòu)等,并且可以在前端/后端執(zhí)行。
如果校驗(yàn)邏輯在前端執(zhí)行,確實(shí)不會對后端性能造成影響,但對于有經(jīng)驗(yàn)的攻擊者,可以修改前端代碼,此屏障就形同虛設(shè);而如果在后端進(jìn)行校驗(yàn),多少會損耗后端性能,如果校驗(yàn)算法比較復(fù)雜耗時,也許又會成為攻擊者的另一個攻擊點(diǎn)。
根據(jù) OWASP,下面看看具體的預(yù)防措施:
◆ Prepared Statements(with Parameterized Queries): 參數(shù)化的查詢語句可以強(qiáng)制應(yīng)用開發(fā)者首先定義所有的sql代碼,之后再將每個參數(shù)傳遞給查詢語句。
◆ Stored Procedures:使用語言自帶的存儲程序,而不是自己直接操縱數(shù)據(jù)庫。
◆ White List Input Validation:驗(yàn)證用戶的輸入。
◆ Escaping All User Supplied Input:
對用戶提供的所有的輸入都進(jìn)行編碼。
3.2 Distributed Denial of Service(DDoS,分布式拒絕服務(wù))
原理:HTTP DDoS攻擊[4]是一種特定類型的DDoS攻擊,旨在通過大量HTTP請求淹沒目標(biāo)Web服務(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),通過慢速請求來捆綁每個服務(wù)器線程,從而消耗服務(wù)器的線程&連接資源。攻擊者與服務(wù)器建立大量連接,每個連接只發(fā)送部分請求頭,并在接近超時之前繼續(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í)行反序列化操作時引起服務(wù)過載。
◆HTTP請求隨機(jī)化攻擊:攻擊者使用各種隨機(jī)化技術(shù),改變User-Agent頭、Referer頭、URL參數(shù)等,使請求難以被簡單地識別和過濾,使每個HTTP請求看起來都是唯一的,從而繞過基于簽名的防御機(jī)制。
DDoS攻擊一般會根據(jù)攻擊目標(biāo)的情況,針對性的把技術(shù)手法混合,以達(dá)到最低的成本最難防御的目的,并且可以進(jìn)行合理的節(jié)奏控制,以及隱藏保護(hù)攻擊資源。
防范:
◆Web應(yīng)用防火墻(WAF):過濾和阻止惡意HTTP請求。
◆CDN(內(nèi)容分發(fā)網(wǎng)絡(luò)):使用CDN將流量分散到多個節(jié)點(diǎn),提高整體抗攻擊能力。
◆流量清洗服務(wù):使用專門的DDoS防護(hù)服務(wù)來識別和清洗惡意流量。
◆
速率限制(Rate Limiting):
對單個IP地址或用戶的請求速率進(jìn)行限制,防止過多的請求來自同一來源。
3.3 Cross Site Script(XSS, 跨站腳本攻擊)
原理:XSS是一種安全漏洞。攻擊者可以利用這種漏洞在網(wǎng)站上注入惡意的客戶端代碼。當(dāng)受害者運(yùn)行這些惡意代碼時,攻擊者就可以突破網(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)容。
大致分為以下幾類:
◆存儲XSS:注入的腳本永久的存在于目標(biāo)服務(wù)器上,每當(dāng)受害者向服務(wù)器請求此數(shù)據(jù)時就會重新喚醒攻擊腳本。
◆反射型XSS:當(dāng)用受害者被引誘點(diǎn)擊一個惡意鏈接,提交一個偽造的表單,惡意代碼便會和正常返回?cái)?shù)據(jù)一起作為響應(yīng)發(fā)送到受害者的瀏覽器,從而騙過了瀏覽器,使之誤以為惡意腳本來自于可信的服務(wù)器,以至于讓惡意腳本得以執(zhí)行。
◆DOM型XSS:有點(diǎn)類似于存儲型XSS,但存儲型XSS是將惡意腳本作為數(shù)據(jù)存儲在服務(wù)器中,每個調(diào)用數(shù)據(jù)的用戶都會受到攻擊。但DOM型XSS則是一個本地的行為,更多是本地更新DOM時導(dǎo)致了惡意腳本執(zhí)行。
防范:
◆輸入驗(yàn)證:從客戶端和服務(wù)器端雙重驗(yàn)證所有的輸入數(shù)據(jù),這一般能阻擋大部分注入的腳本。
◆
數(shù)據(jù)編碼:
對所有的數(shù)據(jù)進(jìn)行適當(dāng)?shù)木幋a。
3.4 Cross Site Request Forgery(CSRF,跨站請求偽造)
原理:CSRF攻擊[6]是一種利用用戶在已登錄網(wǎng)站上的身份來偽造用戶請求的攻擊方式,造成用戶數(shù)據(jù)的損失或網(wǎng)絡(luò)安全的風(fēng)險。也是一種挾制用戶在當(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)站時,將自動向受害者之前已登錄過的網(wǎng)站發(fā)送請求(上面存在的請求)。
e. 被惡意代碼引導(dǎo),受害者訪問攻擊者的網(wǎng)站,正在被他人攻擊造成的后果并不為受害者所知,而瀏覽器會自動發(fā)送包含受害者的Cookie信息的請求,造成CSRF攻擊。
當(dāng)攻擊者偽造了用戶的請求后,服務(wù)器端將無法準(zhǔn)確判斷這個請求的合法性,導(dǎo)致用戶數(shù)據(jù)被篡改、刪除、操作等,產(chǎn)生極大的安全風(fēng)險。因此,在設(shè)計(jì)Web應(yīng)用程序時,需要充分考慮CSRF防御策略以保護(hù)用戶的信息安全。
防范:那怎么預(yù)防CSRF攻擊呢?OWASP推薦了兩種檢查方式來作為防御手段。
◆檢查標(biāo)準(zhǔn)頭部,確認(rèn)請求是否同源:檢查source origin和target origin,然后比較兩個值是否匹配。
◆檢查 CSRF Token:主要有四種推薦的方式
·Synchronizer Tokens:在表單里隱藏一個隨機(jī)變化的token,每當(dāng)用戶提交表單時,將這個token提交到后臺進(jìn)行驗(yàn)證,如果驗(yàn)證通過則可以繼續(xù)執(zhí)行操作。
·Double Cookie Defense:當(dāng)向服務(wù)器發(fā)出請求時,生成一個隨機(jī)值,將這個隨機(jī)值既放在cookie中,也放在請求的參數(shù)中,服務(wù)器同時驗(yàn)證這兩個值是否匹配。
·Encrypted Token Pattern:對token進(jìn)行加密。
· Custom Header:使用自定義請求頭部,這個方式依賴于同源策略。其中最適合的自定義頭部便是:"X-Requested-With: XMLHttpRequest"。
參考文獻(xiàn):
[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.
審核編輯 黃宇
-
網(wǎng)絡(luò)安全
+關(guān)注
關(guān)注
11文章
3295瀏覽量
61103 -
HTTP
+關(guān)注
關(guān)注
0文章
520瀏覽量
32446
發(fā)布評論請先 登錄
實(shí)驗(yàn)室安全管理成焦點(diǎn),漢威科技賦能實(shí)驗(yàn)室安全升級

Lansweeper:強(qiáng)化網(wǎng)絡(luò)安全與資產(chǎn)管理
DEKRA德凱網(wǎng)絡(luò)安全實(shí)驗(yàn)室榮獲ISO 17025認(rèn)可資質(zhì)
NVIDIA推出DRIVE AI安全檢測實(shí)驗(yàn)室
高校實(shí)驗(yàn)室智能安全配電裝置

安全配電裝置在高校實(shí)驗(yàn)室中的應(yīng)用
TCL智能終端安全實(shí)驗(yàn)室獲TüV南德雙項(xiàng)資質(zhì)認(rèn)證
上汽集團(tuán)與紫金山實(shí)驗(yàn)室簽署戰(zhàn)略合作協(xié)議
國產(chǎn)網(wǎng)絡(luò)安全主板在防御網(wǎng)絡(luò)攻擊中的實(shí)際應(yīng)用
IP定位技術(shù)追蹤網(wǎng)絡(luò)攻擊源的方法
實(shí)驗(yàn)室精密儀器防雷安全方案

鑒源實(shí)驗(yàn)室·ISO 26262中測試用例的得出方法-等價類的生成和分析

鑒源實(shí)驗(yàn)室·基于MQTT協(xié)議的模糊測試研究

高校實(shí)驗(yàn)室無線物聯(lián)網(wǎng)用電安全系統(tǒng)設(shè)計(jì)與應(yīng)用

評論