全棧必知系列之網絡安全篇

網絡安全對前端童鞋來講大多數時候都是聽其有之，聞之則無，畢竟在現現在前端如火如荼的時代，大多數東西日益成熟，開箱即用，雲服務、框架等已經幫咱們作了安全方面的防範，不須要咱們去太過於關心前端網絡安全，做爲一個前端愛好者，最近溫習一下這部分知識，作了個簡單的總結，順道呈現給各位看官，請注意查收。

xss攻擊

Cross-Site Scripting（跨站腳本攻擊）簡稱 XSS，是一種代碼注入攻擊。攻擊者經過在目標網站上注入惡意腳本，使之在用戶的瀏覽器上運行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進而危害數據安全。

根據攻擊的來源，XSS 攻擊可分爲存儲型、反射型和 DOM 型三種

1.1 存儲型攻擊

存儲型攻擊常發生在微博論壇等用戶發帖、提交文章評論等地方

1. 將惡意代碼提交到數據庫
2. 數據庫將其保存
3. 他用戶查看帖子或者評論
4. 服務端返回惡意代碼並被拼接到客戶端頁面
5. 惡意代碼可能經過自執行或者用戶點擊執行來彈出廣告或者獲取用戶的cookie等我的隱私並上報到攻擊者數據庫

1.2 反射型攻擊

反射型攻擊主要發生在一些帶有誘導性的連接的按鈕郵件等

1. 攻擊者在一些連接的參數中加入惡意代碼並誘導用戶點擊
2. 用戶經過點擊將請求參數傳入服務端
3. 服務端獲取參數並拼接返回給客戶端
4. 客戶端執行惡意代碼冒充用戶進行權限操做或者盜取用戶的cookie等我的隱私並上報攻擊者數據庫

1.3 DOM型攻擊

1. 攻擊者構造出特殊的 URL，其中包含惡意代碼。
2. 用戶打開帶有惡意代碼的 URL。
3. 用戶瀏覽器接收到響應後解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
4. 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

DOM型和反射性都是經過誘導用戶點擊連接執行，而且都是臨時型的，可是反射型屬於服務端安全漏洞而DOM型屬於客戶端安全漏洞

2.如何防範xss攻擊

• 客戶端對用戶輸入的內容進行安全符轉義，服務端對上交內容進行安全轉義
• 服務端渲染開啓模板引擎自帶的 HTML 轉義功能。
• 避免內聯事件，儘可能不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內聯事件的寫法。在 JavaScript 中經過 .addEventlistener() 事件綁定會更安全。
• 避免拼接 HTML，前端採用拼接 HTML 的方法比較危險，若是框架容許，使用 createElement、setAttribute 之類的方法實現。或者採用比較成熟的渲染框架，如 Vue/React 等。
• 時刻保持警戒在插入位置爲 DOM 屬性、連接等位置時，要打起精神，嚴加防範。
• 經過 CSP、輸入長度配置、接口安全措施等方法，增長攻擊的難度，下降攻擊的後果。
• 主動檢測和發現，可以使用 XSS 攻擊字符串和自動掃描工具尋找潛在的 XSS 漏洞。
• 儘可能避免三方跨域提交內容到服務端
• HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入後也沒法竊取此 Cookie。
• 驗證碼：防止腳本冒充用戶提交危險操做。

CSRF攻擊

CSRF（Cross-site request forgery）跨站請求僞造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操做的目的。

1.1 主動型攻擊

1. 受害者訪問a.com並在本身瀏覽器留下a.com的登陸態
2. 攻擊者誘導受害者訪問三方網站b.com
3. 三方網站b.com植有訪問a.com接口的惡意代碼（刪除/增長/修改等）
4. 受害者點擊b.com時候，b.com帶着a.com的登錄憑證冒充受害用戶執行對a.com的惡意操做

1.2 被動型攻擊

1. 攻擊者在a.com發佈帶有惡意連接的帖子或者評論（提交對a.com帶有增刪改的誘導型img/form/a標籤）
2. 當其餘擁有登陸態的受害者點擊該評論的惡意連接冒用受害者登陸憑證發起攻擊

