一文字の入力が、命令へ変わるとき

架空事例：青葉機材の予約システムが入力された説明文、検索条件、画像URLを処理する。攻撃の具体例は防御境界の説明用であり、悪用手順の完全な再現ではない。

顧客が入力した文字列なのに、命令になった

機材を検索する欄がある。利用者が入力した語をSQL文へ連結し、データベースへ送っていた。ある入力は検索語として扱われず、SQL構文の一部として解釈された。

問題の核心は、入力した文字列の印象が悪いことではない。データとして渡したはずの値が、命令を構成する位置へ置かれたことである。

入力を目視して危険な記号を除去する方法は、構文の種類、文字コード、別の表現方法に左右される。OWASP SQL Injection Prevention Cheat Sheetは、SQL文の構造と値を分離するパラメータ化クエリを中心的な防御として示す。2

SQLを生成する段階で、プレースホルダに値を結び付けるなら、検索語がSQLの演算子に見えても値として扱わせられる。ただし、列名やソート方向など、SQL構文そのものを選択させる場所には通常の値プレースホルダを使えない。許可した列名や方向の集合から選ぶ設計が必要になる。

入力を正しく検査しても、出力で壊れることがある

顧客は返却時の注意事項へ、山括弧を含む説明文を入力した。そのままデータベースに保存された。営業の一覧画面は、保存された値をHTMLとして組み立てて表示していた。

保存された情報だから安全とは限らない。HTMLを組み立てる側が、値をマークアップやスクリプトとして解釈させれば、格納型XSSが生じ得る。反射型、DOM-basedのようにデータの経路が違っても、信頼できない値が実行文脈へ混入するという本質は共通する。3

重要なのは「この文字を削る」という一律の規則ではない。HTML本文、属性、URL、JavaScript文字列では、正しい安全化の文脈が違う。テンプレートの自動エスケープが有効でも、安全でないDOM APIで再解釈すれば境界を破ることがある。

顧客が本当に山括弧を説明として入力したいなら、入力を禁止して消すことが唯一の解ではない。データとして保存し、表示先の文脈で文字として扱う。この方針は、内容を壊さずに安全に表示することにつながる。

CSVは実行形式ではない、とは限らない

営業が検索結果を表計算ソフトへ出力した。取引先の自由記述欄には、表計算ソフトが式として解釈し得る文字列が含まれていた。

CSVを書き出した側には、単なる文字列を出力したという感覚がある。しかし開く側のアプリケーションでは、セルの先頭文字や形式によって式として扱われる可能性がある。データの形式がテキストであるというだけで、次の解釈器の働きを保証できない。

SQLインジェクションとCSVの式解釈は技術的には別の経路だが、共通しているのはデータの意味が解釈境界を越えた瞬間に変わることである。「保存時に危険な文字列はなかった」では、開く側の安全を証明できない。

そのため、出力先を明確にして、利用するプログラムの解釈規則に合わせて処理する。出力形式と使用環境を要件へ含める意味はここにある。

OSコマンドへ渡すなら、別の解釈器が登場する

画像処理のため外部プログラムを呼び出す。ファイル名をシェルのコマンド行へ連結すれば、シェルによる記号の解釈が問題になる。SQLのプレースホルダを利用したから、この別の境界まで安全になるわけではない。

可能ならシェルを経由せず、実行ファイルと引数を分離して渡す。さらに、操作できるファイルの範囲、実行ユーザーの権限、出力先を限定する。入力文字列が命令へ変換されない構造を選ぶことと、仮に欠陥があっても被害を広げない権限分離は別の防御である。4

同じ「インジェクション」という名前が付いていても、SQLパーサ、HTML/JavaScript実行環境、シェル、テンプレートエンジンの解釈規則は異なる。試験で脅威と対策を対応させるとき、どの解釈器へ何が渡ったかを確認すれば、対策の種類を取り違えにくい。

「画像URLだけ」の要求が、内部接続になる

取引先が指定した画像URLを、サーバ側で取得して帳票に載せる機能を追加した。利用者のブラウザではなく、青葉機材のサーバが、その指定先へ通信する。

