前端面試題（五）安全篇

XSS

跨網站指令碼（英語：Cross-site scripting，一般簡稱爲：XSS）是一種網站應用程式的安全漏洞攻擊，是代碼注入的一種。它容許惡意使用者將程式碼注入到網頁上，其餘使用者在觀看網頁時就會受到影響。這類攻擊一般包含了 HTML 以及使用者端腳本語言。

XSS 分爲三種：反射型，存儲型和 DOM-based

如何攻擊

XSS 經過修改 HTML 節點或者執行 JS 代碼來攻擊網站。

例如經過 URL 獲取某些參數

<!-- http://www.domain.com?name=<script>alert(1)</script> -->
<div>{{name}}</div>                                                  
複製代碼

上述 URL 輸入可能會將 HTML 改成 <div><script>alert(1)</script></div> ，這樣頁面中就憑空多了一段可執行腳本。這種攻擊類型是反射型攻擊，也能夠說是 DOM-based 攻擊。

也有另外一種場景，好比寫了一篇包含攻擊代碼 <script>alert(1)</script> 的文章，那麼可能瀏覽文章的用戶都會被攻擊到。這種攻擊類型是存儲型攻擊，也能夠說是 DOM-based 攻擊，而且這種攻擊打擊面更廣。

如何防護

最廣泛的作法是轉義輸入輸出的內容，對於引號，尖括號，斜槓進行轉義

function escape(str) {
	str = str.replace(/&/g, "&");
	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
}
複製代碼

經過轉義能夠將攻擊代碼 <script>alert(1)</script> 變成

// -> <script>alert(1)</script>
escape('<script>alert(1)</script>')
複製代碼

對於顯示富文原本說，不能經過上面的辦法來轉義全部字符，由於這樣會把須要的格式也過濾掉。這種狀況一般採用白名單過濾的辦法，固然也能夠經過黑名單過濾，可是考慮到須要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。

var xss = require("xss");
var html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>');
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html);
複製代碼

以上示例使用了 js-xss 來實現。能夠看到在輸出中保留了 h1 標籤且過濾了 script 標籤

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://*
  複製代碼

• 容許加載任何來源框架

  Content-Security-Policy: child-src 'none'
  複製代碼

更多屬性能夠查看 這裏

CSRF

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

簡單點說，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>
複製代碼

如何防護

防範 CSRF 能夠遵循如下幾種規則：

1. Get 請求不對數據進行修改
2. 不讓第三方網站訪問到用戶 Cookie
3. 阻止第三方網站請求接口
4. 請求時附帶驗證信息，好比驗證碼或者 token

SameSite

能夠對 Cookie 設置 SameSite 屬性。該屬性設置 Cookie 不隨着跨域請求發送，該屬性能夠很大程度減小 CSRF 的攻擊，可是該屬性目前並非全部瀏覽器都兼容。

驗證 Referer

對於須要防範 CSRF 的請求，咱們能夠經過驗證 Referer 來判斷該請求是否爲第三方網站發起的。

Token

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

密碼安全

密碼安全雖然大可能是後端的事情，可是做爲一名優秀的前端程序員也須要熟悉這方面的知識。

加鹽

對於密碼存儲來講，必然是不能明文存儲在數據庫中的，不然一旦數據庫泄露，會對用戶形成很大的損失。而且不建議只對密碼單純經過加密算法加密，由於存在彩虹表的關係。

一般須要對密碼加鹽，而後進行幾回不一樣加密算法的加密。

// 加鹽也就是給原密碼添加字符串，增長原密碼長度
sha256(sha1(md5(salt + password + salt)))
複製代碼

可是加鹽並不能阻止別人盜取帳號，只能確保即便數據庫泄露，也不會暴露用戶的真實密碼。一旦攻擊者獲得了用戶的帳號，能夠經過暴力破解的方式破解密碼。對於這種狀況，一般使用驗證碼增長延時或者限制嘗試次數的方式。而且一旦用戶輸入了錯誤的密碼，也不能直接提示用戶輸錯密碼，而應該提示帳號或密碼錯誤。