Web攻撃と対策｜SQLインジェクション・XSS・CSRFを処理の場所で理解する

SQLインジェクション、XSS、CSRFはいずれもWebアプリに関係しますが、攻撃で利用する仕組みと処理場所が違います。「入力をチェックする」「通信を暗号化する」という一般論だけでは、防ぐべき処理を特定できません。ブラウザ、Webサーバ、DBのどこで何が起きるかを軸に理解しましょう。

事例と三つの攻撃の見取り図

架空のD社の経費アプリには、申請の検索、申請コメントの表示、振込先の変更があります。ログインするとサーバがセッションを発行し、ブラウザはCookieを送って後続要求を行います。実際の攻撃に使うコードではなく、処理境界を示す概念例を使います。

SQLiはDBへ送る命令と値の境界、XSSはブラウザが表示する値と実行内容の境界、CSRFは認証された要求と利用者の意図の境界で考えます。いずれも認可漏れとは別の問題で、認可はすべての操作に必要です。

SQLインジェクション：値を命令として解釈させない

SQLインジェクションは、入力値がSQLの構文として扱われ、意図しない問合せや操作が実行される問題です。入力値を文字列連結でSQLへ埋め込むと、引用符などが値と構文の境界を崩す可能性があります。入力の見た目よりも、DBへどう渡すかを確認します。

避ける構成：SQLの文面に検索入力を文字列連結
基本形：SELECT id FROM requests WHERE owner_id = ?
値の渡し方：ログイン利用者のIDを別にバインド
確認点：動的に組み立てる別の箇所がないか

プレースホルダを使うパラメータ化問合せは、命令の形と入力値を別に渡す方法です。値に記号が含まれてもSQLの命令として扱わせない設計にします。ただしテーブル名や列名、並び順など値としてバインドできない部分は、固定した候補の許可リストから選びます。

型・長さ・業務条件の検証も必要ですが、「危険そうな文字を削る」だけをSQLi対策の中心にしません。利用できる正規の入力を壊したり、別表現を見逃したりするためです。DBの最小権限は成功時の被害範囲を抑えますが、構文の混入自体を直す対策ではありません。

XSS：表示の文脈で安全に扱う

XSSは、信頼できない値がページ内の実行可能な内容として扱われる問題です。サーバが受け取ったコメントを保存し、他の利用者の画面で実行されるなら格納型、要求の値が応答に現れるなら反射型、ブラウザ側の処理が危険なDOM操作へ渡すならDOMベースの観点で調べます。

対策は出力の文脈に合ったエンコードと安全なAPIの利用です。HTML本文、属性、JavaScript、URLでは解釈が違い、HTML用の置換をすべてに使えばよいわけではありません。文章として表示するならtextContentのような文字列として扱う方法を使います。HTMLを許す場合は専用のサニタイザで許可する要素・属性を絞ります。

コメントを文章として表示：textContentへ設定
コメントをHTMLとして連結：避ける
リッチテキスト：許可要素を決めてサニタイズ
URL入力：方式と送信先を検証
補助対策：CSPで許す実行元などを制限

CSPはブラウザに実行元などの制約を伝える仕組みで、防御を補強します。設定に抜けがある場合もあり、危険な出力処理を残したままCSPだけに頼る設計にはしません。入力時に一度処理した値でも、表示する文脈が変われば再確認が必要です。

CSRF：ログイン状態と操作意図を分ける

CSRFは、利用者が攻撃者のページを開くなどした際、ブラウザが認証Cookieを付けて対象サイトへ要求を送り、利用者が意図しない操作が成立する問題です。攻撃者が応答を読めなくても、振込先変更のような状態変更が実行されれば被害になります。

同一オリジンポリシーは、別のオリジンから内容を読むことなどを制限しますが、あらゆる要求送信を禁止するものではありません。オリジンはスキーム、ホスト、ポートの組合せです。認証Cookieが送られる条件と、サーバが要求をどう検証するかを分けて確認します。

対策には、状態変更要求に対するCSRFトークンの検証、Originなどの検証、フレームワークの保護機構があります。トークンは推測困難で利用者のセッション等と適切に結び付け、URLやログへ漏らさないようにします。トークンの有無だけでなく、サーバが検証して拒否することが重要です。

SameSite属性はCookieの送信条件を制限し、CSRFの成立を抑える手段です。ただしsiteとoriginは同じ区切りではなく、同じsiteの別originや属性設定、画面遷移などによって扱いが変わります。独立した要求検証と組み合わせ、GETで状態を変更しないようにします。

オリジン・CORSと、攻撃の分類の注意

