基本情報のXSS・SQLインジェクション・CSRFの違いと覚え方

基本情報技術者試験のセキュリティ問題で、XSS、SQLインジェクション、CSRFが並ぶと一気にややこしく見えますよね。どれもWebアプリへの攻撃なので、名前だけで覚えようとすると選択肢で迷いやすいかなと思います。

ただ、基本情報の問題では、細かい実装よりも「何を狙う攻撃か」「問題文にどんなヒントが出ているか」を見ればかなり切り分けやすくなります。この記事では、基本情報のXSS・SQLインジェクション・CSRFを、試験で選べる形に整理していきます。

基本情報のXSS・SQL・CSRFの違い

狙われる場所で分ける

基本情報のXSS・SQLインジェクション・CSRFを最初に分けるなら、「攻撃の入口」よりも「最終的にどこが悪用されるか」で見るのがおすすめです。XSSはWebページを見ている利用者のブラウザ、SQLインジェクションはWebアプリの裏側にあるデータベース、CSRFはログイン済み利用者の操作権限が主なポイントになります。名前の雰囲気だけで見ると全部Web攻撃に見えますが、狙われる場所を変えるだけでかなり見通しが良くなります。

たとえば、問題文に「掲示板に投稿された文字列を閲覧した利用者のブラウザで不正なスクリプトが実行された」とあれば、中心はブラウザ側です。これはXSSを疑う流れですね。一方で、「入力欄に細工した文字列を入れることで、想定外の検索結果や更新が行われた」とあれば、サーバ側でSQL文の組み立てが壊れている可能性が高く、SQLインジェクションを疑います。「ログイン済みの利用者が、別サイトを閲覧しただけで設定変更リクエストを送らされた」なら、利用者のログイン状態を悪用しているのでCSRFです。

攻撃	主に見る場所	問題文のヒント
XSS	利用者のブラウザ	スクリプト、表示、Cookie
SQLインジェクション	データベース	SQL文、検索条件、入力値
CSRF	ログイン済み操作	意図しない送信、別サイト、認証済み

この3分類は、科目Aの知識問題でも科目Bの事例問題でも使えます。細かい対策名を覚える前に、まず対象をブラウザ、DB、ログイン状態のどれかに置くと、選択肢の候補を大きく減らせます。セキュリティ分野をまとめて復習したい場合は、基本情報技術者試験の情報セキュリティ対策ガイドで範囲全体を確認してから、この記事のような個別テーマを詰めると進めやすいです。

迷ったら、XSSはブラウザ、SQLインジェクションはDB、CSRFはログイン済みの操作権限、と先に置き分けるのがコツです。

XSSはブラウザを狙う

XSSはクロスサイトスクリプティングのことで、基本情報では「Webページに埋め込まれた不正なスクリプトが、利用者のブラウザで実行される攻撃」と考えると覚えやすいです。ポイントは、サーバそのものを直接壊すというより、ページを見た利用者側でスクリプトが動いてしまうことです。問題文に「掲示板」「コメント欄」「検索結果画面」「入力内容をそのまま表示」「Cookieの窃取」などが出てきたら、XSSの可能性が上がります。

試験で問われるXSSは、難しいコードを読む問題というより、入力された文字列をHTMLとしてそのまま表示してしまう危険性を理解しているかを見られることが多いです。たとえば、利用者が書き込んだ内容を別の利用者が閲覧するとき、その内容が単なる文字ではなくスクリプトとして解釈されると、ページ閲覧者のブラウザ上で不正な処理が走ります。ログイン中の画面で起きれば、セッション情報や画面上の情報が狙われる可能性もあります。

対策としては、入力値をそのまま信用しないことに加えて、画面へ出力するときのエスケープ処理が重要です。試験では「特殊文字をエスケープする」「入力値を適切に検査する」「CookieにHttpOnly属性を付ける」といった選択肢が出ることがあります。ただし、HttpOnlyは被害を抑える対策であって、画面に不正スクリプトを混入させない本筋の対策とは少し役割が違います。この違いまで押さえておくと、ひっかけ選択肢にも対応しやすくなります。

