【發(fā)布時間】2023-5-25 9:21:48

【作者】Admin001

【瀏覽量】

網(wǎng)絡(luò)安全對大多數(shù)童鞋來說大多數(shù)時候都是聽其有之，聞之則無，畢竟在現(xiàn)如今web開發(fā)如火如荼的時代，大多數(shù)東西日益成熟，開箱即用，云服務(wù)、框架等已經(jīng)幫我們做了安全方面的防范，不需要我們?nèi)ヌ^于關(guān)心前端網(wǎng)絡(luò)安全，作為一個前端愛好者，最近溫習一下這部分知識，做了個簡單的總結(jié)，順道呈現(xiàn)給各位看官，請注意查收。

xss攻擊

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

根據(jù)攻擊的來源，XSS 攻擊可分為存儲型、反射型和 DOM 型三種

1.1 存儲型攻擊

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

1.將惡意代碼提交到數(shù)據(jù)庫

2.數(shù)據(jù)庫將其保存

3.他用戶查看帖子或者評論

4.服務(wù)端返回惡意代碼并被拼接到客戶端頁面

5.惡意代碼可能通過自執(zhí)行或者用戶點擊執(zhí)行來彈出廣告或者獲取用戶的cookie等個人隱私并上報到攻擊者數(shù)據(jù)庫

1.2 反射型攻擊

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

1.攻擊者在一些鏈接的參數(shù)中加入惡意代碼并誘導用戶點擊

2.用戶通過點擊將請求參數(shù)傳入服務(wù)端

.

3.服務(wù)端獲取參數(shù)并拼接返回給客戶端

4.客戶端執(zhí)行惡意代碼冒充用戶進行權(quán)限操作或者盜取用戶的cookie等個人隱私并上報攻擊者數(shù)據(jù)庫

1.3 DOM型攻擊

1.攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。

2.用戶打開帶有惡意代碼的 URL。

3.用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，前端 JavaScript 取出 URL 中的惡意代碼并執(zhí)行。

4.惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標網(wǎng)站接口執(zhí)行攻擊者指定的操作。

DOM型和反射性都是通過誘導用戶點擊鏈接執(zhí)行，并且都是臨時型的，但是反射型屬于服務(wù)端安全漏洞而DOM型屬于客戶端安全漏洞

2.如何防范xss攻擊

· 

客戶端對用戶輸入的內(nèi)容進行安全符轉(zhuǎn)義，服務(wù)端對上交內(nèi)容進行安全轉(zhuǎn)義

· 

· 

服務(wù)端渲染開啟模板引擎自帶的 HTML 轉(zhuǎn)義功能。

· 

· 

避免內(nèi)聯(lián)事件，盡量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內(nèi)聯(lián)事件的寫法。在 JavaScript 中通過 .addEventlistener() 事件綁定會更安全。

· 

· 

避免拼接 HTML，前端采用拼接 HTML 的方法比較危險，如果框架允許，使用 createElement、setAttribute 之類的方法實現(xiàn)?；蛘卟捎帽容^成熟的渲染框架，如 Vue/React 等。

· 

· 

時刻保持警惕在插入位置為 DOM 屬性、鏈接等位置時，要打起精神，嚴加防范。

· 

· 

通過 CSP、輸入長度配置、接口安全措施等方法，增加攻擊的難度，降低攻擊的后果。

· 

· 

主動檢測和發(fā)現(xiàn)，可使用 XSS 攻擊字符串和自動掃描工具尋找潛在的 XSS 漏洞。

· 

· 

盡量避免三方跨域提交內(nèi)容到服務(wù)端

· 

· 

HTTP-only Cookie: 禁止 JavaScript 讀取某些敏感 Cookie，攻擊者完成 XSS 注入后也無法竊取此 Cookie。

· 

· 

驗證碼：防止腳本冒充用戶提交危險操作。

· 

CSRF攻擊

CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網(wǎng)站執(zhí)行某項操作的目的。

1.1 主動型攻擊

1.受害者訪問a.com并在自己瀏覽器留下a.com的登錄態(tài)

.

2.攻擊者誘導受害者訪問三方網(wǎng)站b.com

3.三方網(wǎng)站b.com植有訪問a.com接口的惡意代碼（刪除/增加/修改等）

4.受害者點擊b.com時候，b.com帶著a.com的登陸憑證冒充受害用戶執(zhí)行對a.com的惡意操作

1.2 被動型攻擊

1.攻擊者在a.com發(fā)布帶有惡意鏈接的帖子或者評論（提交對a.com帶有增刪改的誘導型img/form/a標簽）