画像であるという名称でも、指定先が社内管理画面やクラウドのメタデータサービスだったらどうなるか。サーバに許された通信能力が、外部入力を通じて悪用される可能性がある。これがSSRFの典型的な境界である。OWASPは、URLの不適切な取扱いとサーバからの内部・外部通信を関連付けて説明している。5

許可する取得先が固定できるなら、許可リストによる制限を検討する。任意の外部URLが必要な場合は、名前解決、リダイレクト、接続先アドレス、内部ネットワークやリンクローカルへの到達を含めて制御する必要がある。入力URLの文字列だけを検査して終わりにしない。

同時に、サーバがそもそも何へ接続できるかをネットワーク側でも制限する。アプリケーションのURL検査だけを信じるのでなく、実行環境の権限を狭くする考え方である。

XSSとCSRFを、似た略語のまま暗記しない

顧客がログイン済みで、別サイトを閲覧した。その別サイトから意図しない状態変更を起こさせるのがCSRFの典型的な構造である。ブラウザが持つCookie等が、利用者の意思とは独立に付与されることが問題になる。

一方XSSは、信頼できない値が対象サイトの実行文脈へ入り込む問題である。XSSが成立すれば、元のサイトのスクリプトとして情報を読んだり状態変更を行ったりできる場合がある。CSRFトークンがあるからXSSまで解決する、とは言えない。

CSRF対策には、操作の性質、トークン、CookieのSameSite属性、Origin確認などを組み合わせる。GETで状態を変更してしまう設計は、HTTPの安全なメソッドという期待にも反する。操作の意味とHTTPメソッドの対応まで考えることが必要になる。1

複数の対策が並ぶときは、どの攻撃者が、どの実行文脈と権限を使っているかを切り分ける。一つの機構であらゆる攻撃を防ぐという説明を警戒したい。

WAFが防いだことと、コードが正しいこと

攻撃らしいリクエストをWAFが遮断した。だからアプリケーションの危険な文字列連結を残してよい、とは結論できない。検知や遮断の仕組みにはルールの適用範囲があり、業務固有の解釈や権限の欠陥まで完全には分からない。

反対に、正しくパラメータ化されたSQLを実装していても、公開APIが無制限に高価な検索を受け付ければ可用性を失う可能性がある。入力の構文安全性、資源の制限、アクセス権限は別の性質である。

青葉機材は、同じ入力を処理する経路を一覧にする。登録時の検査、保存、検索、画面表示、CSV出力、ファイル処理、外部URL取得。どの段階で、どの解釈器に渡されるのかを記録する。攻撃手法の一覧より、境界の一覧が設計と検証に直接つながる。

知識を答案へ戻す

午前Ⅱ。 SQLインジェクションとXSS、CSRF、OSコマンドインジェクション、SSRFは、信頼できない入力が作用する場所が違う。目的に対応する防御を選ぶ。

午後Ⅰ。 入力から外部作用までの経路をたどり、どこでデータが命令として解釈され、誰の権限で実行されるかを読み取る。

午後Ⅱ。 パラメータ化、出力エンコード、URL取得先の制御、実行権限の制限を、想定した攻撃経路と検証方法を含めて説明する。

立ち止まって考える：入力時に危険文字を削除していれば、どの画面や帳票へもそのまま出力してよいか

よくない。解釈器ごとに安全な表現が異なる。入力契約に従った妥当性確認と、出力文脈に応じた安全化は別に行う。

出典と照合範囲

[1] コンプリートテキスト第6・19・21・22章、IPA SAシラバスVer.5.2：セキュリティ要件、インタフェース、Web攻撃の基礎を参照。公式シラバス

[2] OWASP SQL Injection Prevention Cheat Sheet：パラメータ化とSQL構造要素の制限を参照。公式解説

[3] OWASP Cross Site Scripting Prevention Cheat Sheet：文脈に応じた出力処理、DOMの扱いを参照。公式解説

[4] OWASP Injection Prevention Cheat Sheet：信頼できない入力を別の解釈器へ渡す問題を参照。公式解説

[5] OWASP Server-Side Request Forgery Prevention Cheat Sheet：任意URL取得と内部・外部への通信境界を参照。公式解説