CSRF主要是冒用受害者登陸憑證發起惡意的增刪改並不會竊取受害者隱私信息

2.如何預防CSRF攻擊

1. 禁止三方網站獲取cookie,好比設置Chrome的SameSite屬性

弊端：SameSite試用階段，兼容性不是很理想

2. 服務端經過Referer Header 和 Origin Header來進行同源驗證

弊端1：攻擊者能夠部分修改或者隱藏referer

<img src="http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy="no-referrer">

弊端2: 某些瀏覽器或者操做會丟失origin頭部，好比302重定向

弊端3：HTTPS頁面跳轉到HTTP頁面，全部瀏覽器Referer都丟失。

弊端4：對於被動性攻擊並不能識別

其餘： 某些低版本瀏覽器對origin和referer並非很穩定，各類意想不到的結果，極其不穩定

3. 利用token來鑑別，三方跨站請求並不能獲取到頭部的token，本站的接口在請求前都會在請求頭增長token用於身份鑑權，三方請求並不會攜帶token

弊端1：token鑑權對服務端壓力較大，許專門開闢服務器用於token鑑權，耗費服務器成本而且增長請求時間

弊端2：對於頁面ajax,fetch等異步請求外的其餘請求如form提交，a連接等須要去挨個加token，不能造成統一的token增長入口，存在部分疏漏

相對而言token鑑權算是比較好的一種防禦措施

4. 利用雙重cookie來認證，在每一個請求的參數都附加scrfCookie='隨機數'防護參數，並在cookie中混入該防護參數值，服務端將請求頭部的cookie中防護cookie參數和請求參數所帶的該參數進行比對

弊端： 先後分離的代碼，後端接口和前端可能不一樣源，好比前端www.xx.com,後端接口爲api.xx.com,前端要拿到後端接口域下的cookie必須將cookie都放在xx.com下面才能保證全部子域均可以拿到，這樣反而增長xss攻擊風險得不償失

DOS攻擊

DOS攻擊經過在網站的各個環節進行攻擊，使得整個流程跑不起來，以達到癱瘓服務爲目的。最多見的就是發送大量請求致使服務器過載宕機

1. 防範措施

• 擴容服務器【有錢公司玩的】
• 進行實時監控，封禁某些惡意密集型請求IP段
• 增長接口驗證，對於某些敏感接口，進行單個IP訪問次數限制
• 進行靜態資源緩存，隔離源文件的訪問，好比CDN加速

HTTP劫持

1. DNS劫持

DNS劫持又稱域名劫持，是指在劫持的網絡範圍內攔截域名解析的請求，分析請求的域名，把審查範圍之外的請求放行，不然返回假的IP地址或者什麼都不作使請求失去響應，其效果就是對特定的網絡不能訪問或訪問的是假網址。其實本質就是對DNS解析服務器作手腳，或者是使用僞造的DNS解析服務器

解決辦法

DNS的劫持過程是經過攻擊運營商的解析服務器來達到目的。咱們能夠不用運營商的DNS解析而使用本身的解析服務器或者是提早在本身的App中將解析好的域名以IP的形式發出去就能夠繞過運營商DNS解析，這樣一來也避免了DNS劫持的問題。

2.內容劫持

內容劫持網上不多有提到，這也是在作httpDNS SDK所遇到的一個問題，其實內容劫持一開始的出發點是好的，是運營商爲了加快用戶的訪問速度同時減小本身的流量損耗而作的一個緩存機制，用戶在像服務器請求數據的時候運營商會把用戶的請求轉移到這個緩存池中，若是緩存中有就直接返回，沒有的話再去像服務器請求而後攔截並緩存服務端給用戶的回調數據，這樣一來能夠極大的下降運營商像服務器請求的次數，也能加快用戶的訪問，因此出發點是好，可是一些非法的商家對緩存池內部作一次些處理就是直接對返回的內容進行修改，這樣一來咱們就會接受到錯誤的數據