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

【作者】Admin001

【瀏覽量】

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

xss攻擊

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

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

1.1 存儲(chǔ)型攻擊

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

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

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

3.他用戶查看帖子或者評(píng)論

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

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

1.2 反射型攻擊

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

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

2.用戶通過點(diǎn)擊將請(qǐng)求參數(shù)傳入服務(wù)端

.

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

4.客戶端執(zhí)行惡意代碼冒充用戶進(jìn)行權(quán)限操作或者盜取用戶的cookie等個(gè)人隱私并上報(bào)攻擊者數(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)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。

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

2.如何防范xss攻擊

· 

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

· 

· 

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

· 

· 

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

· 

· 

避免拼接 HTML，前端采用拼接 HTML 的方法比較危險(xiǎn)，如果框架允許，使用 createElement、setAttribute 之類的方法實(shí)現(xiàn)。或者采用比較成熟的渲染框架，如 Vue/React 等。

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

驗(yàn)證碼：防止腳本冒充用戶提交危險(xiǎn)操作。

· 

CSRF攻擊

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

1.1 主動(dòng)型攻擊

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

.

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

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

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

1.2 被動(dòng)型攻擊

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

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

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

2.如何預(yù)防CSRF攻擊

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

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

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

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

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

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

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

弊端4：對(duì)于被動(dòng)性攻擊并不能識(shí)別

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

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

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

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

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

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

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

DOS攻擊

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

1. 防范措施

· 

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

· 

· 

進(jìn)行實(shí)時(shí)監(jiān)控，封禁某些惡意密集型請(qǐng)求IP段

· 

· 

增加接口驗(yàn)證，對(duì)于某些敏感接口，進(jìn)行單個(gè)IP訪問次數(shù)限制

· 

· 

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

· 

HTTP劫持

1. DNS劫持

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

解決辦法

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

2.內(nèi)容劫持

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

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