前端安全

時間 2019-12-29

原文原文鏈接

1、XSS

什麼是XSS攻擊
cross site script 跨站腳本攻擊，是一種代碼注入攻擊，攻擊者在目標網站注入惡意代碼，當被攻擊者登陸網站時就會執行這些惡意代碼，這些腳本能夠獲取cookie,session tocken，或者其餘敏感網站信息。
xss攻擊的本質是：惡意代碼未通過濾，與網站正常的代碼混在一塊兒，瀏覽器沒法識別哪些腳本是可信的，致使惡意腳本被執行。因爲在用戶終端執行，惡意代碼可以直接獲取用戶信息，攻擊者利用這些信息冒充用戶想網站發起本身定義的請求
攻擊類型
一、反射型
(1)攻擊步驟：
a、攻擊者構造出特殊的url，其中包含惡意代碼
b、用戶打開帶有惡意代碼的url時，網站服務端將惡意代碼從url中取出，拼接在html
中返回給瀏覽器
c、瀏覽器接收到響應後解析執行，其中的惡意代碼也被執行
d、惡意代碼能夠竊取用戶數據併發到攻擊者的網站，或者冒充用戶的行爲，調用目標
網站接口，執行攻擊者操做
(2)、防範手段
a、設置cookie是帶上HtppOnly，使得在客戶端沒法獲取到cookie信息
```
res.addHeader('Set-Cookie',"userid=XXX;path=/;HttpOnly")複製代碼
```
b、對url查詢參數進行轉義encodeURIComponent再輸出到頁面
```
app.get('/home', (req,res)=>{
  res.send(encodeURIComponent(req.query.type))
})複製代碼
```

二、DOM型XSS攻擊
實際上就是前段js代碼不嚴謹，把不可信的內容插入到頁面，在使用.innerHTML， outerHTML,appenChild等api時要格外當心，不要把不可信的數據做爲html插到頁面上
(1)、攻擊步驟：
a、攻擊者構造出特殊的數據，其中包含惡意代碼
b、瀏覽器執行了惡意代碼
c、惡意代碼攜帶用戶信息發送到攻擊者網站，或者冒充用戶行爲，調用目標網站接口執行惡意操做
(2)、防範手段
防範DOM型XSS核心是對輸入的內容進行轉義，對敏感特殊字符<>"'進行轉義
html

function encodeHtml(str) {
    return str.replace(/"/g, '&quot;') .replace(/'/g, '&apos;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;'); }複製代碼

三、存儲型XSS攻擊
惡意腳本永久存在目標服務器上，當瀏覽器請求時，腳本從服務器傳回並執行。存在的根本緣由仍然是沒有作好過濾，前端沒有作好過濾就提交到服務端，服務端沒有作過濾就存到數據庫，前端從服務器請求到數據時沒有作好過濾就輸出。這種攻擊常見於帶有用戶保存信息的網站，如論壇、商品評論、貼吧等

(1)、攻擊步驟：
a、攻擊者將惡意代碼提交到目標網站數據庫中
b、用戶打開目標網站時，網站服務器將惡意代碼從數據庫中取出，拼在html中給瀏覽器
c、用戶瀏覽器接收到用戶數據併發送到攻擊者網站，或者冒充用戶，調用目標網站接口執行惡意操做
(2)、防範措施：要轉義！！！
a、前端提交數據給服務端以前對特殊字符轉義前端

b、後端在存儲以前要對特殊字符轉義redis

c、前端在獲取數據，拼接html，渲染頁面以前，對特殊字符轉義數據庫

除了轉義以外的防禦
一、CSP:只容許加載同域下的資源：服務端設置http的content-security-policy,或者在前端meta標籤設置，只容許加載同域下的資源，有不少配置項
```
<meta http-equiv="Content-Security-Policy" content="form-action 'self';">複製代碼
```

二、設置cookie爲httpOnly，沒法在客戶端用js獲取cookie後端

res.addHeader('Set-Cookie',"uid=xxx;path=/;HttpOnly")複製代碼

CSRF

什麼是CSRF?
cross-site-request-forgrey：跨站請求僞造，利用用戶已登陸態，攻擊者誘導用戶進入惡意網站，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，染事後臺的用戶驗證，達到冒充用戶對被攻擊網站執行惡意操做的目的
攻擊過程
一、用戶登陸了網站A，並保留了登陸憑證（cookie）
二、攻擊者誘導用戶訪問了站點B
三、站點B向站點A發送惡意請求，瀏覽器會默認攜帶站點A的憑證，繞過了用戶驗證
四、攻擊完成。
防護
一、判斷請求的來源：header中有referer信息，判斷來源是否安全
二、使用tocken（主流）
CSRF攻擊之因此能成功，就是使用cookie，繞過了服務端的用戶鑑權。那麼咱們就要求全部的用戶請求都攜帶一個攻擊者沒法獲取的tocken。服務器經過驗證tocken是否正確將用戶和CSRF攻擊者分隔開
步驟：
a、登陸成功時，服務端生成一個tocken，傳遞給用戶
b、用戶提交請求時攜帶這個tocken
c、服務器驗證tocken是否正確
禁止第三方網站攜帶cookie， sameSite Cookie屬性，存在兼容性問題

3、HTTP協議

4、用戶鑑權

常見鑒權方式：session/cookie、tockenapi

session/cookie

原理
一、服務器在接收客戶端首次訪問時在服務器端生成一個session，這個session記錄着用戶信息，對外暴露sid，(簽名：經過祕鑰對sid進行簽名處理，加密)，例如session={'xxxxxxx':{userInfo: {}}}，一般保存在Redis中。
二、響應頭中種下這個cookie信息，res.setHeader('Set-Cookie','sid=xxxxxxx')
三、瀏覽器接收到請求響應，會解析響應頭，把sid保存在cookie中，瀏覽器下次請求時，請求頭會帶上該域下的cookie信息
四、服務端接受客戶端請求解析出sid，而後根據這個sid去redis中找對應session，判斷該請求是否合法
五、路由守衛中間件，一般把校驗邏輯寫成一箇中間件，須要鑑權的路由，執行這個中間件