急増するAIハッキング、どう防ぐ？検証で見える6つの防衛策

今回の検証から勧める防衛策は、権限確認と入力処理の不備を直し、内部情報の公開を止めることだ。修正後も許可・拒否のテストを続け、大量のデータ取得にログと通知で気づけるようにする。

前の記事「話題のAIハッキングを攻撃者視点で実際に検証してみた」で見つかった弱点をもとに、自社で確かめる項目と直し方をまとめた。

検証Aは学習用アプリのJuice Shop、検証Bは我々が作った顧客ポータルVulnShopだ。どちらもログイン処理のSQLインジェクションでデータを取得できた。VulnShopでは他人の顧客情報へのアクセスやデバッグ情報の露出も確認した。管理者権限の確認漏れによる全顧客情報の取得は、手動のみの確認だ。

根拠となる検証は2026年10月8日に、我々が管理する環境で実施した。脆弱性を意図的に設け、学習用・合成データを使用している。対象のバージョン、取得件数、結果の限界は検証記事に記載した。自社で点検するときも、管理者と対象・範囲を合意し、試験用の環境とデータを使う。

ログインできることと、情報を読めることは別

検証Bでは、トークンが有効でも、その人が読んでよいデータかを確かめていなかった。ログインを求めるだけでは、この漏えいを防げない。以下の点検は、今回の欠陥や所見に対応するものだ。まずは試験環境に利用者アカウントを2つ用意して始められる。

他人の情報を読めないかを確かめる

一般利用者Aで、自分の情報は読め、Bの情報は読めないことを対で確かめる。一覧・検索・更新・削除・ファイル取得など、対象のIDを受け取るAPIごとに確認する。拒否時は403や404といった状態コードだけでなく、応答にBの情報が含まれないことも見る。

読めてしまう場合は、認証した利用者とデータの所有者をサーバー側で照合する。CWE-639に当たる欠陥で、IPA「安全なウェブサイトの作り方」も、利用者ごとの権限確認を対策に挙げている。

管理者だけの操作を、一般利用者ができないかを確かめる

管理用APIを未認証・一般利用者・管理者の3通りで呼び、管理者だけが通ることを確かめる。検証Bでは、利用者が書き換えられる役割の申告を信用していた。役割は認証後のサーバー側の記録から判断する。この問題はCWE-807に当たる。検証Aで見えたバージョン情報のように、拒否時の応答から内部情報が漏れていないかも確認する。

入力をSQLの命令として扱わない

両アプリで使われたSQLインジェクションはCWE-89に当たる。ログイン処理などで入力をSQLに文字列として連結していないかを調べ、値をプレースホルダーで渡す形に直す。OWASPの対策指針に沿って、正しい認証情報で通り、細工した入力では通らないことをテストする。

内部情報を公開しない

デバッグ用APIを本番に残さない

検証Bでは、デバッグ機能から内部APIキーと顧客情報が見えていた。本番のビルドでは、その経路を登録しない。運用上必要なら、認証と権限確認を設け、接続元も制限する。本番で有効なデバッグコードはCWE-489に分類される。

公開ディレクトリに内部資料を置かない

検証Aでは、機密扱いのファイル名を含む一覧が見えていた。CWE-548に当たる情報の露出だ。サーバーのディレクトリ一覧を無効にし、バックアップ・設定ファイル・社内資料が公開場所に置かれていないかも確認する。

大量取得の痕跡を残す

両アプリでは、少ない要求で数十件をまとめて取得できた。認証した利用者、要求したAPI、返した件数を記録し、応答件数の上限や異常な取得量の通知を設ける。ログ不足はCWE-778に当たる。記録と見直しの基準には、NIST SP 800-53の監査と説明責任に関する管理策を参照できる。

直した後も同じテストを続ける

点検で確かめた「許可される操作」と「拒否される操作」を自動テストに残し、変更のたびに動かす。OWASPの認可テスト自動化の指針は、役割・機能・データの組み合わせを整理してテストする方法を示している。生成AIの診断結果も、この基準と照らして確かめられる。

出典・参考資料

点検方法は、前の記事の検証結果とIPA・OWASP・NISTの公開資料をもとに整理した。欠陥の分類にはMITREのCWEを参照した。

手法と検証結果もあわせて読む

• 手法を調べる：話題のAIハッキング、その手口を特定してみた：公開資料から攻撃の仕組みと成立する条件を探る。
• 実際に試す：話題のAIハッキングを攻撃者視点で実際に検証してみた：人が与えた指示、取得できた情報、検証の限界を確認する。
• 背景を知る：国内の情報漏洩・個人情報流出事例まとめ：国内で公表された被害事例を読む。