《前端之路》之前端安全 XSS 原理以及防護手段

時間 2019-11-30

標籤前端之路前端安全 xss 原理以及防護手段欄目系統安全简体版

原文原文鏈接

什麼是 XSS

1、XSS

什麼是 XSS

XSS，即 Cross Site Script ，翻譯過來就是跨站腳本攻擊；爲了和 css 有所區分，於是在安全領域被稱爲 XSS。javascript

什麼是 XSS 攻擊

XSS 攻擊指的是攻擊者在網站上注入惡意的客戶端代碼，經過惡意腳本對客戶端網頁進行篡改，從而在別的用戶瀏覽網頁的時候，對用戶進行控制或者獲取用戶對隱私數據的這麼一種攻擊手段。css

XSS 攻擊的方式是什麼

XSS 攻擊能夠分爲3類：反射型（非持久型）、存儲型（持久型）、基於DOM。html

XSS攻擊須要具有兩個條件：須要向web頁面注入惡意代碼；這些惡意代碼可以被瀏覽器成功的執行。前端

用戶注入的惡意腳本通常包括 JavaScript 、HTML、Flash。不少種的 XSS 攻擊方式，可是共同點是：將一些隱私數據像：一、cookie、session 發送給攻擊者。二、將受害者重定向到一個由攻擊者控制的網站（俗稱釣魚網站），在受害者的機器上進行一些惡意操做。vue

####反射型（非持久型）的 XSS 攻擊java

XSS反射型攻擊，惡意代碼並無保存在目標網站，而是經過引誘用戶點擊一個連接到目標網站的惡意連接來實施攻擊的。node

直接這麼解釋仍是有點難懂的。下面，咱們仍是來看個 demogit

<a href="http://127.0.0.1:1212/login/<img src='' onerror='alert(document.cookie)'>" target="_blank" >這是 XSS 的惡意連接</a> 複製代碼

假設某用戶在黑客點釣魚網站上點擊了這個帶有 XSS 攻擊的惡意連接。就會跳轉到 http://127.0.0.1:1212 這個網站上。恰好這個路徑下的連接是會有一個發生一個 get 請求。那麼這個時候 <img src='' onerror='alert(document.cookie)'> 這部分的內容就被看成請求的內容發送給了服務端。若是服務端爲對該內容進行 XSS 防護，直接返回給瀏覽器。github

那麼這個時候就會出現 XSS 攻擊了。<img src='' onerror='alert(document.cookie)'> 這句代碼被顯示在了瀏覽器上，由於 img 標籤也具備跨域屬性，直接執行了 onerror 中的 JS 代碼。黑客這個時候就能夠在目標網站上隨心所欲了。web

好比這裏就是簡單的 alert 了全部的 cookie。可是，若是我是黑客的話，我確定會把用戶的 cookie、localStorage、等等重要信息所有上傳到個人服務器，而後進行拿到各種想要的信息。從而獲益。

####存儲型（持久型）的 XSS 攻擊

存儲型（持久型）的 XSS 攻擊和反射型其實也有殊途同歸之妙呀。

這麼多，我哪裏記得住？

別慌，咱們慢慢分析一波就都能記住啦～

惡意代碼經過表單提交的方式被保存到目標網站的服務器中，這種攻擊具備較強的穩定性和持久性，比較常見場景是在博客，論壇、OA、CRM等社交網站上，好比：某CRM系統的客戶投訴功能上存在XSS存儲型漏洞，黑客提交了惡意攻擊代碼，當系統管理員查看投訴信息時惡意代碼執行，竊取了客戶的資料，然而管理員絕不知情，這就是典型的XSS存儲型攻擊。

咱們仍是寫個 demo 來方便理解吧

 <div><textarea id="textarea" class="text"></textarea></div> <button id="btn" class="botton">submit</button> 複製代碼

大概就長這個樣子了：

textarea 內則爲帶有 xss 的代碼，點擊提交。直接 xhr 請求到 node 的服務端。

node 服務端接收到傳入的參數不作任何 xss 防護直接保存起來的 js demo 通常是存儲 sql 可是這裏方便起見咱們就直接存 memory-cache ，代碼以下：

router.post("/upload", (ctx, next) => {
  let curData = JSON.stringify(ctx.request.body);
  cache.put("xss", curData);
  ctx.body = `<div>${curData}</div>`;
});
複製代碼

咱們請求一個新的路徑來將 memory-cache 的值獲取到。 node 端代碼：

router.get("/getName", (ctx, next) => {
  let curData = cache.get("xss");
  ctx.body = `<div>${JSON.parse(curData)}</div>`;
});
複製代碼

接下來就是訪問 http://127.0.0.1:1212/getName

獲得以下畫面：

固然，黑客不會 alert 你的 cookie 信息。直接 post 到一個第三方的服務器上，而後直接模擬瀏覽器訪問，那就簡直了。

####基於 DOM 的 XSS 攻擊

基於 DOM 的 XSS 攻擊是指經過惡意腳本修改頁面的 DOM 結構，是純粹發生在客戶端的攻擊。

const divXss = document.getElementById("xss");
    const xssbtn = document.getElementById("xssbtn");

    const val = `'' onclick=alert(/xss/)`;

    xssbtn.addEventListener("click", function() {
      divXss.innerHTML = `<a href=${val}>testLink</a>`;
    });
複製代碼

固然上面的這個 val 每每是黑客經過 input 或者 textarea 的 form表單提交引發的

當用戶下意識的去點擊這個新增的 dom 的時候，就會出現以下場景：

黑客又能夠隨心所欲了。

2、XSS 的防護

HttpOnly 防止劫取 Cookie

HttpOnly 最先由微軟提出，至今已經成爲一個標準。瀏覽器將禁止頁面的Javascript 經過 document.cookie 獲取帶有 HttpOnly 屬性的Cookie。

上文有說到，攻擊者能夠經過注入惡意腳本獲取用戶的 Cookie 信息。一般 Cookie 中都包含了用戶的登陸憑證信息，攻擊者在獲取到 Cookie 以後，則能夠發起 Cookie 劫持攻擊。因此，嚴格來講，HttpOnly 並不是阻止 XSS 攻擊，而是能阻止 XSS 攻擊後的 Cookie 劫持攻擊。