淺談前端安全

前端安全的範圍

將Web安全問題按照發生的區域來分類，發生在瀏覽器、Web頁面中的安全問題就是前端安全問題。

同源策略

同源：URL由協議、域名、端口和路徑組成，若是兩個URL的協議、域名和端口相同，則表示他們同源。

URL	是否同源	緣由
http://test.test.com/dir2/oth...	是
http://test.test.com/dir/test...	是
https://test.test.com/test.html	否	協議不一樣
http://test.test.com:8080/test.html	否	端口不一樣
http://test123.test.com/test....	否	域名不一樣

瀏覽器的同源策略，限制了來自不一樣源的document或腳本，對當前document讀取或設置某些屬性。從一個域上加載的腳本不容許訪問另一個域的文檔屬性。

若是沒有同源限制存在，瀏覽器中的cookie等其餘數據能夠任意讀取，不一樣域下DOM能夠任意操做，ajax能夠任意請求。若是瀏覽了惡意網站那麼就會泄漏這些隱私數據

在瀏覽器中，<script>、<img>、<iframe>、<link>等標籤均可以加載跨域資源，而不受同源限制。

這些帶 src屬性的標籤每次加載時，其實是由瀏覽器發起了一次GET請求。不一樣於 XMLHttpRequest的是，經過 src屬性加載的資源，瀏覽器限制了JavaScript的權限，使其不能讀、寫返回的內容。

---

跨站腳本攻擊（XSS）

XSS，即Cross Site Script（跨站腳本攻擊）；爲了和層疊樣式表(Cascading Style Sheet)作出區分，在安全領域叫作 XSS。

XSS 攻擊是指攻擊者在網站上注入惡意的客戶端代碼，利用惡意腳本對客戶端網頁進行篡改，從而在用戶瀏覽網頁時，對用戶瀏覽器進行控制或者獲取用戶隱私數據的一種攻擊方式。有不少種方式進行 XSS 攻擊，但它們的共同點爲：將一些隱私數據像cookie、session發送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操做。

攻擊方式

反射型XSS

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

攻擊流程：

1. A給B發送一個惡意構造的URL
2. B點擊URL後跳轉到具備漏洞的HTML頁面
3. HTML頁面在B瀏覽器中執行JavaScript，能夠執行B所具備權限下的命令

存儲型XSS

惡意代碼被保存到目標網站的服務器中，這種攻擊具備較強的穩定性和持久性，比較常見場景是在博客，論壇、OA、CRM等社交網站上。

攻擊流程：

1. 攻擊者提交一條包含XSS代碼的留言或其餘數據到數據庫
2. 當目標用戶查詢時，XSS的內容會從服務器解析以後加載出來
3. 瀏覽器將惡意代碼看成正常腳本解析執行，能夠執行瀏覽器所具備權限下的命令

DOM Based XSS

基於DOM的XSS攻擊是指經過惡意腳本修改頁面的DOM結構，是純粹發生在客戶端的攻擊。DOM型XSS攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端JavaScript自身的安全漏洞。

攻擊流程：

1. A給B發送一個惡意構造的URL
2. B點擊URL後HTML頁面獲取攻擊性的代碼，如經過location.hash獲取的參數等
3. 攻擊性代碼看成HTML代碼寫入頁面
4. HTML頁面在B瀏覽器中執行JavaScript，能夠執行B所具備權限下的命令

防範手段

• 輸入檢查

  在源頭控制，把用戶輸入的一些不合法的東西都過濾或者編碼掉，從而保證安全性。如移除用戶提交的的DOM屬性如onerror，移除用戶上傳的節點，<iframe>，<script>，<a>節點等。

  通常業務中是對客戶端和服務端中同時進行輸入檢查。

• 輸出檢查

  利用轉義庫對 HTML 模板各處節點進行充分的轉義。

• 使用HttpOnly

  經過設置HttpOnly，瀏覽器能夠禁止頁面的JavaScript訪問帶有HttpOnly屬性的Cookie。它的目的並不是是爲了對抗XSS，而是對抗XSS以後的Cookie劫持攻擊。

  Cookie的使用過程：

  1. 瀏覽器向服務器發起請求，此時沒有Cookie
  2. 服務器返回Set-Cookie頭，向瀏覽器寫入Cookie
  3. 在Cookie到期以前，瀏覽器訪問該域下的全部頁面，都將發送該Cookie

  HttpOnly是在Set-Cookie的時候進行標記的

  Set-Cookie： <name>=<value>[; <Max-Age>=<age>]
  [; expires=<date>][; domain=<domain_name>]
  [; path=<some_path>][; secure][; HttpOnly]