基本情報の暗記では、「XSSはサイトをまたぐ名前だから外部サイトだけの攻撃」と誤解しない方がいいです。実際の問題では、同じWebアプリ内の投稿欄や表示欄がきっかけになることもあります。名前よりも、ブラウザでスクリプトが実行されるかどうかを見ます。攻撃の結果としてCookieやセッション情報が狙われるとしても、最初に見るべき軸は、利用者のブラウザ上で不正な処理が動くかどうかです。

SQLインジェクションはDBを狙う

SQLインジェクションは、Webアプリがデータベースへ送るSQL文に、攻撃者が意図した条件や命令を混ぜ込む攻撃です。基本情報では「入力値を材料にSQL文を組み立てる処理があり、その入力値を悪用して、想定外の検索・更新・削除・認証突破につなげる」と理解しておけば十分です。問題文に「ログイン画面」「検索条件」「商品ID」「利用者ID」「データベースから抽出」といった言葉が出てきたら、SQLインジェクションを疑います。

XSSとの大きな違いは、SQLインジェクションの中心がブラウザ表示ではなく、サーバ側で実行されるSQL文にあることです。利用者の画面でスクリプトが動く話ではなく、WebアプリがDBに問い合わせる処理を攻撃者がねじ曲げます。たとえば、検索フォームやログインフォームに細工された文字列を入れることで、本来なら一致しないはずの条件が一致したり、表示してはいけないデータが返ったりするイメージです。試験では実際の危険な入力例を細かく再現する必要はなく、SQL文の構造が壊されるという方向性を押さえれば足ります。

• 検索条件やログイン条件が不正に変わる
• DBの情報が漏えいする
• 本来できない更新や削除が行われる
• SQL文を文字列連結で作る処理が危ない

対策としてよく問われるのは、プレースホルダを使ったSQLの組み立て、バインド機構、入力値の検査、DB利用者権限の最小化です。特に基本情報では「SQL文中で入力値を直接連結しない」という発想が重要です。単に入力欄の文字数を制限するだけでは不十分なこともありますし、表示時のエスケープはXSS寄りの対策です。選択肢に複数の安全対策が並ぶときは、どの攻撃に対する本命の対策なのかを対応させて選びます。

SQLそのものの読み方が不安な人は、攻撃手法だけを暗記しても問題文の流れが見えにくいかもしれません。SELECT、WHERE、JOIN、GROUP BYの基本が弱い場合は、基本情報のSQL問題の解き方で通常のSQL問題を先に整理してから戻ると、SQLインジェクションが「SQL文を壊す攻撃」だと理解しやすくなります。攻撃名を覚えるより、正常な処理を知る方がかえって近道になることもあります。

CSRFはログイン状態を悪用する

CSRFはクロスサイトリクエストフォージェリのことで、基本情報では「ログイン済みの利用者に、本人が意図しないリクエストを送らせる攻撃」と覚えると分かりやすいです。XSSのようにブラウザで不正スクリプトを動かすことが中心ではなく、SQLインジェクションのようにSQL文を壊すことが中心でもありません。すでに認証済みの利用者のブラウザから、正規のWebアプリに対して操作リクエストが送られる点がポイントです。

たとえば、利用者が銀行や会員サイトにログインした状態で、攻撃者が用意した別サイトやメール内のリンクを開いたとします。そのページをきっかけに、本人が押したつもりのない退会、メールアドレス変更、購入、送金などのリクエストが送られると、Webアプリ側から見るとログイン済み利用者からの正規のリクエストに見えてしまう場合があります。ここで悪用されるのは、利用者のログイン状態やセッション情報です。

CSRFは、利用者が「攻撃者になりすます」のではなく、攻撃者が「利用者の認証済み状態を利用して操作させる」と考えると整理しやすいです。

対策としては、重要な操作のリクエストに推測困難なトークンを付けて照合する、RefererやOriginを確認する、再認証を求める、といったものが代表的です。基本情報では特に、フォームにCSRF対策用トークンを埋め込んで、送信時にサーバ側で確認する流れがよく出ます。入力値のエスケープやSQLのプレースホルダは大事な対策ですが、それぞれXSSやSQLインジェクション向けなので、CSRFの主対策としてはズレます。

