前言

工具的部分暫時歇一會，今天來聊點不一樣的，來介紹一下這個工具預計會掃哪些漏洞吧。

那今天先從 XSS 開始好了。

XSS 是什麼？

XSS 的全名是 Cross-Site Scripting，中文常稱為跨站腳本攻擊。當網站沒有妥善處理不可信的輸入，讓它成為頁面中可以執行的程式，就可能形成 XSS。

問題在於，這段程式是在目標網站的來源環境中執行。它可能修改頁面內容、讀取該頁面可存取的資料，或利用使用者現有的登入狀態發出請求。實際影響取決於頁面能存取的資源與使用者權限。

對我想做的工具而言，要掃描的大約像下面這樣：

使用者可控制的輸入
        ↓
網站如何處理這份輸入
        ↓
輸入被放進頁面的哪個位置
        ↓
瀏覽器把它當成文字，還是可執行的內容？

有哪些不同的 XSS？

XSS 大約分成下面三類：

直接拼接輸入，會發生什麼事？

假設後端使用下面這種寫法，再把產生的字串當成 HTML 回傳：

# 教學示意：q 是從請求取得的字串。
html = f"<p>搜尋關鍵字：{q}</p>"

這段程式把 q 直接放進 HTML，沒有處理輸入中的特殊字元。

假設輸入是 <b>hello</b>，組出的內容就會是：

<p>搜尋關鍵字：<b>hello</b></p>

瀏覽器會把 <b> 當成標籤，將 hello 顯示為粗體。這個例子說明輸入已經能影響 HTML 結構，但還沒有展示 JavaScript 執行，因此不能只憑粗體效果就宣稱已確認 XSS。

反射型 XSS 的判斷還要往下追：攻擊者能否控制輸入，讓它在實際頁面情境中成為可執行的程式？這取決於輸入位置、網站如何處理字元，以及瀏覽器套用的限制。

輸入出現的位置，也會影響判斷

同樣一個 q，可能被放在不同位置：

<!-- 一般 HTML 文字內容 -->
<p>搜尋關鍵字：使用者輸入</p>

<!-- HTML 屬性值 -->
<input value="使用者輸入">

<!-- JavaScript 字串 -->
<script>
  const keyword = "使用者輸入";
</script>

這些位置有不同的語法規則，因此不能用同一套字元替換方式處理所有情境。尤其應避免把不可信輸入直接插入 JavaScript 程式碼；如果只需要顯示文字，就讓它留在文字內容中。

工具要收集什麼，才有辦法判斷？

回到 AI Web Security Agent，我會把後續的檢查規劃成幾個階段：

這是預計加入的能力。目前的對話工具還沒有完成這些自動驗證。

我會先讓程式保存證據，再讓 AI 整理觀察與下一步。只有表單時，記錄輸入點；只有反射時，記錄反射位置；缺少執行證據時，保留待驗證狀態。

Day 5 簡單的總結

今天稍微介紹了 XSS，並整理了 XSS 的形成過程。

後續分析時，我要確認輸入從哪裡進來、如何被處理、放進頁面的哪個位置，以及瀏覽器最後如何解讀它。這些問題都有對應證據後，工具才有基礎做出更可靠的判斷。

那就……

明天見！