【發布時間】2023-5-25 9:21:48

【作者】Admin001

【瀏覽量】

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

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所遇到的一個問題，其實內容劫持一開始的出發點是好的，是運營商為了加快用戶的訪問速度同時減少自己的流量損耗而做的一個緩存機制，用戶在像服務器請求數據的時候運營商會把用戶的請求轉移到這個緩存池中，如果緩存中有就直接返回，沒有的話再去像服務器請求然后攔截并緩存服務端給用戶的回調數據，這樣一來可以極大的降低運營商像服務器請求的次數，也能加快用戶的訪問，所以出發點是好，但是一些非法的商家對緩存池內部做一次些處理就是直接對返回的內容進行修改，這樣一來我們就會接受到錯誤的數據

文章轉自 coding加油站，如有侵權請聯系刪除