CSRFで迷いやすいのは、Cookieやセッションという言葉が出たときにXSSと混同するところです。Cookieを盗む、Cookieを読み取る、ブラウザでスクリプトを実行するならXSS寄りです。Cookieが自動送信されるログイン状態を利用し、本人が意図しない操作を成立させるならCSRF寄りです。Cookieという単語だけで決めず、「盗む」のか「自動送信される認証状態を使う」のかを読むと、選択肢の切り方が安定します。

三つの違いを表で整理する

ここまでをまとめると、基本情報のXSS・SQLインジェクション・CSRFは、攻撃対象、問題文のキーワード、対策の組み合わせで覚えるのが一番実戦的です。単語だけを暗記すると、「入力欄があるから全部SQLインジェクション」「Cookieが出たから全部XSS」のように早とちりしがちです。入力欄があっても、表示された内容がブラウザで実行されるならXSSですし、ログイン済み状態で意図しない操作を送らせるならCSRFです。

試験では、攻撃名を聞かれる問題だけでなく、対策を選ぶ問題もあります。その場合は、攻撃と対策をセットで覚えておくと強いです。XSSなら出力時のエスケープ、SQLインジェクションならプレースホルダやバインド、CSRFならトークン照合という対応関係を先に思い出します。もちろん実務では複数対策を組み合わせますが、基本情報の選択肢では「この攻撃に最も直接効く対策はどれか」という見方が役立ちます。

観点	XSS	SQLインジェクション	CSRF
狙うもの	ブラウザ	DB	認証済み操作
代表ヒント	スクリプト実行	SQL文の改変	意図しない送信
主な被害	Cookie窃取など	情報漏えいなど	設定変更など
主対策	出力エスケープ	プレースホルダ	トークン照合

この表は、過去問演習のたびに自分の言葉で再現できるようにしておくと便利です。特に、XSSとCSRFはどちらも利用者のブラウザやCookieが絡むので混同しやすいです。XSSは不正スクリプトを利用者のブラウザで実行させる、CSRFは利用者がログインしていることを利用して正規のリクエストを送らせる。この1文の違いを何度か口に出すだけでも、科目Aの選択肢で迷う時間を減らせます。

より正確な用語や安全なWebアプリケーションの作り方を確認したい場合は、IPAの「安全なウェブサイトの作り方」も一次情報として参考になります。この記事では基本情報の試験対策としてかみ砕いていますが、正確な情報は公式サイトをご確認ください。実務での最終的な実装判断は専門家にご相談ください。

基本情報のXSS・SQL・CSRFの解き方

問題文のキーワードを見る

基本情報でXSS、SQLインジェクション、CSRFを見分けるときは、まず問題文のキーワードに線を引くつもりで読みます。攻撃名を先に思い出そうとすると、似た言葉に引っ張られます。先に「利用者のブラウザで何かが動くのか」「DBへの問い合わせが壊れるのか」「ログイン済み利用者の操作として送られるのか」を探す方が安定します。科目Aの短い文章でも、科目Bの長い事例でも、この順番は変わりません。

キーワードは単語単体ではなく、動作とセットで見ます。「Cookie」が出たからXSSと決めるのではなく、Cookieを盗み取るためにスクリプトを実行しているのか、Cookieが認証情報として自動送信される状況を利用しているのかを見ます。「入力欄」が出たからSQLインジェクションと決めるのではなく、入力値がSQL文の条件や命令に影響しているのか、HTMLとして表示されているのかを見ます。この読み方をすると、ひっかけがかなり減ります。

• ブラウザでスクリプトが実行されるならXSS
• SQL文やDB検索条件が変わるならSQLインジェクション
• ログイン済みの操作を勝手に送らせるならCSRF
• 対策名は攻撃対象とセットで確認する

たとえば、「利用者が掲示板を閲覧しただけで、意図しないスクリプトが実行された」という文なら、閲覧とスクリプトが重要です。これはXSS寄りです。「検索フォームに細工した値を入力すると、表示されるべきでない会員情報が表示された」なら、検索フォームとDB問い合わせが重要なのでSQLインジェクション寄りです。「ログイン中の利用者が別サイトを開いた結果、登録メールアドレスが変更された」なら、ログイン中と意図しない操作が重要なのでCSRF寄りです。