• 輸入內容長度限制

  對輸入的內容限定合理長度，能夠增長XSS攻擊的難度

• 避免拼接HTML或者使用內聯事件

  前端使用拼接HTML或者內聯事件的狀況比較危險，建議替換爲createElement、setAttribute及addEventListener的實現方法，或者採用成熟的框架進行渲染，如Vue/React等

• 開啓CSP網頁安全政策（Content Security Policy）

  一種由開發者定義的安全性政策申明，經過CSP所約束的責任指定可信的內容來源，（內容能夠是指腳本、圖片、style 等遠程資源）。

  CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。

  開啓方式：

  • 經過HTTP頭信息的Content-Security-Policy字段
  • 在網頁中設置<meta>標籤

<meta http-equiv\="Content-Security-Policy" content\="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"\>

---

跨站點請求僞造（CSRF）

跨站請求僞造攻擊，原理就是攻擊者構造出一個後端請求地址，誘導用戶點擊或者經過某些途徑自動發起請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，冒充用戶執行某些操做。

攻擊流程

1. 被攻擊者登陸A站點，並保留了登錄憑證
2. 攻擊者誘使被攻擊者訪問B站點
3. B站點向A站點發起請求，瀏覽器會默認攜帶A站點的Cookie
4. A站點接收請求後會對其進行驗證，並且會誤認爲是被攻擊者發起的請求，同時以被攻擊者的身份執行相應的操做

攻擊方式

• GET類型

  通常是利用<img>標籤等發起

  <img src="http://test.com/test?test=test">

  在被攻擊者訪問頁面時，瀏覽器會自動向src指向的地址發出請求

• POST類型

  一般是構造一個自動提交的表單在頁面上，模擬用戶完成了一次POST操做

• 連接類型

  一般是須要誘騙用戶點擊纔會觸發

攻擊特色

• 攻擊通常發生在第三方站點，被攻擊站點沒法防止攻擊發生
• 攻擊手段爲冒充受害者提交操做，而非直接竊取數據
• 攻擊過程當中攻擊者並不能獲取到用戶的登錄憑證，而只是冒充

防範手段

• 驗證碼

  經過增長網站A的驗證手段，例如增長圖形驗證碼或短信驗證碼等等，只有經過驗證的請求才算合法。可是這種方案擁有兩個侷限性，一個是增長開發成本，另一個是下降用戶體驗。

• 驗證Referer

  根據 HTTP 協議，在 HTTP 頭中有一個字段叫Referer，它記錄了該 HTTP 請求的來源地址。經過驗證Referer，能夠檢查請求是否來自合法的"源"。

• 驗證Token

  服務端隨機生成token，保存在服務端session中，同時保存到客戶端中，客戶端發送請求時，把token帶到HTTP請求頭或參數中，服務端接收到請求，驗證請求中的token與session中的是否一致。若是請求中沒有 token 或者 token 內容不正確，則認爲多是 CSRF 攻擊而拒絕該請求。

---

點擊劫持

在一個Web頁面下隱藏了一個透明的iframe（opacity：0），用外層假頁面誘導用戶點擊，其實是在隱藏的frame上觸發了點擊事件進行一些用戶不知情的操做。

攻擊流程

1. 攻擊者構造一個誘導用戶點擊的內容，將頁面放入到<iframe>
2. 利用z-index和opacity將<iframe>疊加到實際頁面上方並透明化
3. 受害者訪問到欺騙頁面後，實際看到的是誘使點擊的內容，點擊以後則是有害頁面

攻擊方式

• 盜取用戶資金
• 得到用戶敏感信息
• 與XSS或者CSRF相配合，誘騙用戶點擊惡意連接

防範手段

• 設置X-FRAME-OPTIONS

  服務器端可設置HTTP頭X-Frame-Options：DENY來讓瀏覽器主動禁止<iframe>內嵌，可是這種方式須要結合HTTPS來實現，由於HTTP不可靠，容易被竊聽篡改內容