coffee-cart-cwc

Aiden cwc wrote:

測試目的 (Objective)¶

驗證結帳表單在面對無效電子郵件格式、超長字串以及潛在的 XSS 注入攻擊字元時，是否能正確攔截並提供合理的驗證回饋，避免腳本執行或崩潰。

前置條件 (Preconditions)¶

1. 開啟受測網站：Coffee cart。
2. 加入任意商品至購物車，點擊付款按鈕開啟付款彈窗（Payment Modal）。

測試步驟 (Test Steps)¶

1. Email 格式驗證：
   • 在 Email 欄位輸入不合法格式（如 user@、user@test、plainaddress）。
   • 點擊提交按鈕，觀察瀏覽器或表單提示。
2. 特殊字元與邊界輸入：
   • Name 欄位輸入超長字串（255+ 字元）或包含特殊符號（例如 !@#$%^&*()）。
3. XSS 腳本注入防護測試：
   • 在 Name 欄位輸入 <script>alert('XSS')</script> 或 <img src=x onerror=alert(1)>。
   • 輸入有效 Email 並點擊提交。
4. 觀察成功提示訊息或頁面渲染時，輸入的腳本文字是否被安全跳脫（Escaped）。

預期結果 (Expected Results)¶

1. 步驟 1：不合規定的 Email 格式無法通過驗證，游標自動聚焦錯誤欄位並提示格式錯誤。
2. 步驟 2：超長字元不會造成 Modal 破版變形。
3. 步驟 3-4：系統安全跳脫 HTML 特殊字元，嚴禁彈出任何 JavaScript alert 視窗；提示訊息僅將其視為純文字顯示。

實際測試結果 (Actual Results)¶

• 執行狀態：Pass (大致符合預期 / 具備基礎瀏覽器校驗與無狀態渲染防護)

• 嚴重程度：Low (潛在輸入過濾缺失，但未構成直接漏洞)

• 實際呈現：

  1. Email 基礎格式校驗生效：輸入不合規之電子郵件格式（如缺少 @ 或網域名稱）並點擊送出時，瀏覽器原生表單校驗成功攔截，阻止表單提交，並將游標自動聚焦於該欄位跳出錯誤提示，符合預期。
  2. 超長字元與彈窗排版穩定：在 Name 欄位輸入 255+ 字元或包含各類特殊符號時，輸入框與彈窗 Modal 皆維持原容器寬度，文字自動向後滾動或正常換行，未發生彈窗變形或版面位移破版。
  3. XSS 惡意腳本無執行機會：在 Name 欄位輸入 <script>alert('XSS')</script> 或帶有 onerror 屬性的 Payload 後送出，未跳出任何 JavaScript alert 視窗。送出後系統直接關閉 Modal 並於畫面右下角彈出靜態的 Thanks for your purchase. Please check your email for payment. 成功提示，未在任何 DOM 節點重新反射（Reflect）或渲染使用者剛輸入的姓名內容。
  4. 姓名欄位缺乏格式過濾（Sanitization）：Name 欄位未限制特殊字元（如 HTML 標籤語法 <> 等），使用者輸入任意符號皆能直接通過校驗送出，但因前端未將該內容二次渲染至頁面，故未引發實質的 XSS 危害。

• 原因分析：

  1. 依賴瀏覽器原生 HTML5 表單校驗 (HTML5 Validation Constraint)：
     Email 輸入框使用了 <input type="email" required> 屬性，因此在點擊 Submit 時會自動由瀏覽器層級進行基礎格式正則比對，阻擋不符合規則的字串。
  2. 缺少反射式輸出點降低了 XSS 風險 (No Data Reflection)：
     交易成功後，前端僅觸發預設的常數字串 Toast 提示（Thanks for your purchase. Please check your email for payment.），並未將表單物件內的 name 內容回顯至 DOM（如常見的「感謝您，{name}！」），因此即使使用者輸入惡意標籤，也沒有執行該腳本的進入點（Sink）。
  3. 客戶端缺少業務字元白名單 (Lack of Input Sanitization)：
     Name 欄位未設定 pattern 屬性或 JavaScript 正則表達式進行格式清理，若未來系統擴充將購買者姓名顯示於訂單明細頁或管理後台，此處未跳脫的字元可能會在後續流程中衍生潛在的持久型或反射型 XSS 風險。