Google的AI安全代理PageBreak已在公司第一方網頁應用程式中識別出逾500個經驗證的跨網站指令碼(XSS)漏洞。XSS是一類注入式漏洞,攻擊者提供的指令碼會在其他使用者的瀏覽器中執行;由於在受信任頁面上執行的程式碼可以該頁面的權限運作,這一直是網頁安全的長期風險。該系統會先針對實際運行的服務測試每個疑似弱點,報告才會提交給產品團隊——這一驗證步驟將可用的攻擊手法與AI模型產生、看似可信但實際有誤的攻擊描述區分開來。此設計旨在確保每份確認的報告都對應一個可實際運作的攻擊手法,而非僅是聽起來合理的說法。

Google於2025年11月以試驗形式啟動PageBreak,並於2026年1月將其列為正式專案。公司的產品安全團隊表示,該系統在敏感的公司網域中發現了XSS漏洞。Google並未透露受影響的應用程式名稱,也未公布嚴重程度分佈;所報告的數字涵蓋其整體網頁應用程式環境。

專責驗證器將誤報率保持在接近零

PageBreak並不將每個警報直接轉交給工程師,而是將每個候選問題發送至專責驗證器。針對XSS漏洞,驗證器會將JavaScript注入相關頁面,並觀察程式碼是否執行。Google表示,該流程將誤報率保持在接近零,並防止未經測試的說法進入產品團隊的審查流程。

該系統驗證的不僅是瀏覽器指令碼。額外檢查可判斷注入的輸入是否會改變資料庫查詢、透過路徑遍歷暴露檔案,或觸發程式碼執行;另有單獨的驗證器檢查可能觸及內部服務的請求。這些檢查使PageBreak能夠評估多類攻擊,同時讓報告聚焦於可行的攻擊路徑。每個候選問題都需具備獨立的證明,工程師才會將其視為漏洞。

大部分掃描由Gemini 3.1 Pro或Gemini 3.5 Flash執行,但攻擊驗證由獨立工具完成;證器並非來自AI代理本身。Google會重複嘗試,因為模型可能放棄有效的路徑,或選擇在實際應用條件下失效的攻擊路徑。

未經驗證的結果不會以確認漏洞的形式離開內部安全工作流程。團隊反而可利用這些結果改進未來的掃描或建立更多驗證器。這一區別非常重要,因為語言模型可能產生聽起來令人信服的詳細安全敘述,但在實際應用中測試時未必能重現——而在大規模應用下,這一差距決定了AI產生的發現究竟是節省工程時間,還是讓時間耗費在分類篩選上。

高保證框架應用程式中發現兩個漏洞

截至9月4日,PageBreak已在數百個基於Google高保證網頁框架構建的應用程式中識別出兩個XSS漏洞。兩起案例都涉及缺少某些防護的內部應用程式或除錯端點。此結果展示了這些框架防護在反覆自動掃描下的表現。框架相關的數字與整體逾500個的發現分開計算,並不包含在內。

PageBreak可透過公司程式碼倉庫檢視跨服務的程式碼路徑。來自實際網路流量的安全資料可將請求的頁面與相關原始碼連結起來,而現有的掃描器也提供對內部網站的認證存取。

這樣的環境使PageBreak有別於公開的模型掃描。外部研究人員通常無法檢視Google的程式碼、流量資料或受保護的測試系統。因此,PageBreak反映的是一個具備深度營運存取權限的內部安全工作流程,而其發現數量並不代表其他組織僅靠執行Gemini就能取得相同成果。

修復工作流程:計劃整合CodeMender

Google計劃將PageBreak與CodeMender更緊密地連結,後者是一個旨在產生安全修復方案的代理。如此一來,產品團隊便能在確認漏洞的同時審查建議的修復方案——形成從發現到修復的完整閉環。公司表示,這種搭配可減輕大量經驗證發現所帶來的工作負擔,但未提供整合的時間表。

類似的驗證問題也影響著加密貨幣軟體,AI工具在該領域可能產生大量看似合理的安全報告。以太坊基金會已使用獨立審查者來重現AI代理產生的發現,而一次Bitcoin紅隊掃描發現,當時報告的問題中僅24.7%附有可重現的證明。

Google尚未表示是否會將PageBreak開放給外部專案使用。

來源:Blockonomi,基於Google官方PageBreak公告。