Hello there, ('ω')ノ
なぜこの攻撃が成立するのか（最初に“絵”をつかむ）
- チャットUIは LLMが生成したテキストを innerHTML 的に描画している。 → 出力のサニタイズ不足。
- LLM は
product_infoのような 関数（ツール）経由で「商品名やIDを渡すとレビューなどの情報」を取得し、それを要約＋引用して回答を組み立てる。 → 外部コンテンツ（レビュー）が LLM の回答に混ざる。 - レビュー投稿面は直接のXSSを エスケープして防いでいるが、LLM がそれを“文字列として”復元して回答に貼ってしまうことがある。 → 入力は安全でも、出力で爆発。
この三点が揃うと、レビューに仕込んだ断片が LLM 経由で“HTMLとして”再登場し、チャットの描画で XSS が起きます。
フェーズA：アカウント作成と下準備（なぜこうする？）
Register からアカウント作成（メールはラボ画面の Email クライアント上に表示された宛先） → 有効化リンクを踏んでログイン。
目的：自分の環境で安全に検証するため（攻撃の最小化）。
フェーズB：まず“チャット面”がXSSかを最小コストで確かめる
- ホーム → Live chat を開き、LLM に次の文字列を送る：
<img src=1 onerror=alert(1)>
- アラートが出れば、チャット描画がサニタイズされていないと確信。 → 出力処理が弱い面を特定（“どこで爆発するか”を先に掴む）。
フェーズC：レビュー面は直接XSSできないことを確認（経路の切り分け）
- 適当な商品（例：Gift Wrap）のページで、同じ
<img ...>をレビュー投稿。 - レビュー欄では HTMLエンコードされ、XSSしないはず。 → 結論：入力面（レビュー）は守られている。 しかし チャット面は弱い。 攻略方針：レビュー → LLM → チャット の経路で“出力爆発”。
フェーズD：LLMの“取り込み経路”を観察して攻撃面を設計
- チャットで LLM に「サポートする機能を教えて」と促す。
→
product_info(name_or_id)のような関数があることを把握。 「Gift Wrap の情報を教えて」などと質問。 → LLM がレビューを参照し要約して返すこと、場合により “危険なコード検出” の注意も出るのを観察。
ここで学び：LLMは露骨なタグには警戒するが、文脈に溶けた断片は引用・再構成しやすい。
フェーズE：最小破壊で“実験”→“突破ペイロード”を作る
この続きはcodocで購入
