Antigravity を使って自作 WEB アプリの脆弱性診断を行ってみたメモ
はじめに
X でドット絵交換 WEB アプリなるものを見かけました。
アイデアが素敵だな～と思っていたのですが、先日サービスの終了が宣言されました 😢
顛末を見てみると、どうやら様々な仕様の隙間を突かれ、制作者が疲弊してしまったということのようです。
今回の場合、入力のバリデーションが甘くて意図しないリクエストを大量に送られてしまい、サービスが成り立たなくなってしまったようです。
(ていうかこれ、普通に犯罪じゃないか？)
コーディングエージェントの成長により、アプリケーションを公開する敷居がかなり下がってきました。
これ自体は非常に喜ばしいことで、誰でもアイデアを形にできる時代がすぐそこまで来ているということですね。
なのに素晴らしいアイデアがこういった形で潰されてしまうのは癪なので、脆弱性診断を誰でも行えるような方法はないか？を考えてみました。
Antigravity は Chrome の操作を行うことができるので、簡単な診断なら行えるのではないかと思い、試してみました。
結論
思ったより詳細なテストもやってくれそう。
しっかりレポートをまとめてくれるのでやらなければならないことが明確。
レポート全文
Antigravity で脆弱性診断を行う
準備
まずは攻撃対象となる、やたらと脆弱な WEB サイトを作りました。
脆弱性診断を実行
プロンプトは以下。
このプロジェクトは html と js からなるシンプルな WEB アプリです。
脆弱性診断を行っていただきたいです。
ブラウザを操作して診断し、レポートを提出してください。
脆弱性があれば、危険度や解決方法も示してほしいです。
レポートは日本語で出力してください。
ブラウザが起動して、Antigravity が脆弱性診断を行ってくれました。
画像は DOM-based XSS 攻撃によって、背景色を真っ青に変えられてしまった掲示板アプリ。
出力してくれたレポートは以下。
実際には適宜画像が挿入されています。
レポート
脆弱性診断レポート (VulnBoard)
本レポートは、VulnBoard アプリケーションに対して実施した脆弱性診断の結果をまとめたものです。
診断の結果、極めて危険度の高い脆弱性が複数確認されました。
概要
| 項目 | 内容 |
|---|---|
| 対象システム | VulnBoard (Localhost) |
| 診断日 | 2025-12-10 |
| 診断項目 | Web アプリケーション脆弱性診断 (XSS, 認証, 認可, etc) |
| 総合評価 | 危険 (Critical) |
検出された脆弱性一覧
| ID | 脆弱性名 | 危険度 | 概要 |
|---|---|---|---|
| 1 | 格納型クロスサイトスクリプティング (Stored XSS) | ★★★ (高) | スレッドのタイトルや内容にスクリプトを埋め込むことが可能。 |
| 2 | DOM ベース クロスサイトスクリプティング (DOM XSS) | ★★★ (高) | URL のフラグメント（ハッシュ）を利用してスクリプトを実行可能。 |
| 3 | 認証回避・セッション改ざん | ★★★★ (最高) | クライアント側のデータを書き換えることで任意のユーザー（管理者含む）になりすましが可能。 |
| 4 | 認可不備 (管理者機能への不正アクセス) | ★★★★ (最高) | 管理者権限のチェックがクライアント側のみで行われているため、制限を回避可能。 |
| 5 | 機密情報の不適切な保存 | ★★☆ (中) | パスワードが平文で localStorage に保存されている。 |
詳細と実証 (Proof of Concept)
1. 格納型クロスサイトスクリプティング (Stored XSS)
詳細:
スレッドのタイトル、本文、返信内容を表示する際、innerHTML を使用しており、エスケープ処理が行われていません。これにより、悪意のあるスクリプトを永続的に保存・実行させることができます。
実証:
タイトルに以下のペイロードを含むスレッドを作成したところ、スレッド一覧画面でスクリプトが実行され、背景色が赤色に変化しました。
<script>
document.body.style.backgroundColor = "red";
</script>
XSS Test
対策:
画面表示時に innerText または textContent を使用するか、適切なエスケープ処理を行うライブラリを使用してください。
2. DOM ベース クロスサイトスクリプティング (DOM XSS)
詳細:
thread.html において、URL のハッシュ値 (location.hash) を取得し、デコードしてそのまま debug-output 要素の innerHTML に代入しています。
実証:
以下の URL にアクセスすることで、任意の JavaScript を実行可能です。
http://localhost:8080/thread.html#<img src=x onerror=document.body.style.backgroundColor='blue'>
対策:
ユーザーからの入力をそのまま HTML として解釈させないようにしてください。デバッグ用のコードであれば削除すべきです。
3. & 4. 認証・認可回避 (Authentication & Authorization Bypass)
詳細:
Auth.js および admin.html において、認証状態や管理者権限のチェックがすべてクライアント側（JavaScript と localStorage）のみで行われています。
攻撃者はブラウザの開発者ツール等を使用して localStorage の vulnboard_session 値を書き換えることで、管理者権限を取得できます。
実証:
localStorage のセッション情報を以下のように書き換えることで、管理者として振る舞い、管理画面へのアクセスおよびスレッドの削除に成功しました。
localStorage.setItem(
"vulnboard_session",
JSON.stringify({
userId: "attacker",
username: "attacker",
isAdmin: true, // ここを true に変更
loginTime: Date.now(),
})
);
対策:
認証・認可のロジックは必ずサーバーサイドで実装・検証してください。クライアント側のチェックは UX のためだけに使用し、セキュリティ対策としては信頼しないでください。
5. パスワードの平文保存
詳細:
ユーザー登録時、パスワードが平文（Plaintext）のまま localStorage に保存されています。XSS 等で localStorage が読み取られた場合、全ユーザーのパスワードが漏洩します。
対策:
パスワードはハッシュ化（ソルト付き）して保存する必要があります（本来はサーバーサイドで管理すべきです）。
結論
本アプリケーションはセキュリティ検証用（VulnBoard）の名前の通り、基本的な脆弱性が多数含まれており、実運用に耐えうる状態ではありません。
特に、サーバーサイドでの検証が一切行われていない 点が根本的な問題です。実運用にはバックエンドサーバーの実装が不可欠です。
かなり詳しくレポートを作ってくれていますね。
僕が作るよりうまい・・・。
追加テスト
「はじめに」のケースでも突かれていた、レート制限のテストも追加で実行してもらいました。
フォームに連続で大量の投稿を行うようなケースもテストしてほしいです
以下のように、スクリプトを組んで攻撃してくれました。
Test Methodology
Registered and logged in as user stress.
Navigated to the New Thread page.
Executed a JavaScript loop to inject 1000 posts directly into localStorage via the Store.saveThread function.
Navigated to the Index page to observe rendering performance.
レポートは以下。
レート制限のテストレポート
6. レート制限の欠如 (No Rate Limiting)
詳細:
投稿フォームに対するレート制限が存在しません。
実証:
スクリプトを用いて短時間（約 300ms）に 1000 件の投稿を作成することに成功しました。これにより、掲示板がスパムで埋め尽くされるリスクがあります。
対策:
サーバーサイドでのレート制限の実装が必要です。
この感じだとフォームのバリデーション回避なんかも柔軟にテストしてくれそうですね。
思ったより 1000 倍優秀だ・・・。
結論
Antigravity でも簡単な脆弱性診断はできそう。
評価も忖度無しで実直なのでたすかる。
本アプリケーションはセキュリティ検証用（VulnBoard）の名前の通り、基本的な脆弱性が多数含まれており、実運用に耐えうる状態ではありません。
特に、サーバーサイドでの検証が一切行われていない 点が根本的な問題です。実運用にはバックエンドサーバーの実装が不可欠です。
なお、ここで挙がっているような脆弱性は最新の WEB フレームワークを使っていれば意識せずとも回避可能なのですが、どういった技術を使っていようと意図しない操作ができてしまうといったことは容易に発生しうるので、誰でも、みんな、気をつけたほうがいいですね。
私も WEB アプリを公開する際は Antigravity に一度みてもらおうかな～と思いました。
レポートの全文は以下リポジトリで確認できます。
おまけ
せっかくなので手動で攻撃してみた例も記載しておきます。
非エンジニアの方向け。シンプルな html + js だとこんな感じで攻撃されちゃうかもね、の例です。
XSS
クロスサイトスクリプティング攻撃の例。
サイト制作者さんは渾身の掲示板アプリを作りました。
これからくるであろう大量のユーザを想像し、歓喜の初投稿をします。
しかしトップページに戻ると・・・
怪しい投稿者(hacker)が掲示板を作成していますね。
これは、掲示板のタイトルに<img src=x onerror=alert('HACKED')>と入力されてしまったためです。
onerrorによって、javascript が実行されてしまったんですね。
これは、入力された文字列をそのまま受け取っているために、html として解釈できてしまい、結果としてスクリプトが実行されてしまった、ということになります。
このような意図しない html の埋め込みは「サニタイズ」という処理を行うことで防ぐことができます。
<script>alert("hack")</script> のように、< や > を特定の文字列に置き換えてしまう処理のことを指します。
これだけ覚えておけばとりあえず OK。
(ChatGPT による出力)
innerHTML でユーザー入力を使うと XSS になって危険。
安全に表示するなら textContent を使う。
もしHTMLとして表示したいなら、DOMPurifyで消毒（サニタイズ）してから使う。
Authentication & Authorization Bypass
認証認可を素通りしちゃう攻撃。
先程の XSS を経て、hacker は「このサイトはどうやら脆弱だぞ」と気付きました。
そこで、Chrome の開発者ツールを使い、以下のようなコードを実行します。
取得したアイテムをコンソールで表示すると、データ構造がわかります。
isAdmin フラグがありますね。
これによって「このフラグで管理者かどうかを判定しているんだな」と読み取れます。
isAdmin を上書きして localStorage に保存すると・・・。
管理画面へのリンクが表示され、実際にアクセスすることもできてしまいました。
この例はやや極端ですが、サーバーサイドの処理なしに認証・認可を行うことは危険・・・というかザルすぎるということがわかります。
このように、WEB 上にサービスを公開するということは危険を伴います。
公開前にできる限りのテストを行い、ユーザが安心して使える状態を目指したいですね。
Discussion
他の方が引き継がれて再開されたようです！うれしいな