早在 4 月中，官方就宣佈啟動「機器人留言防堵機制」，看得出來他們很努力想解決這個問題，應該也同步提高了防護等級。
像是在註冊時加入 Cloudflare Turnstile 行為驗證，乍看之下好像真的能解決不少，但實際上現在還是能看到一堆『機器人』在留言區橫行。
我就覺得好奇，這行為到底是怎麼進行的，如果使用 Cloudflare Turnstile 應該有擋下很大一份部分的『機器人』，除非……整個站點只有「註冊、登入」頁面有啟用，其他地方都沒驗證？這我還沒驗證過，不太清楚。
不過我們回到重點，來看看「留言」這一塊到底怎麼發生的。
本文僅分享本人使用自有帳號、在方格子平台合法範圍內之測試觀察。請勿模仿或於未經授權之情況下進行類似行為。
首先，我在自己的頁面建立一筆”私密發佈“（僅只為了這次的行為做的測試）。
建立文章後，我在自己的文章底下留言。
會得到這樣的內容，如截圖：
這時候我看到了一件事情，Headers 的 Authorization 所使用的是 Bearer Token 的驗證方式，這時候我大概知道問題的方向在哪邊了
於是我把相關『內容』，透過Postman 進行“留言動作”
我也成功留言，如截圖：
到這邊，可能！可能！這只是攻擊方的其中一種手法，但這個手法在防堵起來，就可以防堵98%的『機器人留言』了。
至於怎麼做呢？
我先提一個概念，為什麼大部分的攻擊能夠成功，因為攻擊成本符合攻擊者的時間成本，像我剛剛演示的行為，我只是看了瀏覽器的network跟使用 postman 就能達成，攻擊者預期的效果。
這時我們要增加防禦動作、增加攻擊者的行為成本！
先來標記問題：
系統把 API 想成獨立的，不檢查「API 是否是透過頁面正規流程來呼叫」，導致只要有 token 就能打 API。
當攻擊者回到「頁面」的時候，我們就有相關輔助可以上Buff
所以我們把行為導回『API 必須「依附頁面上下文」才能動作』，也就是 「上下文鏈結（Context Binding）」 或 「前端交互綁定」。
例如：讓 API 呼叫必須結合頁面環境的額外條件，像是 CSRF token、頁面注入的一次性驗證碼等
有兩個方法可以配合執行
1. CSRF Token + Page Session 綁定強化
- 留言 API 除了需要 Bearer Token，再加上：
- 必須帶特定的 CSRF Token
- CSRF Token 是「在頁面渲染時注入」
- 在留言頁面載入時，由後端下發一組短效期、一次性的頁面 token。
- 留言 API 強制要求攜帶該 token，且一但使用就失效。
- 效果：API 沒辦法被獨立呼叫，因為 CSRF Token 要依賴當下頁面環境。
2. Referer + Origin 嚴格檢查
- 後端強制留言 API 檢查：
- Referer 必須來自合法的文章頁面
- Origin 必須來自合法網站
- 效果：單純 API 工具直接打包時，不容易偽造 Referer/Origin（雖然可以偽造，但增加難度）。
瀏覽器層 ｜ CSRF Token + Session 綁定 ｜ 防止跨站、Token 搶用
Header 層 ｜ Referer + Origin 檢查 ｜ 防止非瀏覽器、工具直接打
這兩層工作上來後，我預測攻擊者會使用 Selenium、Puppeteer、Playwright 相關可以再瀏覽器進行自動化工具的方式進行『機器人留言』，逼攻擊者回到瀏覽器再透過 Cloudflare Turnstile 的驗證來進行封鎖！
雖然以上寫的都很理想，但攻擊方會有一些意想不到的方式可以繞過，到時候再見招拆招。
對了，我有看到方格子的創辦人有在村長的文章留言，表示方格子系統會上手機驗證！！，
這對攻擊方來說，真的、真的、真的大大增加了攻擊成本啊～～
