浅谈Web前端安全策略xss和csrf，及又该如何预防？
Web前端安全策略xss和csrf的攻擊和防御
- 一、XSS跨站請求攻擊
- 1、什么是XSS
- 2、場景模擬
- 3、XSS的攻擊類型
- 4、如何防御XSS
- 二、XSRF跨站請求偽造
- 1、什么是csrf
- 2、場景模擬
- （1）場景一
- （2）場景二
- 3、CSRF的特點
- 4、CSRF攻擊方式
- 5、CSRF常見的攻擊類型
- 6、如何防御csrf
- 三、CSRF與 XSS 區別
- 四、結束語
隨著前端技術的不斷革新，前端早已不再是簡簡單單的做頁面了。現在的前端網站上會涉及到大量用戶的數據和隱私，那這些用戶數據安全嗎？答案并不是肯定的。因此，這個時候前端安全就顯得尤為重要。如果網站沒有做安全策略，那么就會很容易被攻擊者通過某些不為人知的操作，獲取到用戶的隱私信息。
在下面的這篇文章中，將講解前端安全策略 xss 和 csrf ！一起來一探究竟吧~
一、XSS跨站請求攻擊
1、什么是XSS
跨站腳本攻擊，縮寫為XSS(Cross Site Scripting)，是利用網頁的漏洞，通過某種方式給網頁注入惡意代碼，使用戶加載網頁時執行注入的惡意代碼。
2、場景模擬
假設有一個博客網站，這個博客網站的安全做的很差。那么我現在準備在這個網站上發布一篇博客，在發布的這篇博客中，我嵌入了一段
寫完之后呢，我成功把這篇博客發送出去了。現在，只要有人在這個網站查看我這篇博客文章，那么我就能輕松地收割訪問者的 cookie ，這就是一個簡單的 xss 攻擊流程。
了解完 xss 的定義之后，我們再來了解 xss 的攻擊類型。
3、XSS的攻擊類型
XSS一共分為三種：
- 非持久型跨站（也叫反射型）
- 持久型跨站（也叫存儲型）
- DOM跨站
（1）非持久型跨站（反射型）
①攻擊步驟
- 攻擊者構造出特殊的 URL ，其中包含惡意代碼。
- 用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在HTML中返回給瀏覽器。
- 用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
- 惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
②攻擊場景
反射型 XSS (也被稱為非持久性 XSS )漏洞常見于通過 URL 傳遞參數的功能，如網站搜索、跳轉等。
③攻擊方式
由于需要用戶主動打開惡意的 URL 才能生效，攻擊者往往會結合多種手段誘導用戶點擊。
POST 的內容也可以觸發反射型 XSS，只不過其觸發條件比較苛刻（需要構造表單提交頁面，并引導用戶點擊），所以非常少見。
（2）持久型跨站（存儲型）
①攻擊步驟
- 攻擊者將惡意代碼提交到目標網站的數據庫中。
- 用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在HTML中返回給瀏覽器。
- 用戶瀏覽器接收到響應后解析執行，混在其中的惡意代碼也被執行。
- 惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
②攻擊場景
存儲型 XSS 攻擊 (也被稱為持久型 XSS )常見于帶有用戶保存數據功能的網站，如論壇發帖、商品評論、用戶私信等。
③危害
它是最危險的一種跨站腳本，相比反射型 XSS 和 DOM 型 XSS 具有更高的隱蔽性，危害更大，因為它不需要用戶手動觸發。
任何允許用戶存儲數據的 web 程序都可能存在存儲型 XSS 漏洞，當攻擊者提交一段 XSS 代碼后，被服務器端接收并存儲，當所有瀏覽者訪問某個頁面時都會被 XSS 。
（3）DOM跨站
①攻擊步驟
- 攻擊者構造出特殊的 URL ，其中包含惡意代碼。
- 用戶打開帶有惡意代碼的 URL 。
- 用戶瀏覽器接收到響應后解析執行，前端 JavaScript 取出 URL 中的惡意代碼并執行。
- 惡意代碼竊取用戶數據并發送到攻擊者的網站，或者冒充用戶的行為，調用目標網站接口執行攻擊者指定的操作。
②危害
DOM通常表示 html、xhtml和xml中的對象，使用 DOM 可以允許程序和腳本動態的訪問和更新文檔的內容、結構和樣式。它不需要服務器解析響應的直接參與，觸發 XSS 依靠的是瀏覽器端的DOM解析 。
對以上三種xss的攻擊類型進行一個小結：
反射型跟存儲型的區別是：
存儲型 XSS 的惡意代碼存在數據庫里，反射型 XSS 的惡意代碼存在 URL 里。
DOM 型跟前兩種區別是：
DOM 型 XSS 攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬于服務端的安全漏洞。
三者的對比：
| 反射型 XSS | URL | HTML |
| 存儲型 XSS | 后端數據庫 | HTML |
| DOM 型 XSS | 后端數據庫/前端存儲/URL | 前端 JavaScript |
4、如何防御XSS
只要有輸入數據的地方，就可能存在 XSS 危險。
（1）設置HttpOnly
在 cookie 中設置 HttpOnly 屬性后， js 腳本將無法讀取到 cookie 信息。
（2）轉義字符串
XSS 攻擊大多都是由數據的輸入和輸出作為攻擊點進行攻擊，所以針對這幾個攻擊點，對數據進行過濾。
其中，數據包括前端數據的輸入和輸出、后端數據的輸入和輸出。
那么，數據過濾是什么？又如何對數據進行過濾呢？
數據過濾是對輸入格式的檢查，例如：郵箱，電話號碼，用戶名，密碼……等，按照規定的格式輸入。它不僅僅是前端負責，后端也要做相同的過濾檢查。如果沒有做數據過濾，攻擊者完全可以繞過正常的輸入流程，直接利用相關接口向服務器發送設置。
因此，可以通過封裝過濾函數對數據進行過濾，目的是將幾個攻擊者常用的輸入內容都進行轉移，這樣就避免了瀏覽器解析成了腳本代碼。
function escape(str) {str = str.replace(/&/g, '&');str = str.replace(/</g, '<');str = str.replace(/>/g, '>');str = str.replace(/"/g, '&quto;');str = str.replace(/'/g, ''');str = str.replace(/`/g, '`');str = str.replace(/\//g, '/');return str; }（3）白名單
對于顯示富文本來說，不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。這種情況通常采用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標簽和標簽屬性實在太多，更加推薦使用白名單的方式。
二、XSRF跨站請求偽造
1、什么是csrf
跨站請求偽造(Cross-site request forgery)，也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF，是一種挾制用戶在當前已登錄的 Web 應用程序上執行**非本意的操作**的攻擊方法。
如：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。
2、場景模擬
（1）場景一
假設你正在購物，看重了某個商品，商品 id 是 100 。同時這個商品的付費接口時 xxx.com/pay?id=100 ，但是沒有任何驗證。這個時候我是攻擊者，我看中了一個商品，id 是 200 。那么，我如何讓你來為我付款？
這個時候我像你發送了一封郵件，郵件標題很是吸引人。但郵件正文隱藏著 <img src = "xxx.com/pay?id=200"> 。你一查看郵件，一點擊，就幫我購買了 id 是 200 的商品。
（2）場景二
要完成一次 CSRF 攻擊，受害者必須依次完成兩個步驟：
- 登錄受信任網站 A ，并在本地生成 Cookie 。
- 在不登出 A 的情況下，訪問危險網站 B 。
看到這里，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。是的，確實如此，但是呢，你可能沒辦法保證以下情況不會發生哦！比如：
- 你不能保證你登錄了一個網站后，不再打開一個 tab 頁面并訪問另外的網站。
- 你不能保證你關閉瀏覽器了后，你本地的 Cookie 會立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認為關閉瀏覽器就等于退出登錄/結束會話了…）
上述中所說的網站，可能是一個存在其他漏洞，但又很受信任的且經常被人訪問的網站。
3、CSRF的特點
- 攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生。
- 攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作，而不是直接竊取數據。
- 整個過程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。
4、CSRF攻擊方式
跨站請求可以用各種方式：
- 圖片 URL 、超鏈接、 CORS 、 Form 提交等等。部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤。
- CSRF通常是跨域的，因為外域通常更容易被攻擊者掌控。但是如果本域下有容易被利用的功能，比如可以發圖和鏈接的論壇和評論區，攻擊可以直接在本域下進行，且這種攻擊方式更加危險！
5、CSRF常見的攻擊類型
1）GET類型的CSRF
GET 類型的 CSRF 是較為容易攻擊的一種方式，只需要一個 HTTP 請求，攻擊者一般做出以下操作：
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >在受害者訪問含有這個 img 的頁面后，瀏覽器會自動向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發出一次 HTTP 請求。 bank.example 就會收到包含受害者登錄信息的一次跨域請求。
2）POST類型的CSRF
這種類型的 CSRF 攻擊通常使用的是一個自動提交的表單，如：
<form action="http://bank.example/withdraw" method=POST><input type="hidden" name="account" value="xiaoming" /><input type="hidden" name="amount" value="10000" /><input type="hidden" name="for" value="hacker" /> </form> <script> document.forms[0].submit(); </script>訪問該頁面后，表單會自動提交，相當于模擬用戶完成了一次 POST 操作。
POST 類型的攻擊通常比 GET 要求更加嚴格一點，但仍并不復雜。任何個人網站、博客，被黑客上傳頁面的網站都有可能是發起攻擊的來源，后端接口不能將安全寄托在僅允許 POST 上面。
3）鏈接類型的CSRF
比起其他兩種用戶打開頁面就中招的情況，鏈接類型的 CSRF 比較不常見，因為這種攻擊方式需要用戶點擊鏈接才會觸發。這種類型通常是在論壇等平臺發布的圖片中嵌入惡意鏈接，或者以廣告的形式誘導用戶中招，攻擊者通常會以比較夸張的詞語誘騙用戶點擊，例如：
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">重磅消息！！ <a/>6、如何防御csrf
1）驗證碼
增加驗證，例如密碼、短信驗證碼、指紋等等，強制用戶必須與應用進行交互，才能完成最終請求。這種方式能很好的遏制 csrf ，但是用戶體驗相對會比較差。
2）Referer check
referer 代表請求的來源，不可以偽造。后端可以通過寫一個過濾器來檢查請求的 headers 中的 referer ，檢驗是不是本網站的請求。但缺點是瀏覽器可以關閉 referer ，且低版本的瀏覽器會存在偽造 Referer 的風險。
referer 和 origin 的區別，只有 post 請求會攜帶 origin 請求頭，而 referer 不論何種情況下都帶。
3）token
token 是最普遍的一種防御方法，后端先生成一個 token ，之后將此放在數據庫中并發送給前端，那么前端發送請求時就會攜帶這個 token ，后端通過校驗這個 token 和數據庫中的 token 是否一致，以此來判斷是否是本網站的請求。
示例：
用戶登錄輸入賬號密碼，請求登錄接口，后端在用戶登錄信息正確的情況下將 token 放到數據庫中，并返回 token 給前端，前端把 token 存放在 localstorage 中，之后再發送請求都會將 token 放到 header 中。
后端寫一個過濾器，攔截 POST 請求，注意忽略掉不需要 token 的請求，比如登錄接口，獲取 token 的接口，以免還沒有獲取 token 就開始檢驗 token 。
校驗原則：數據庫中的 token 和前端 header 中的 token 一致的 post 請求，則說明校驗成功，給客戶端放行。
三、CSRF與 XSS 區別
CSRF 與 XSS 區別有以下兩點：
- 通常來說 CSRF 是由 XSS 實現的，CSRF 時常也被稱為 XSRF（CSRF 實現的方式還可以是直接通過命令行發起請求等）。
- 本質上講，XSS 是代碼注入問題，CSRF 是 HTTP 問題。 XSS 是內容沒有過濾導致瀏覽器將攻擊者的輸入當代碼執行，CSRF 則是瀏覽器在發送 HTTP 請求時候進行。
四、結束語
對于前端來說，防范攻擊還是很重要的，因為誰也預測不了我們寫的網站何時會受到攻擊。
本文很淺很淺的談論了關于Web前端安全中的兩種攻擊模式，希望對大家有幫助！
有不理解或有誤的地方也歡迎評論區評論或私信我交流~
- 關注公眾號 星期一研究室 ，不定期分享學習干貨，學習路上不迷路~
- 如果這篇文章對你有用，記得點個贊加個關注再走哦~
總結
以上是生活随笔為你收集整理的浅谈Web前端安全策略xss和csrf，及又该如何预防？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 手机怎么清理微信缓存？
- 下一篇： 阴阳师卖药郎怎么获得