CSRF攻擊原理及防護

CSRF攻擊原理及防護

CSRF 跨站點請求僞造(Cross—Site Request Forgery)。

個人理解就是：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來講這個請求是徹底合法的，可是卻完成了攻擊者所指望的一個操做，好比以你的名義發送郵件、發消息，盜取你的帳號，添加系統管理員，甚至於購買商品、虛擬貨幣轉帳等。

• 原理圖：

  圖CSRF原理圖

這是一種對網站的惡意利用，CSRF比XSS更具危險性。想要深刻理解CSRF的攻擊特性咱們有必要了解一下網站session的工做原理。

session詳解

1、術語session

1. session，中文常常翻譯爲會話，其原本的含義是指善始善終的一系列動做/消息，好比打電話時從拿起電話撥號到掛斷電話這中間的一系列過程能夠稱之爲一個session。有時候咱們能夠看到這樣的話「在一個瀏覽器會話期間，...」，這裏的會話一詞用的就是其本義，是指從一個瀏覽器窗口打開到關閉這個期間①。最混亂的是「用戶（客戶端）在一次會話期間」這樣一句話，它可能指用戶的一系列動做（通常狀況下是同某個具體目的相關的一系列動做，好比從登陸到選購商品到結帳登出這樣一個網上購物的過程，有時候也被稱爲一個transaction），然而有時候也可能僅僅是指一次鏈接，也有多是指含義。

2. 然而當session一詞與網絡協議相關聯時，它又每每隱含了「面向鏈接」和/或「保持狀態」這樣兩個含義，「面向鏈接」指的是在通訊雙方在通訊以前要先創建一個通訊的渠道，好比打電話，直到對方接了電話通訊才能開始，與此相對的是寫信，在你把信發出去的時候你並不能確認對方的地址是否正確，通訊渠道不必定能創建，但對發信人來講，通訊已經開始了。「保持狀態」則是指通訊的一方可以把一系列的消息關聯起來，使得消息之間能夠互相依賴，好比一個服務員可以認出再次光臨的老顧客而且記得上次這個顧客還欠店裏一塊錢。這一類的例子有「一個TCP session」或者「一個POP3 session」③。

3. session在web開發語境下的語義又有了新的擴展，它的含義是指一類用來在客戶端與服務器之間保持狀態的解決方案④。有時候session也用來指這種解決方案的存儲結構，如「把xxx保存在session裏」⑤。因爲各類用於web開發的語言在必定程度上都提供了對這種解決方案的支持，因此在某種特定語言的語境下，session也被用來指代該語言的解決方案，好比常常把Java裏提供的javax.servlet.http.HttpSession簡稱爲session。

2、session和cookie

HTTP協議自己是無狀態的，這與HTTP協議原本的目的是相符的，客戶端只須要簡單的向服務器請求下載某些文件，不管是客戶端仍是服務器都沒有必要紀錄彼此過去的行爲，每一次請求之間都是獨立的。

人們發現提供一些按需生成的動態信息會使web變得更加有用，就像給有線電視加上點播功能同樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行爲，另外一方面在服務器端則出現了CGI規範以響應客戶端的動態請求，做爲傳輸載體的HTTP協議也添加了文件上載、cookie這些特性。其中cookie的做用就是爲了解決HTTP協議無狀態的缺陷所做出的努力。至於後來出現的session機制則是又一種在客戶端與服務器之間保持狀態的解決方案。

具體來講cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時咱們也看到，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的，

• 咱們舉個簡單的例子：
  一、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎麼對待了。這種作法就是協議自己支持狀態。 （HTTP協議是無狀態的，而出於種種考慮也不但願使之成爲有狀態的）

  二、發給顧客一張卡片，上面記錄着消費的數量，通常還有個有效期限。每次消費時，若是顧客出示這張卡片，則這次消費就會與之前或之後的消費相聯繫起來。這種作法就是在客戶端保持狀態。

  三、發給顧客一張會員卡，除了卡號以外什麼信息也不紀錄，每次消費時，若是顧客出示該卡片，則店員在店裏的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種作法就是在服務器端保持狀態。

3、cookie機制

正統的cookie分發是經過擴展HTTP協議來實現的，服務器經過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。（純粹的客戶端腳本如JavaScript或者VBScript也能夠生成cookie。）

而cookie的使用是由瀏覽器按照必定的原則在後臺自動發送給服務器的。瀏覽器檢查全部存儲的cookie，若是某個cookie所聲明的做用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。

cookie的內容主要包括：名字，值，過時時間，路徑和域。

• 路徑與域合在一塊兒就構成了cookie的做用範圍。若是不設置過時時間，則表示這個cookie的生命期爲瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期爲瀏覽器會話期的cookie被稱爲會話cookie。會話cookie通常不存儲在硬盤上而是保存在內存裏，固然這種行爲並非規範規定的。若是設置了過時時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過時時間。