CORSはサーバの許可に基づき、ブラウザのJavaScriptが別オリジンの応答へアクセスする仕組みです。CORSを許可しなければすべての要求が届かない、という理解は誤りです。送信方法やContent-Typeなどによって事前確認の有無が変わり、状態変更を守るにはサーバ側の要求検証が必要です。

XSSの分類は単純な三択ではありません。保存した入力をブラウザ側の危険なDOM操作へ渡すなど、格納のされ方と実行する処理場所が組み合わさる例もあります。名称を答えるだけでなく、どこから値が入り、どの出力・APIで実行されるかを追います。

セッションとCookieの保護

セッションIDが利用者のログイン状態を表すなら、それを取得した第三者がなりすましに使う危険があります。十分に推測困難なIDを使い、ログイン時や権限変更時に必要な更新を行い、期限・ログアウト・サーバ側無効化を設計します。ログイン前に固定されたIDをそのまま引き継ぐと、固定化攻撃につながります。

HttpOnlyがあるとCookie値を直接読む手段を抑えられますが、ページ内で動く不正スクリプトは利用者の権限で要求を出せる場合があります。XSSはCSRFトークンを読んで保護を迂回することもあるため、両方を直す必要があります。

TLSは通信経路を保護します。受信した値をSQLやHTMLで危険に解釈する処理、Cookie付き要求の意図を確認しない処理は、暗号化されたままサーバ・ブラウザへ届いて成立し得ます。「HTTPSだからWeb攻撃を防げる」という説明は不十分です。

対策を適用する箇所の点検

この表は一つの操作に一つの対策しか要らないという意味ではありません。検索結果の画面にはXSS対策が必要で、コメント投稿には認可とCSRF対策が必要です。どこで命令・表示・許可の境界を越えるかを全経路で点検します。

演習1：文字列連結

条件：入力した検索語をSQL文へ連結している。

問い：中心となる修正は何か。

解答例：パラメータ化問合せでSQLの構文と検索値を分離して渡す。

根拠と誤答の確認：入力文字の削除だけでは解釈境界を安定して守れません。

演習2：動的な並び順

条件：並べる列名を利用者が選ぶ。列名は値のプレースホルダにできない。

問い：どう選択するか。

解答例：サーバで固定した許可リストの列名へ対応付けて選ぶ。

根拠と誤答の確認：文字列を無検証で連結しないことが重要です。

演習3：コメント表示

条件：コメントは単なる文章でよく、HTML表現は不要。

問い：ブラウザで安全に表示する方法を述べる。

解答例：textContentなど、入力を文字列として扱う方法で表示する。

根拠と誤答の確認：innerHTMLで埋めてからCSPに頼るより、実行可能な文脈へ入れない設計が中心です。

演習4：応答を読めない攻撃者

条件：別サイトから振込先変更要求を送れ、認証Cookieも送信される。攻撃者は応答を読めない。

問い：CSRF被害は成立し得るか。

解答例：成立し得る。応答の読取りを必要とせず、状態変更が実行されるため。

根拠と誤答の確認：同一オリジンポリシーと操作意図の検証を混同しません。

演習5：HttpOnlyの限界

条件：CookieはHttpOnlyだが、画面でXSSが実行される。

問い：不正操作の危険はなくなるか。

解答例：なくならない。不正スクリプトが利用者の権限で要求を送れる場合があるため。

根拠と誤答の確認：Cookieの値を読む制限とCookieが付く要求を発生させる制限は別です。

演習6：HTTPSの役割

条件：全通信はHTTPSだが、サーバはCookieだけを見て振込先変更を受け付ける。

問い：追加すべき検証を答える。

解答例：状態変更要求のCSRFトークン等をサーバで検証し、対象操作の認可も確認する。

根拠と誤答の確認：暗号化は経路保護であり、正規利用者の操作意図の根拠にはなりません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。技術仕様とIPAの公開資料を照合し、特定年度の問題本文を前提にせず学べる構成にしています。

IPA APシラバスVer.7.2

OWASP SQLi防止

OWASP XSS防止

OWASP CSRF防止

OWASP セッション管理

関連テーマを続けて学ぶ

AP科目Bの記述式｜設問・本文根拠・条件から短い答案を作る

認証・アクセス制御・パスワード管理｜本人確認から漏えい対策まで

脆弱性とサプライチェーン対策｜更新・配布・委託先の信頼を点検する

暗号・署名・PKI・TLS｜鍵と証明書の役割を通信の流れで理解する

インシデント対応：証拠・封じ込め・復旧