2.當其他擁有登錄態(tài)的受害者點擊該評論的惡意鏈接冒用受害者登錄憑證發(fā)起攻擊

CSRF主要是冒用受害者登錄憑證發(fā)起惡意的增刪改并不會竊取受害者隱私信息

2.如何預防CSRF攻擊

1. 禁止三方網(wǎng)站獲取cookie,比如設(shè)置Chrome的SameSite屬性

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

2. 服務(wù)端通過Referer Header 和 Origin Header來進行同源驗證

弊端1：攻擊者可以部分修改或者隱藏referer

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

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

弊端3：HTTPS頁面跳轉(zhuǎn)到HTTP頁面，所有瀏覽器Referer都丟失。

弊端4：對于被動性攻擊并不能識別

其他：某些低版本瀏覽器對origin和referer并不是很穩(wěn)定，各種意想不到的結(jié)果，極其不穩(wěn)定

3. 利用token來鑒別，三方跨站請求并不能獲取到頭部的token，本站的接口在請求前都會在請求頭增加token用于身份鑒權(quán)，三方請求并不會攜帶token

弊端1：token鑒權(quán)對服務(wù)端壓力較大，許專門開辟服務(wù)器用于token鑒權(quán)，耗費服務(wù)器成本并且增加請求時間

弊端2：對于頁面ajax,fetch等異步請求外的其他請求如form提交，a鏈接等需要去挨個加token，不能形成統(tǒng)一的token增加入口，存在部分疏漏

相對而言token鑒權(quán)算是比較好的一種防護措施

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

弊端：前后分離的代碼，后端接口和前端可能不同源，比如前端www.xx.com,后端接口為api.xx.com,前端要拿到后端接口域下的cookie必須將cookie都放在xx.com下面才能保證所有子域都可以拿到，這樣反而增加xss攻擊風險得不償失

DOS攻擊

DOS攻擊通過在網(wǎng)站的各個環(huán)節(jié)進行攻擊，使得整個流程跑不起來，以達到癱瘓服務(wù)為目的。最常見的就是發(fā)送大量請求導致服務(wù)器過載宕機

1. 防范措施

· 

擴容服務(wù)器【有錢公司玩的】

· 

· 

進行實時監(jiān)控，封禁某些惡意密集型請求IP段

· 

· 

增加接口驗證，對于某些敏感接口，進行單個IP訪問次數(shù)限制

· 

· 

進行靜態(tài)資源緩存，隔離源文件的訪問，比如CDN加速

· 

HTTP劫持

1. DNS劫持

DNS劫持又稱域名劫持，是指在劫持的網(wǎng)絡(luò)范圍內(nèi)攔截域名解析的請求，分析請求的域名，把審查范圍以外的請求放行，否則返回假的IP地址或者什么都不做使請求失去響應(yīng)，其效果就是對特定的網(wǎng)絡(luò)不能訪問或訪問的是假網(wǎng)址。其實本質(zhì)就是對DNS解析服務(wù)器做手腳，或者是使用偽造的DNS解析服務(wù)器

解決辦法

DNS的劫持過程是通過攻擊運營商的解析服務(wù)器來達到目的。我們可以不用運營商的DNS解析而使用自己的解析服務(wù)器或者是提前在自己的App中將解析好的域名以IP的形式發(fā)出去就可以繞過運營商DNS解析，這樣一來也避免了DNS劫持的問題。

2.內(nèi)容劫持

內(nèi)容劫持網(wǎng)上很少有提到，這也是在做httpDNS SDK所遇到的一個問題，其實內(nèi)容劫持一開始的出發(fā)點是好的，是運營商為了加快用戶的訪問速度同時減少自己的流量損耗而做的一個緩存機制，用戶在像服務(wù)器請求數(shù)據(jù)的時候運營商會把用戶的請求轉(zhuǎn)移到這個緩存池中，如果緩存中有就直接返回，沒有的話再去像服務(wù)器請求然后攔截并緩存服務(wù)端給用戶的回調(diào)數(shù)據(jù)，這樣一來可以極大的降低運營商像服務(wù)器請求的次數(shù)，也能加快用戶的訪問，所以出發(fā)點是好，但是一些非法的商家對緩存池內(nèi)部做一次些處理就是直接對返回的內(nèi)容進行修改，這樣一來我們就會接受到錯誤的數(shù)據(jù)

文章轉(zhuǎn)自 coding加油站，如有侵權(quán)請聯(lián)系刪除