問題文を読んだら、攻撃名を思い出す前に「ブラウザ」「DB」「ログイン状態」のどれが主役かをメモするつもりで切り分けると、選択肢が選びやすくなります。

選択肢の対策を対応させる

攻撃名を選ぶ問題よりも、対策を選ぶ問題の方が迷う人は多いかなと思います。理由は、選択肢に並ぶ対策がどれも一見セキュリティに良さそうだからです。入力値チェック、エスケープ、プレースホルダ、トークン、アクセス制御、暗号化などが並ぶと、どれも正しく見えます。そこで大事なのが、対策の良し悪しを一般論で見るのではなく、問題文の攻撃に対して直接効くかで見ることです。

XSSなら、利用者のブラウザでスクリプトとして解釈されないようにすることが中心です。出力時にHTML特殊文字をエスケープする、入力値を適切に検査する、CookieにHttpOnly属性を付けて被害を抑える、といった方向を見ます。SQLインジェクションなら、入力値がSQL文の構造を変えないように、プレースホルダやバインド機構を使うことが中心です。CSRFなら、正規の画面から送られたリクエストかを確認するために、CSRFトークンなどを照合します。

対策	主に対応する攻撃	理由
出力エスケープ	XSS	HTML上でスクリプト化させない
プレースホルダ	SQLインジェクション	入力値でSQL構造を変えない
CSRFトークン	CSRF	正規画面からの送信か確認する
権限の最小化	補助対策	被害範囲を狭める

ここで注意したいのは、実務では複数の対策を重ねることが多いという点です。たとえば入力値チェックは多くの場面で有効ですが、それだけでSQLインジェクション対策の本命とは限りません。暗号化も重要ですが、XSSでスクリプトが実行される問題やCSRFでリクエストが送られる問題を直接止めるとは限りません。基本情報では「この攻撃を防ぐための最も適切な対策」を選ぶ意識が大事ですね。

科目Bのセキュリティ問題では、本文の状況と設問の聞き方を対応させる力も必要です。長文問題での読み方に不安がある場合は、基本情報の科目Bセキュリティ対策も合わせて確認すると、攻撃と対策を事例の中で読む練習がしやすくなります。用語暗記と長文読解は別物に見えますが、対応表を頭に入れておくとかなりつながります。

科目Bでは業務の流れで読む

科目BでXSS、SQLインジェクション、CSRFが出る場合は、用語をそのまま聞くというより、業務の流れやWebアプリの処理の中で読み取らせる形になりやすいです。会員登録、ログイン、商品検索、掲示板、管理画面、メール通知などの場面が出てきて、どこに弱点があるかを考えさせるイメージですね。長い文章を最初から全部完璧に理解しようとすると疲れるので、まずは入力、処理、出力、認証状態のどこが問題になっているかを追います。

SQLインジェクションなら、入力された値が検索条件や更新条件に使われる場面が重要です。XSSなら、入力された値が別の利用者の画面に表示される場面が重要です。CSRFなら、ログイン中の利用者のブラウザから、重要な操作リクエストが送信される場面が重要です。科目Bでは登場人物や画面が多く出ることがありますが、すべてを同じ重さで読むのではなく、攻撃が成立する流れに関係する部分を中心に拾うと読みやすくなります。

この読み方をすると、問題文が多少長くても「何を問われているか」が見えやすくなります。たとえば、管理者が投稿内容を確認する画面でスクリプトが動くならXSS、商品検索画面の条件指定でDBの情報が広く表示されるならSQLインジェクション、ログイン中の利用者が外部ページを見た後に設定変更されるならCSRFです。言い換えると、科目Bでは用語を一問一答で覚えるだけでなく、処理の流れに用語を当てはめる練習が必要です。

また、セキュリティ問題は時間をかけすぎると他の設問に響きます。最初の読みで攻撃名が確定しない場合でも、ブラウザ、DB、ログイン状態の三択まで絞れれば十分前進です。そこから対策選択肢を見て、出力エスケープ、プレースホルダ、トークンのどれが自然かを確認します。本文と選択肢の両方から絞るイメージを持つと、暗記だけに頼るより安定します。

