前回の原則を破ると何が起きるか
前回のQ-06では、外部からの入力はすべて信用しないという大原則と、検証と無害化という2段の対処を学びました。今回はその原則が破れたときに何が起きるのかを、代表的な3つの攻撃として具体的に見ていきます。3つはばらばらの現象に見えますが、根っこには同じ構造があります。攻撃の再現手順は一切扱わず、どの境界がどう悪用されるかと、すでに学んだ道具でどう防ぐか、その2点だけに集中します。
このスライドのポイント
- Q-06で学んだこと: 外部からの入力はすべて信用しない／対処は「検証」と「無害化」の2段
- この講義の役割: その原則が破れたときに起きる代表的な事故を、3つの攻撃として構造で見る
- 攻撃の再現手順は扱わない。悪用される境界と、防ぎ方だけに集中する
3つの攻撃を構造と防御で定義する
3つの攻撃を、構造と防御の観点だけで定義します。XSSは、入力がブラウザ上で命令、つまりスクリプトとして作動してしまう問題で、防御は表示時の無害化です。CSRFは、ログイン済みの利用者のブラウザを踏み台にして、本人が意図しないリクエストを送らせる問題で、D-07で学んだCookieが自動で付く性質を悪用します。防御は、正規の画面からの送信であることを確認することで、対策トークンなどを使い、現代の枠組みは標準で備えていることが多いです。SQLインジェクションは、入力がL-06で見たSQLの一部として作動してしまう問題で、防御は入力とSQL文を分離することです。
このスライドのポイント
- XSS: 入力がブラウザ上で命令（スクリプト）として作動してしまう問題 → 防御は表示時の無害化（Q-06）
- CSRF: ログイン済みの利用者のブラウザを踏み台に、本人が意図しないリクエストを送らせる問題（D-07のCookieが自動で付く性質の悪用）→ 防御は正規の画面からの送信であることの確認（対策トークン等）
- SQLインジェクション: 入力がSQL（L-06）の一部として作動してしまう問題 → 防御は入力とSQL文の分離（プレースホルダー）
なぜ名前と構造を知る必要があるか
この3つを知らないと、AIが生成したコードが標準の防御を外していることに気づけません。たとえば、利用者の入力をそのままSQL文字列につなげて組み立てるような書き方は、SQLインジェクションの入口になりますが、名前と構造を知らなければ危険とすら思えません。さらに、攻撃の名前を知らないと、AIに監査を頼むための語彙そのものを持てません。守る対象を言葉にできて初めて、確認を依頼できるのです。
このスライドのポイント
- 名前を知らないと、AIの生成コードが標準の防御を外していても気づけない
- 例: 入力をそのままSQL文字列につなげる書き方は、SQLインジェクションの入口
- 名前を知らないと、AIに監査を頼むための語彙そのものを持てない
全部「入力が命令になる」の変奏
3つの攻撃は、悪用される境界がそれぞれ違います。XSSはブラウザの表示境界、CSRFはCookieの自動送信、SQLインジェクションはDBへの命令境界です。作動する場所が違うので、防ぐ場所も違います。しかし一段引いて眺めると、3つはすべて「入力が命令になる」という同じ構造の変奏にすぎません。だからこそ、Q-06で学んだ検証と無害化、そして命令とデータの分離という考え方が、そのまま防御の柱になります。
このスライドのポイント
- 悪用される境界はそれぞれ違う: XSS=ブラウザの表示境界／CSRF=Cookieの自動送信／SQLインジェクション=DBへの命令境界
- 作動する場所が違うので、防ぐ場所も違う
- しかし俯瞰すると、3つはすべて「入力が命令になる」という同じ構造の変奏
- だから防御の柱はQ-06と同じ: 検証・無害化・命令とデータの分離
経費アプリで被害のイメージをつかむ
経費アプリで被害のイメージをつかみます。XSSでは、備考欄に書き込まれた文字列が、それを閲覧した別の社員のブラウザ上で作動し、セッションが狙われます。CSRFでは、利用者が偽のサイトを開いた拍子に、ログイン状態を悪用されて、申請が勝手に承認されてしまいます。SQLインジェクションでは、検索欄からの入力がDBへの命令として作動し、全社員の申請データが抜き取られます。いずれの被害も、防御はすでに学んだ道具で足ります。
このスライドのポイント
- XSS: 備考欄に書き込まれた文字列が、閲覧した別社員のブラウザ上で作動し、セッションが狙われる
- CSRF: 偽のサイトを開いた拍子に、ログイン状態を悪用され、申請が勝手に承認される
- SQLインジェクション: 検索欄の入力がDBへの命令として作動し、全社員の申請データが抜かれる
- いずれの被害も、防御は既出の道具で足りる
技術サンプル: 3攻撃の対応表
技術サンプルとして、3つの攻撃を1枚の対応表にまとめました。名前、悪用する境界、発生条件、防御、確認の質問の5列で並べています。表の防御の列を見てください。すべてQ-06で学んだ無害化と、現代の枠組みが標準で備えている装備で埋まっています。特別な魔法があるわけではなく、標準を外さないことが防御そのものです。AIにコードを書かせたときは、この標準を無効化している箇所がないかを、この表を使って監査させてください。
このスライドのポイント
- 種別: table
- 目的: 3攻撃を「名前・悪用する境界・発生条件・防御・確認の質問」で一望する
XSSとSQLインジェクションの違い
混同しやすいのは、XSSとSQLインジェクションです。どちらも入力が命令として作動する点は同じですが、作動する場所が違います。XSSはブラウザの表示のところで作動し、SQLインジェクションはDBへの命令のところで作動します。作動する場所が違うということは、防御する場所も違うということです。表示のための無害化と、SQL文からの入力の分離は、別々の対処だと押さえてください。
このスライドのポイント
- どちらも「入力が命令として作動する」点は同じ
- 違うのは作動する場所: XSS=ブラウザの表示のところ／SQLインジェクション=DBへの命令のところ
- 作動する場所が違う＝防御する場所も違う（表示時の無害化 vs SQL文からの入力の分離）
バイブコーディングでの確認点
確認点です。この3観点での監査を、P章で学んだテストと同じように定期的に実行してください。特に、生のSQL文字列を組み立てている箇所と、生のHTMLを挿入している箇所は、機械的に探し出せます。AIへの質問例としては、「このコードの中で、生のSQL文字列を組み立てている箇所と、生のHTMLを挿入している箇所をすべて一覧にしてください」と頼むとよいでしょう。見つかった箇所は、正当な理由があるかを一つずつ確かめます。
このスライドのポイント
- 3観点の監査を、P章のテストと同様に定期実行する
- 「生のSQL文字列を組み立てているか」「生のHTMLを挿入しているか」は機械的に探せる（AIに探させる）
- 見つかった箇所は、正当な理由があるかを一つずつ確認する
一問一答とまとめ
最後に一問一答です。3つの攻撃に共通する構造は何でしょうか。……答えは、入力が命令として作動してしまうこと、です。だからこそ、検証と無害化、そして命令とデータの分離という同じ道具で防げます。30秒でまとめます。XSS・CSRF・SQLインジェクションは、それぞれブラウザの表示・Cookieの自動送信・DBへの命令という違う境界を悪用しますが、根はすべて入力が命令になる変奏であり、標準を外さないことが防御です。次回は、アプリ自身が持つ秘密の守り方、秘密情報とAPIキーへ進みます。関連資料は「AIアプリのセキュリティ超入門」「セキュリティ用語50」「AIアプリ公開前チェックリスト100」です。
このスライドのポイント
- 一問一答:「3攻撃に共通する構造は？」→ 入力が命令として作動してしまうこと
- 30秒まとめ: 3攻撃は違う境界を悪用するが、根はすべて「入力が命令になる」の変奏。標準を外さないことが防御
- 次回: Q-08 秘密情報とAPIキー（アプリ自身の秘密の守り方）
- 関連資料: 「AIアプリのセキュリティ超入門」「セキュリティ用語50」「AIアプリ公開前チェックリスト100」
