Bug Bounty Secrets The attack Technique No One Talks About
三句話摘要
透過 CORS 錯誤設定與 CSRF 攻擊，將受害者的銀行提款帳戶竄改為攻擊者帳戶。 CORS 接受任意來源加上 SameSite=None，足以讓 JSON API 的 CSRF 防線徹底失效，攻擊者只需一個自動提交的 HTML 表單即可竄改受害者的財務帳戶。 Client ID 參數缺乏驗證是入口：修改 Client ID 會觸發 403，但完整移除該參數後伺服器仍回應 200 並建立 Payout Method，代表後端邏輯只對「值不符」做防護，對「參數不存在」完全無處理。
重點整理
重點- 1
Client ID 參數缺乏驗證是入口：修改 Client ID 會觸發 403，但完整移除該參數後伺服器仍回應 200 並建立 Payout Method，代表後端邏輯只對「值不符」做防護，對「參數不存在」完全無處理。
- 2
CORS 錯誤設定使跨站請求成立：伺服器的 Access-Control-Allow-Origin 接受任意來源，且 Cookie 的 SameSite=None，使得從第三方頁面發出的請求能夾帶受害者的 Session，繞過同源政策。
- 3
text/plain 編碼繞過 JSON CSRF 防護：JSON API 通常被認為天然防 CSRF，因為瀏覽器預設不允許跨站發送 application/json。但透過 `<form enctype="text/plain">` 將 JSON Key-Value 包在隱藏欄位中，可讓 POST body 符合 JSON 格式，同時屬於「簡單請求」不觸發 Preflight。
- 4
攻擊結果直接影響資金安全：攻擊者只需誘使受害者開啟惡意頁面，表單自動提交後，受害者帳戶的 Payout Method 即被更新為攻擊者的 Routing Number 與 Account Number，後續所有付款直接轉至攻擊者。
實用技巧與重點
乾貨- 工具：Burp Suite（Intercept、Repeater、HTTP History）
- 漏洞類型：CORS Misconfiguration + CSRF（Cross-Site Request Forgery）
- 目標端點：POST 請求，JSON body 含 `funding_type`、`entity`、`account_number`、`bank_routing_number`
- URL 參數：`client_id`（移除後仍 200 OK → 無後端驗證）
- CORS 問題：伺服器接受任意 Origin，Cookie `SameSite=None`
- 繞過技巧：HTML form `method=POST`、`enctype=text/plain`，以隱藏 Input 拼出 JSON Key-Value Pair
- 自動觸發：`<script>` tag 呼叫 `document.forms[0].submit()`
- 攻擊影響：受害者的 Payout Method 被替換 → 資金轉至攻擊者帳戶
- 成功回應：`200 OK`，body 含 `"Payout Method Created Successfully"`
結論
結論“CORS 接受任意來源加上 SameSite=None，足以讓 JSON API 的 CSRF 防線徹底失效，攻擊者只需一個自動提交的 HTML 表單即可竄改受害者的財務帳戶。”
完整解析
詳細這支影片示範的是一個結合 CORS 錯誤設定與 CSRF 的真實 Bug Bounty 案例。目標網站的支付頁面提供了一個讓用戶綁定提款帳戶的功能，用戶可輸入 Routing Number 與 Account Number，點擊 Continue 後，前端會送出一個帶有 JSON body 的 POST 請求。講者首先用 Burp Suite 攔截這個請求，注意到 URL 中帶有 `client_id` 參數。他先嘗試修改 `client_id` 的值，伺服器正確回應 403 Forbidden，看似有做身份驗證。然而，當他將整個 `client_id` 參數從 URL 中完整刪除後，伺服器卻回應 200 OK，並附上「Payout Method Created Successfully」的訊息，代表後端只驗證了參數值是否合法，卻沒有檢查參數本身是否存在。
發現這個邏輯漏洞後，講者進一步審查 HTTP History，發現伺服器的 CORS 設定允許任意來源（Access-Control-Allow-Origin 不限制），且回應的 Cookie 屬性 SameSite 設為 None。這兩個條件加在一起，代表任何第三方網站都可以發出帶有受害者 Cookie 的跨站請求，伺服器也會照單全收。
接下來講者構造了攻擊 Payload：一個標準 HTML 表單，`method` 設為 POST、`enctype` 設為 `text/plain`，內含隱藏的 Input 欄位，其 `name` 與 `value` 拼合後恰好構成合法的 JSON 格式，填入的是攻擊者自己的 Account Number 與 Routing Number。頁面載入時，一段 `<script>` 自動呼叫 `document.forms[0].submit()` 提交表單。由於 `text/plain` 屬於瀏覽器允許的「簡單請求」類型，不會觸發 CORS Preflight 檢查，請求連同受害者的 Session Cookie 直接送達伺服器。
結果是：只要受害者點開攻擊者發送的連結，其帳戶的提款設定即在無感知的情況下被替換為攻擊者的銀行資訊，往後所有提款或 Payout 都會流向攻擊者帳戶。這個案例的嚴重性在於攻擊完全靜默、不需任何用戶輸入，且直接影響財務安全，因此在 Bug Bounty 平台上通常可獲得相當高的賞金。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