似た攻撃との違いも押さえる

基本情報のセキュリティでは、XSS、SQLインジェクション、CSRF以外の攻撃手法も出てきます。たとえば、OSコマンドインジェクション、ディレクトリトラバーサル、セッションハイジャック、クリックジャッキング、フィッシングなどですね。これらと混ざると、せっかく3つの違いを覚えても選択肢で迷うことがあります。そこで、似た攻撃は「何を混入するのか」「何を奪うのか」「利用者をどうだますのか」で追加分類すると整理しやすくなります。

SQLインジェクションとOSコマンドインジェクションは、どちらも入力値を悪用して命令を混ぜ込む点が似ています。ただし、SQLインジェクションはDBに対するSQL文、OSコマンドインジェクションはOSのコマンド実行が中心です。問題文にファイル操作、シェル、コマンド実行などが出るならOSコマンド側を疑います。データベース、検索条件、SQL文が中心ならSQLインジェクションです。混ぜ込む対象が違うわけですね。

インジェクション系は「何を注入するか」を見ると分かれます。SQL文ならSQLインジェクション、OSコマンドならOSコマンドインジェクションです。

XSSとフィッシングも混同しやすいです。XSSは正規サイトなどのページ上で不正スクリプトが実行される攻撃です。フィッシングは偽サイトや偽メールなどで利用者をだまし、IDやパスワードを入力させる攻撃です。どちらも利用者が被害に遭う点は似ていますが、技術的な成立条件が違います。問題文が「偽のログイン画面へ誘導」といった話ならフィッシング寄り、「投稿内容を閲覧した利用者のブラウザでスクリプトが実行」ならXSS寄りです。

CSRFとクリックジャッキングも、利用者に意図しない操作をさせる点では似ています。クリックジャッキングは、透明なボタンや偽装された画面などで、利用者に別の操作をクリックさせる攻撃です。CSRFは、別サイトなどをきっかけにログイン済み利用者のリクエストを送らせる攻撃です。画面上のクリック誘導が中心ならクリックジャッキング、認証済みリクエストの偽造が中心ならCSRFと見ると、基本情報レベルでは分けやすいかなと思います。

基本情報のXSS・SQL・CSRFまとめ

基本情報のXSS・SQLインジェクション・CSRFは、用語が似ているから難しく感じますが、狙われる場所で分ければかなりシンプルです。XSSは利用者のブラウザで不正スクリプトが実行される攻撃、SQLインジェクションは入力値を悪用してSQL文やDB操作をねじ曲げる攻撃、CSRFはログイン済み利用者に意図しないリクエストを送らせる攻撃です。この3つを、ブラウザ、DB、ログイン状態のセットで思い出せるようにしておきましょう。

対策も同じようにセットで覚えます。XSSは出力エスケープ、SQLインジェクションはプレースホルダやバインド、CSRFはトークン照合が基本の対応関係です。もちろん実際の開発では、入力値検証、権限管理、ログ監視、セッション管理など複数の対策を組み合わせます。ただ、基本情報の選択問題では、まず攻撃名と主対策を対応させることが得点に直結しやすいです。

• XSSは「表示された内容がブラウザで動くか」を見る
• SQLインジェクションは「DBへのSQL文が壊れるか」を見る
• CSRFは「ログイン済み操作を勝手に送らせるか」を見る
• 対策はエスケープ、プレースホルダ、トークンで対応させる

過去問演習では、問題を解いた後に「なぜ他の攻撃ではないのか」まで一言で説明してみると効果的です。XSSではない理由、SQLインジェクションではない理由、CSRFではない理由を言えるようになると、選択肢の消去がかなり速くなります。暗記カードを作る場合も、攻撃名だけでなく、問題文のヒントと対策を同じカードに入れると実戦向きです。

最後に、セキュリティは一度覚えて終わりではなく、問題演習で何度も見直す分野です。最初は表を見ながらで構いません。ブラウザ、DB、ログイン状態という3つの軸で読み続けると、だんだん問題文のヒントが目に入るようになります。基本情報のXSS・SQLインジェクション・CSRFは、細かい攻撃手順を覚えるより、違いと対策の対応関係を押さえることから始めるのが得点につながりやすいです。