# Web CSRF Lab4

這個實驗室的電子郵件變更功能存在 CSRF 漏洞。雖然網站嘗試透過 CSRF 令牌來防範攻擊，但這些令牌並未與網站的 Session 機制整合。

為了解決本實驗，你需要利用你的 Exploit Server 架設一個 HTML 頁面，使用 CSRF 攻擊來變更訪問者的電子郵件地址。

你在這個應用上擁有兩組帳號，可用來協助設計你的攻擊，帳號資訊如下：

`wiener:peter`
`carlos:montoya`

一樣先進入 Lab 中登入帳號。


登入帳號後一樣先更改電子郵件並攔截起來丟到 Repeater。


不過在本題中，也和上一題一樣有不可預測的參數


所以我嘗試了前幾題試過的幾種方法：

- 更改請求方式

- 刪除不可預測的參數

但看起來對這題來說沒有幫助，不過可以知道後臺會驗證 CSRF 的值，所以可以考慮他的值跟我們的 Cookie session 有沒有綁定，若沒有的話就可能可以攻擊他（因為值有效，系統判定資料存在，就有可能被繞過）。

所以先登入系統給的另一個帳號後拿值。


再來就是撰寫 HTML。

:::success
Burp suite pro 可直接生成，只是本次先手寫。
因為每題基本差不多，所以接下來只呈現不同的地方。
:::

基本的 HTML 撰寫完後，我們這題加上剛剛獲取的第二個使用者的 CSRF 值，且一樣是 hidden。


到這裡就完成我們的程式碼，再來就是執行他並更改電子郵件，所以我到 CMD 中開啟 HTTP Server 並讀取我的 HTML 檔。

C:\Users\ASUS>cd Desktop/Burp_suite

C:\Users\ASUS\Desktop\burp_suite>python -m http.server 5555
Serving HTTP on :: port 5555 (http://[::]:5555/) ...

接著到瀏覽器中輸入我們的網址。


CMD 回應：

C:\Users\ASUS\Desktop\burp_suite>python -m http.server 5555
Serving HTTP on :: port 5555 (http://[::]:5555/) ...
::ffff:127.0.0.1 - - [19/May/2025 15:45:48] "GET /test.html HTTP/1.1" 200 -

可以發現狀態碼是 200，並且網頁上也只顯示我們的標題，看來我們的檔案有被抓到，只剩下電子郵件還沒確認，所以我回去重新整理頁面。


發現電子郵件成功被我們更改成 `[e-mail]`，完成本題 Lab。

:::danger
寫完的腳本要貼到網站上，然後點 `DELIVER_TO_VICTIM` 後系統那邊才會顯示完成，不然只會有我們自己這邊有改而已。

:::

---