4、session機制

session機制是一種服務器端的機制，服務器使用一種相似於散列表(PS :根據關鍵碼值(Key value)而直接進行訪問的數據結構。也就是說，它經過把關鍵碼值映射到表中一個位置來訪問記錄，以加快查找的速度。)的結構（也可能就是使用散列表）來保存信息。

當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

保存這個session id的方式能夠採用cookie，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。通常這個cookie的名字都是相似於SEEESION ID.

EP:weblogic對於web應用程序生成的cookie

JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

的名字就是JSESSIONID。

• 因爲cookie能夠被人爲的禁止，必須有其餘機制以便在cookie被禁止時仍然可以把session id傳遞迴服務器。常常被使用的一種技術叫作URL重寫，就是把session id直接附加在URL路徑的後面，附加方式也有兩種:
  
• 1. 一種是做爲URL路徑的附加信息，表現形式爲
     http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcE
• 1. 另外一種是做爲查詢字符串附加在URL後面，表現形式爲http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

更詳細的session應用問題咱們能夠參考博客：http://www.javashuo.com/article/p-drmwojqt-mu.html

因此咱們總結一下CSRF攻擊步驟：

1. 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A；

2. 在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A；

3. 用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

4. 網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問第三方站點A；

5. 瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

網上看到一個很形象的例子：（CSRF實例攻擊）

受害者 Bob 在銀行有一筆存款，經過對銀行的網站發送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可使 Bob 把 1000000 的存款轉到 bob2 的帳號下。一般狀況下，該請求發送到網站後，服務器會先驗證該請求是否來自一個合法的 session，而且該 session 的用戶 Bob 已經成功登錄。

黑客 Mallory 本身在該銀行也有帳戶，他知道上文中的 URL 能夠把錢進行轉賬操做。Mallory 能夠本身發送一個請求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。可是這個請求來自 Mallory 而非 Bob，他不能經過安全認證，所以該請求不會起做用。

這時，Mallory 想到使用 CSRF 的攻擊方式，他先本身作一個網站，在網站中放入以下代碼： src=」http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory 」，而且經過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發向銀行，而這個請求會附帶 Bob 瀏覽器中的 cookie 一塊兒發向銀行服務器。大多數狀況下，該請求會失敗，由於他要求 Bob 的認證信息。可是，若是 Bob 當時恰巧剛訪問他的銀行後不久，他的瀏覽器與銀行網站之間的 session 還沒有過時，瀏覽器的 cookie 之中含有 Bob 的認證信息。這時，悲劇發生了，這個 url 請求就會獲得響應，錢將從 Bob 的帳號轉移到 Mallory 的帳號，而 Bob 當時絕不知情。等之後 Bob 發現帳戶錢少了，即便他去銀行查詢日誌，他也只能發現確實有一個來自於他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而 Mallory 則能夠拿到錢後逍遙法外。

CSRF漏洞檢測：

• 檢測CSRF漏洞是一項比較繁瑣的工做，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段後再從新提交，若是該提交還有效，那麼基本上能夠肯定存在CSRF漏洞。

隨着對CSRF漏洞研究的不斷深刻，不斷涌現出一些專門針對CSRF漏洞進行檢測的工具，如CSRFTester，CSRF Request Builder等。

• 咱們拿CSRFTester工具爲例，說明一下CSRF漏洞檢測工具的測試原理：
  使用CSRFTester進行測試時，首先須要抓取咱們在瀏覽器中訪問過的全部連接以及全部的表單等信息，而後經過在CSRFTester中修改相應的表單等信息，從新提交，這至關於一次僞造客戶端請求。若是修改後的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，固然此款工具也能夠被用來進行CSRF攻擊。

　

如何使用CSRF漏洞

　 CSRF攻擊的主要目的是讓用戶在不知情的狀況下攻擊本身已登陸的一個系統，相似於釣魚。
　如用戶當前已經登陸了郵箱，或bbs，同時用戶又在使用另一個，已經被你控制的站點，咱們姑且叫它釣魚網站。這個網站上面可能由於某個圖片吸引你，你去點擊一下，此時可能就會觸發一個js的點擊事件，構造一個bbs發帖的請求，去往你的bbs發帖，因爲當前你的瀏覽器狀態已是登錄狀態，因此session登錄cookie信息都會跟正常的請求同樣，純自然的利用當前的登錄狀態，讓用戶在不知情的狀況下，幫你發帖或幹其餘事情。
　

如何抵禦CSRF攻擊

經過 referer、token 或者 驗證碼 來檢測用戶提交。 儘可能不要在頁面的連接中暴露用戶隱私信息。 對於用戶修改刪除等操做最好都使用post 操做。 避免全站通用的cookie，嚴格設置cookie的域。