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

【作者】Admin001

【瀏覽量】

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

xss攻擊

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

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

1.1 存儲型攻擊

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

1.將惡意代碼提交到數據庫

2.數據庫將其保存

3.他用戶(hù)查看帖子或者評論

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

5.惡意代碼可能通過(guò)自執行或者用戶(hù)點(diǎn)擊執行來(lái)彈出廣告或者獲取用戶(hù)的cookie等個(gè)人隱私并上報到攻擊者數據庫

1.2 反射型攻擊

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

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

2.用戶(hù)通過(guò)點(diǎn)擊將請求參數傳入服務(wù)端

.

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

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

1.3 DOM型攻擊

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

2.用戶(hù)打開(kāi)帶有惡意代碼的 URL。

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

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

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

2.如何防范xss攻擊

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

· 

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

· 

CSRF攻擊

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

1.1 主動(dòng)型攻擊

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

.

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

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

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

1.2 被動(dòng)型攻擊

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

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

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

2.如何預防CSRF攻擊

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

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

2. 服務(wù)端通過(guò)Referer Header 和 Origin Header來(lái)進(jìn)行同源驗證

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

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

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

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

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

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

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

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

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

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

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

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

DOS攻擊

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

1. 防范措施

· 

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

· 

· 

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

· 

· 

增加接口驗證，對于某些敏感接口，進(jìn)行單個(gè)IP訪(fǎng)問(wèn)次數限制

· 

· 

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

· 

HTTP劫持

1. DNS劫持

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

解決辦法

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

2.內容劫持

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

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