網絡安全對前端童鞋來講大多數時候都是聽其有之,聞之則無,畢竟在現現在前端如火如荼的時代,大多數東西日益成熟,開箱即用,雲服務、框架等已經幫咱們作了安全方面的防範,不須要咱們去太過於關心前端網絡安全,做爲一個前端愛好者,最近溫習一下這部分知識,作了個簡單的總結,順道呈現給各位看官,請注意查收。前端
Cross-Site Scripting(跨站腳本攻擊)簡稱 XSS,是一種代碼注入攻擊。攻擊者經過在目標網站上注入惡意腳本,使之在用戶的瀏覽器上運行。利用這些惡意腳本,攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等,進而危害數據安全。ajax
根據攻擊的來源,XSS 攻擊可分爲存儲型、反射型和 DOM 型三種數據庫
存儲型攻擊常發生在微博論壇等用戶發帖、提交文章評論等地方
後端
反射型攻擊主要發生在一些帶有誘導性的連接的按鈕郵件等
api
DOM型和反射性都是經過誘導用戶點擊連接執行,而且都是臨時型的,可是反射型屬於服務端安全漏洞而DOM型屬於客戶端安全漏洞
跨域
CSRF(Cross-site request forgery)跨站請求僞造:攻擊者誘導受害者進入第三方網站,在第三方網站中,向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證,繞事後臺的用戶驗證,達到冒充用戶對被攻擊的網站執行某項操做的目的。瀏覽器
CSRF主要是冒用受害者登陸憑證發起惡意的增刪改並不會竊取受害者隱私信息
緩存
弊端:SameSite試用階段,兼容性不是很理想安全
弊端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並非很穩定,各類意想不到的結果,極其不穩定
弊端1:token鑑權對服務端壓力較大,許專門開闢服務器用於token鑑權,耗費服務器成本而且增長請求時間
弊端2:對於頁面ajax,fetch
等異步請求外的其餘請求如form
提交,a連接等須要去挨個加token
,不能造成統一的token
增長入口,存在部分疏漏
相對而言token鑑權算是比較好的一種防禦措施
cookie
來認證,在每一個請求的參數都附加scrfCookie='隨機數'
防護參數,並在cookie
中混入該防護參數值,服務端將請求頭部的cookie
中防護cookie
參數和請求參數所帶的該參數進行比對弊端: 先後分離的代碼,後端接口和前端可能不一樣源,好比前端www.xx.com
,後端接口爲api.xx.com
,前端要拿到後端接口域下的cookie
必須將cookie
都放在xx.com
下面才能保證全部子域均可以拿到,這樣反而增長xss
攻擊風險得不償失
DOS攻擊經過在網站的各個環節進行攻擊,使得整個流程跑不起來,以達到癱瘓服務爲目的。最多見的就是發送大量請求致使服務器過載宕機
DNS劫持又稱域名劫持,是指在劫持的網絡範圍內攔截域名解析的請求,分析請求的域名,把審查範圍之外的請求放行,不然返回假的IP地址或者什麼都不作使請求失去響應,其效果就是對特定的網絡不能訪問或訪問的是假網址。其實本質就是對DNS解析服務器作手腳,或者是使用僞造的DNS解析服務器
DNS的劫持過程是經過攻擊運營商的解析服務器來達到目的。咱們能夠不用運營商的DNS解析而使用本身的解析服務器或者是提早在本身的App中將解析好的域名以IP的形式發出去就能夠繞過運營商DNS解析,這樣一來也避免了DNS劫持的問題。
內容劫持網上不多有提到,這也是在作httpDNS SDK所遇到的一個問題,其實內容劫持一開始的出發點是好的,是運營商爲了加快用戶的訪問速度同時減小本身的流量損耗而作的一個緩存機制,用戶在像服務器請求數據的時候運營商會把用戶的請求轉移到這個緩存池中,若是緩存中有就直接返回,沒有的話再去像服務器請求而後攔截並緩存服務端給用戶的回調數據,這樣一來能夠極大的下降運營商像服務器請求的次數,也能加快用戶的訪問,因此出發點是好,可是一些非法的商家對緩存池內部作一次些處理就是直接對返回的內容進行修改,這樣一來咱們就會接受到錯誤的數據