前端安全編碼

得德發表於2019-03-10
前端

這裡只是講解前端需要考慮的安全問題，後端和網路上的安全問題這裡不做講解

web網頁中前端開發中需要注意的幾個地方

  • url連結的安全問題
  • 輸入表單內容的安全問題
  • 介面提交的安全問題
  • 登入密碼的安全問題

下面通過具體的漏洞型別，進行分析

XSS漏洞

跨站指令碼攻擊（英語：Cross-site scripting，因簡稱與css衝突，無奈簡稱為：XSS）是一種網站應用程式的安全漏洞攻擊，是程式碼注入的一種。
它允許惡意使用者將程式碼注入到網頁上執行，其他使用者在觀看網頁時就會受到攻擊，從而可以達到攻擊者盜取使用者資訊或其他侵犯使用者安全隱私的目的。

XSS攻擊方式的幾種常見型別

非持久型 XSS

非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通過給別人傳送帶有惡意指令碼程式碼引數的 URL，當 URL 地址被開啟時，特有的惡意程式碼引數被 HTML 解析、執行。

  • 例如通過 URL 獲取某些引數
    下述 URL 輸入會將 HTML結構 改為 <div><script>alert(1)</script></div> ，這樣頁面中就憑空多了一段可執行指令碼
<!-- http://www.domain.com?name=<script>alert(1)</script> -->
<div>{{name}}</div>
複製程式碼

如何防禦

  • Web 頁面渲染的所有內容或者渲染的資料都必須來自於服務端
  • 儘量不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取資料直接渲染。
  • 儘量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.creteElement() 等可執行字串的方法
  • 做不到以上幾點的話，前端渲染的時候對任何的欄位都需要做 escape 轉義編碼
    • 最普遍的做法是轉義輸出的內容，對於引號，尖括號，斜槓進行轉義
      function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}
複製程式碼

      通過轉義可以將攻擊程式碼 變成

      escape('<script>alert(1)</script>')
// -> &lt;script&gt;alert(1)&lt;&#x2F;script&gt;
複製程式碼
    • 對於顯示富文字來說，不能通過上面的辦法來轉義所有字元，因為這樣會把需要的格式也過濾掉。這種情況通常採用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。
      以下示例使用了 js-xss 來實現。輸出中保留了 h1 標籤且過濾了 script 標籤
      var xss = require('xss')
var html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
console.log(html)
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
複製程式碼

持久型 XSS

持久型 XSS 漏洞，也被稱為儲存型 XSS 漏洞，一般存在於 Form 表單提交等互動功能，如發帖留言，提交文字資訊等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入資料庫持久儲存，當前端頁面獲得後端從資料庫中讀出的注入程式碼時，恰好將其渲染執行。

持久型 XSS 攻擊成功需要同時滿足以下幾個條件：

  • POST 請求提交表單後端沒做轉義直接入庫。
  • 後端從資料庫中取出資料沒做轉義直接輸出給前端。
  • 前端拿到後端資料沒做轉義直接渲染成 DOM。

如何防禦

  • 後端在入庫前應該選擇不相信任何前端資料，將所有的欄位統一進行轉義處理。
  • 後端在輸出給前端資料統一進行轉義處理。
  • 前端在渲染頁面 DOM 的時候應該選擇不相信任何後端資料，任何欄位都需要做轉義處理。

CSP

內容安全策略 (CSP) 是一個額外的安全層，用於檢測並削弱某些特定型別的攻擊，包括跨站指令碼 (XSS) 和資料注入攻擊等。無論是資料盜取、網站內容汙染還是散發惡意軟體，這些攻擊都是主要的手段。我們可以通過 CSP 來儘量減少 XSS 攻擊。CSP 本質上也是建立白名單，規定了瀏覽器只能夠執行特定來源的程式碼。

通常可以通過 HTTP Header 中的 Content-Security-Policy 來開啟 CSP

  • 只允許載入本站資源
Content-Security-Policy: default-src ‘self’
複製程式碼
  • 只允許載入 HTTPS 協議圖片
Content-Security-Policy: img-src https://*
複製程式碼

前端CSRF安全編碼

跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制使用者在當前已登入的 Web 應用程式上執行非本意的操作的攻擊方法。[1] 跟跨網站指令碼（XSS）相比，XSS 利用的是使用者對指定網站的信任，CSRF 利用的是網站對使用者網頁瀏覽器的信任

CSRF 就是利用使用者的登入態發起惡意請求, 攻擊成功需要同時滿足以下幾個條件：

  1. 使用者已經登入了站點 A，並在本地記錄了 cookie
  2. 在使用者沒有登出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。
  3. 站點 A 沒有做任何 CSRF 防禦
  • 攻擊方式
    假設網站中有一個通過 Get 請求提交使用者評論的介面，那麼攻擊者就可以在釣魚網站中加入一個圖片，圖片的地址就是評論介面
<img src="http://www.domain.com/xxx?comment='attack'" />
複製程式碼

如果介面是 Post 提交的，就相對麻煩點，需要用表單來提交介面

<form action="http://www.domain.com/xxx" id="CSRF" method="post">
 <input name="comment" value="attack" type="hidden" />
</form>
複製程式碼

防禦辦法

  • Get 請求不對資料進行修改
  • 不讓第三方網站訪問到使用者 Cookie
  • 阻止第三方網站請求介面
  • 在非 GET 請求中增加 token

    伺服器下發一個隨機 Token（演算法不能複雜），每次發起請求時將 Token 攜帶上，伺服器驗證 Token 是否有效。

密碼安全

密碼安全更多的是後端資料庫的安全，其實前端也可以做些事情，

  • 比如，防止暴力破解的方式破解密碼

通常使用驗證碼增加延時或者限制嘗試次數的方式。並且一旦使用者輸入了錯誤的密碼，也不能直接提示使用者輸錯密碼，而應該提示賬號或密碼錯誤。

前端敏感資訊洩漏

  • 禁止使用localStorage/sessionstorage/globalStorage進行敏感資訊儲存
  • 使用postMessage等需要在進行白名單校驗
  • 前端禁止寫入cookie

參考：
yuchengkai.cn/docs/fronte…
zoumiaojiang.com/article/com…

不足之處還望海涵，請大神多多指教

相關文章