CSRF · 前端筆記

[TOC] # 概述 CSRF的全稱是Cross Site Request Forgery，即跨域請求偽造。 ## 跨站點的請求跨站點請求的來源是其他站點，如目標網站的刪除文章功能接收到惡意網站客戶端發出的刪除文章請求，目標網站應該區分請求來源。 ## 請求是偽造的如果請求的發出不是用戶的意愿，這個請求就是偽造的。 ## 一個場景網站A有刪除文章功能，通常是用戶點擊“刪除鏈接”時才刪除指定的文章，如www.a.com/blog/del?id=1。用CSRF實現的步驟如下： * 在惡意網站B編寫一個CSRF頁面，如何發出GET請求到目標網站A？ * 利用AJAX跨域時帶上目標域的會話 * 用代碼<img src=[http://www.a.com/blog/del?id=1](http://www.a.com/blog/del?id=1) /> * 然后欺騙已登錄過目標網站A的用戶訪問CSRF頁面攻擊過程有三個關鍵點：跨域發出一個GET請求、可以無JavaScript參與，請求是身份認證后。 # CSRF類型按照請求類型可分為GET類型和PSOT類型的CSRF攻擊。若按照攻擊類型分類，可分享HTML CSRF攻擊、JSON HiJacking 攻擊和Flash CSRF攻擊。 ## HTML CSRF攻擊這一類是最普遍的CSRF攻擊，HTML中能設置src/href等鏈接地址的標簽都可以發起一個GET請求，如 * <link href=""> * <img src=""> * <img lowsrc=""> * <img dynsrc=""> * <meta http-equiv="refresh" content="0; url="> * <iframe src=""> * <frame src=""> * <script src=""> * <bgsound src=""> * <embed src=""> * <video src=""> * <audio src=""> * <a href=""> * <table background=""> * ... CSS樣式中的： * @import "" * background: url\(""\) * ... 還有通過JavaScript動態生成的標簽對象或CSS對象發起的GET請求，而發出POST請求只能通過form提交。 ## JSON HiJacking 攻擊 JSON HiJacking 基礎非常經典，攻擊過程是CSRF，不過是對AJAX 響應中最長久的JSON數據進行的挾持攻擊。現代瀏覽器都提供了原生的方法 JSON.parse\(str\) 來轉換為JS對象。低版本IE可通過引入JOSN3，不要使用eval。在JS里可以為對象定義一些setter函數，這樣的話就存在了可以利用的漏洞。 ``` window.__defineSetter__('x', function() { alert('x is being assigned!'); }); window.x=1; ``` 當利用<script>標簽請求外部的一個JSON API時，如果返回的是數組型，就可以利用竊取數據。比如有這樣的一個API：[http://www.test.com/friends返回的數據是JSON](http://www.test.com/friends返回的數據是JSON) Array： ``` [{'user':'test01','age':18},{'user':'test02,'age':19},{'user':'test03','age':20}] ``` 在攻擊頁面上插入以下的代碼，就可以獲取到用戶的所有的朋友的信息。 ``` <script> Object.prototype.__defineSetter__('user',function(obj) {alert(obj); } ); </script> <script src="http://www.test.com/friends"></script> ``` ## Flash CSRF攻擊 # 危害 * 篡改目標網站上的用戶數據 * 盜取用戶隱私數據 * 作為其他攻擊向量的輔助攻擊手法 * 傳播CSRF蠕蟲 # 防御 ## 檢查 http referer 根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自于同一個網站，比如需要訪問 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用戶必須先登陸 bank.example，然后通過點擊頁面上的按鈕來觸發轉賬事件。這時，該轉帳請求的 Referer 值就會是轉賬按鈕所在的頁面的 URL，通常是以 bank.example 域名開頭的地址。而如果黑客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站構造請求，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客自己的網站。因此，要防御 CSRF 攻擊，銀行網站只需要對于每一個轉賬請求驗證其 Referer 值，如果是以 bank.example 開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。 <br> 然而，這種方法并非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對于 Referer 的具體實現可能有差別，并不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴于第三方（即瀏覽器）來保障，從理論上來講，這樣并不安全。事實上，對于某些瀏覽器，**比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值**。如果 bank.example 網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設為以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。 **同時，有以下場景無法獲取referer**： 1. 直接在瀏覽器地址欄中輸入地址； 2. 使用location.reload()刷新（location.href或者location.replace()刷新有信息）； 3. 在微信對話框中，點擊鏈接進入微信自身的瀏覽器； 4. 掃碼進入QQ或者微信的瀏覽器； 5. 直接新窗口打開一個頁面； 2017.8.3更新新版本Chrome測試，新窗口頁面依然有document.referrer 6. 從https的網站直接進入一個http協議的網站（Chrome下親測）； 7. a標簽設置rel="noreferrer"（兼容IE7+）； 8. meta標簽來控制不讓瀏覽器發送referer； <br> ## 使用一次性 token > token 是一段隨機的數字字母值，經常出現在表單的隱藏項中，原理是無法通過 ajax 獲取到外域頁面的 token 值（雖然可以通過 html 標簽帶動 ajax 跨域請求，如 <img src='http://...' ?onload="load\_ajax\_func\(\)">，但無法通過 javascript 讀取返回的內容）。 > <br> ## 使用驗證碼（降低用戶體驗） > 當同域頁面上有xss 漏洞時，可以通過 ajax 獲取到其他頁面的 token； > > token 如果出現在 get 參數中，也容易通過 refer的方式泄露； > > 此時只能通過驗證碼來防范csrf 了。 <br>