在前面的章節中，我們討論了許多後端處理不當導致的漏洞。今天我們要將視角轉向前端，探討許多開發者常犯的迷思：「在前端用 JavaScript 計算 Token 或進行驗證，網站就安全了嗎？」我們將透過DVWA的JavaScript模組，示範如何運用瀏覽器內建的開發者工具，進行前端邏輯分析與驗證繞過。

• 什麼是 JavaScript 前端邏輯漏洞？

在 Web 開發中，JavaScript 運行在使用者的瀏覽器（客戶端）環境。這意味著：

1.程式碼完全透明：使用者可以隨時檢視、除錯甚至修改任何 JavaScript 原始碼。
2.執行流程可被操控：透過瀏覽器的 Console，使用者可以任意呼叫頁面中的全域函式、修改變數數值或覆寫驗證邏輯。

如果網站將安全防禦寄託在前端 JavaScript，攻擊者只需開啟開發者工具分析邏輯，就能輕鬆複製或繞過驗證。

• DVWA 實作與觀察（Low 安全等級）

1. 觀察失敗狀況

若直接將輸入框的 ChangeMe 改成 success 並點擊 Submit，畫面上會顯示：
You got the phrase wrong.
這是因為表單送出時，後端除了比對輸入的字串，還會比對隱藏欄位中的 Token。當我們只改了輸入框文字，隱藏欄位中的 Token 依然是舊的 ChangeMe 所算出來的值，導致比對失敗。

2. DevTools 逆向分析原始碼

按下 F12 開啟開發者工具，切換至 Sources 頁面檢視前端腳本，找到 Token 的生成函式：
function generate_token() {
var phrase = document.getElementById("phrase").value;
document.getElementById("token").value = md5(rot13(phrase));
}
前端定義了 generate_token() 函式。
該函式會讀取輸入框的值，依序進行 rot13 混淆與 md5 雜湊，並將結果自動填入隱藏的 token 欄位中。

3.控制台（Console）操作與破解

既然 Token 生成邏輯完全曝露在前端，我們可以直接透過 Console 控制執行：

1.將輸入框文字改為 success。
2.切換至 DevTools 的 Console 頁面，手動執行函式：
generate_token();

3.回到頁面再次點擊 Submit，伺服器比對無誤，成功出現 Well done!。

• 如何正確防禦 Client-side 邏輯漏洞？

1.零信任客戶端：
牢記所有前端傳回的資料（包含 Cookie、Header、隱藏欄位、JS 計算結果）都是不可信的，後端必須進行獨立的完整性與合法性校驗。

2.核心安全邏輯後端化：
Token 產生、權限校驗、金額計算等關鍵業務邏輯，必須完全放在伺服器端（Server-side）進行。

3.前端混淆不等於安全：
代碼混淆（如 UglifyJS）只能增加逆向工程的時間成本，無法從根本提升安全性。