入力チェックだけで安全と言えますか——SQLインジェクション・XSS・CSRFを「値の使い道」で読む｜支援士解説2の5

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• SQLインジェクション、XSS、CSRFなどが「なぜ起きるか」を、入力値の使われ方から説明できる

• 午後の問題で、ソースコードやHTTPのやり取りから欠陥の場所と対策を特定できる

• 解答欄に書く「原因」と「対策」の型が分かる

シラバスとの対応：小項目2-5「セキュアプログラミング」。セッション管理・JWT・Cookie属性の詳細は支援士解説2の4、脆弱性を見つける診断の方法は支援士解説2の6で扱います。

午後の試験では、Webアプリケーションの問題がよく出ます。JavaやJavaScriptのコードを読ませる問題も多く、用語を覚えているだけでは解けません。問われるのは、問題文に書かれた入力値が、どこで何として使われ、どこで境界が崩れているかを読み取る力です。

この記事は、その読み方を一つの軸で整理します。軸は「値の使い道」です。値がSQLの命令になる、HTMLのタグになる、通信の行き先になる、他人のデータを指す。どの脆弱性も、この形で説明できます。

1. 考え方の軸：値は、使う場所で「命令」や「行き先」になる

【図1】入力から利用先まで、境界を追う

外から届く値は、フォームの入力欄だけではありません。URLのパラメータ、HTTPヘッダ、Cookie、hiddenフィールド、アップロードされたファイル、外部APIの応答も、利用者や攻撃者が書き換えられます。データベースに一度保存した値も、出どころが外部なら、取り出して使うときには信用できません。

脆弱性を探すときは、次の四つを線でつなぎます（図1）。

• 入力：値はどこから来たか

• 検証：型・長さ・形式・業務上の条件を、サーバ側で確かめているか

• 利用先：値はSQL、HTML、OSコマンド、ファイルのパス、通信先のURLのどれに使われるか

• 制御：利用先に合った安全な処理（値と命令を分ける、出力時にエスケープする、行き先を許可リストで限定する）をしているか

ここで大切なのは、入力時の検証と、利用先での処理は別の問いだということです。入力時の検証は「業務上許される値か」を確かめます。一方、利用先での処理は「その値が命令として解釈されないか」を確かめます。人名にはアポストロフィ（シングルクォート）が含まれることがあります。そのため「記号を拒否したから安全」とは言えません。逆に、記号を通しても、利用先で正しく扱えば問題は起きません。

値の扱いとは別に、その対象を操作してよいか（認可）も必ず確かめます（8節）。また、外から来る値だけでなく、メモリの領域や、同時に更新されるデータのような共有する状態も境界になります（10・11節）。

もう一つの軸は権限です。値の扱いに欠陥があっても、アプリケーションがデータベースに接続するアカウントの権限を最小限にしておけば、被害を小さくできます。ただしこれは被害を抑える対策で、欠陥そのものを直すものではありません。

2. SQLインジェクション：値がSQLの命令になる

仕組み

Webアプリは、利用者の入力値を使ってSQL文を組み立て、データベースに問い合わせます。ログイン画面で、次のように文字列をつなぎ合わせてSQL文を作るとします。

SELECT * FROM members WHERE name = '（入力した名前）' AND passwd = '（入力したパスワード）'

パスワード欄に、次の値を入力されたとします。

' OR '1'='1

できあがるSQL文は次のようになります。

SELECT * FROM members WHERE name = 'taro' AND passwd = '' OR '1'='1'

入力値の先頭のシングルクォートが文字列の終わりとして解釈され、その後ろのOR以降がSQLの命令の一部になりました。SQLではANDがORより先に評価されるので、条件は「（名前がtaroかつパスワードが空）または（常に真になる条件）」になります。後半は常に真なので、パスワードを知らなくても認証を通過できます。

原因は、危険な記号が入っていたこと自体ではありません。データとして扱うべき値が、SQLの構文として解釈されたこと、つまり値と命令の境界が崩れたことです。

悪用されると、次のような被害が起きます。

• 認証を回避される（上の例）

• UNIONを使った問合せを付け足され、本来の検索結果に別の表（会員情報など）の内容を混ぜて表示される

• データを改ざん・削除される

画面に出なくても情報は漏れる：ブラインドSQLインジェクション

検索結果やエラーが画面に表示されなくても、攻撃は成立します。ブラインドSQLインジェクションは、条件を変えたリクエストを送り、応答の違いを観察して、データベースの情報を少しずつ割り出す手法です。

数値として使われるパラメータは、引用符で囲まれません。そのためシングルクォートで文字列を抜け出さなくても、後ろに条件を付け足せます。たとえば、次の二つのリクエストを送って応答を比べます。

article=20250401 and 1=1   （常に真）→ 通常どおり表示される
article=20250401 and 1=0   （常に偽）→ 表示されない

応答が変われば、入力がSQLの条件として解釈されていると分かります。さらに「テーブル名の1文字目はaか」のような条件を一つずつ試せば、データが画面に出なくてもテーブル名などを特定できます。

根本対策：プレースホルダ

【図2】文字列連結とプレースホルダの違い

根本対策はプレースホルダ（バインド機構）です（図2）。

• SQL文の値の部分に「?」などの記号を置き、SQL文の「ひな形」を先に用意する

• 実際の値は、後から別に割り当てる（バインドする）

• 割り当てた値は、ただの値（文字列や数値）として扱われる。値の中にシングルクォートがあっても、構文としては解釈されない

Javaでは、次のように書きます（説明用に簡略化した例）。

String sql = "SELECT * FROM members WHERE name = ? AND passwd = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, name);
stmt.setString(2, passwd);

• 1行目：値を入れる場所を「?」にしたSQL文を用意する

• 2行目：SQL文を準備する。ここで命令の構造が決まる

• 3〜4行目：1番目と2番目の「?」に、入力値を割り当てる

データベース側でSQL文の構文を解析してから値を割り当てる方式を、静的プレースホルダといいます。値が入る前に「どこが命令で、どこが値か」が確定しているので、後から入る値は構文の一部になりません。これがプレースホルダが根本対策になる理由です。なお、ライブラリの側で値をエスケープしてからSQL文に埋め込む動的プレースホルダもあります。こちらは、ライブラリのエスケープ処理が正しいことが前提になります。

プレースホルダで渡せないもの

• 表名・列名・ORDER BYの並び順：SQLの構造そのものなので、値としてバインドしても意図どおりには働きません。画面で並び順を選ばせるなら、「新しい順」なら「created_at DESC」に置き換える、というように、プログラム側で決めた候補の中から選ばせます。入力値をそのまま連結しません。

• LIKE句のワイルドカード：値の中のパーセント記号（%）やアンダースコア（_）は、プレースホルダで渡してもワイルドカードとして扱われます。これはSQLインジェクションとは別の「意図しない範囲が検索される」問題です。ただの文字として扱いたいなら、別にエスケープします。

ORMやストアドプロシージャを使っていても、内部で文字列を連結していれば安全とは言えません。コードを読むときは、SQLを実行するメソッドを使っているかどうかではなく、SQL文を組み立てている箇所に入力値が直接つながっていないかを見ます。

その他の対策

• エスケープ処理：プレースホルダを使えない場合に、シングルクォートを2つ重ねるなどして、特別な意味を持つ文字をただの文字にします。ただし漏れが起きやすい方法です。たとえば数値として埋め込む値は引用符で囲まれないので、シングルクォートを置き換えても効果がありません。

• WAF：SQLインジェクションに典型的なパターンを遮断できます。ただし、すり抜けられる場合があるので、根本対策の代わりにはなりません。

• 被害を小さくする対策：DBへの接続アカウントの権限を最小限にします。また、データベースのエラーの詳細を利用者の画面に出しません。エラーの内容は、表の構造などのヒントを攻撃者に与えるからです。

午後での問われ方

• 令和5年度春期 午後I問1：Javaのソースコードの空欄に、プレースホルダを使ったSQL文（条件の値の部分を「?」にする）と、PreparedStatementを使う記述を埋めさせる問題でした。文字列を連結してSQL文を作っている箇所を見つけ、プレースホルダに置き換えるのが、コード読解問題の定番です。

• 令和7年度春期 午後問2：脆弱性診断で指摘されたキャンペーンページが題材でした。常に偽・常に真になる条件を付け足したパラメータで応答の違いを確かめ、ブラインドSQLインジェクションによってDBのテーブル名が特定できる、という流れが示されました。

採点講評で指摘されたつまずき

• 令和5年度春期 午後I問1では、プレースホルダを使う行に入る型を「PreparedStatement」とすべきところを、「Statement」と答えた受験者が多かったと指摘されています。プレースホルダ付きのSQL文を扱うのは PreparedStatement です。クラス名とメソッド名（prepareStatement）をセットで書けるようにしておきます。

記述の型

• 原因：「入力値を文字列連結でSQL文に組み込んでいるため、入力値がSQL文の構文として解釈される」

• 対策：「プレースホルダを用いてSQL文を組み立てる」

• 対策の理由：「SQL文の構造を先に確定させ、入力値を値として扱うため」

• ブラインドSQLインジェクションの危険性：「応答の違いから、DBのテーブル名などの情報を特定される」

• 被害を小さくする対策：「DB接続アカウントの権限を必要最小限にする」「詳細なエラーメッセージを表示しない」

3. OSコマンドインジェクション・パストラバーサル・ファイルアップロード

SQLインジェクションと同じ構図は、OSやファイルでも起きます。

OSコマンドインジェクション

多くの言語には、system関数のようにシェル（コマンドを解釈して実行するプログラム）を起動してOSのコマンドを実行する関数があります。シェルは、セミコロンや縦棒（パイプ）などを「コマンドの区切り」として解釈します。ファイル名を受け取って処理するコマンドに、次のような値を入れられたとします。

report.txt; rm -rf /

すると、本来のコマンドの後ろで、セミコロンの後ろに書かれた別のコマンドが実行されます。

対策は次のとおりです。

• シェルを起動する関数を、できるだけ使わない。ファイルの移動や削除は、言語の専用の機能（ファイル操作のライブラリ）で行う

• 外部プログラムを使うしかない場合は、コマンドと引数を分けて渡す。引数として渡しても、呼び出し先がその値をオプションとして解釈する場合があるので、引数の仕様を確かめる

• 使える文字の種類と書式を決め、合わない入力はエラーにして処理しない。シェル向けのエスケープは複雑で漏れやすいので、通すより受け付けないほうが安全

• 実行するアカウントの権限を最小限にする

パストラバーサル（ディレクトリトラバーサル）

入力したファイル名でサーバのファイルを開く機能に、一つ上のディレクトリを示す記号を含む値を入れられ、公開するつもりのないファイルを読まれる問題です。たとえば、決まったフォルダの中のファイルを開く機能に次の値を入力されると、サーバの重要なファイルが読まれます。

../../etc/passwd

• そもそも、外部から受け取った文字列でファイル名を指定する仕様をやめる。たとえば、申請IDからサーバ側で決めたファイルを引く

• やむを得ない場合は、パス名からファイル名だけを取り出す関数（basename関数など）を使う

• 上の記号の有無だけを調べる方法は破られやすい。スラッシュをURLエンコードした値や、それをさらにエンコードした値は、チェックの後でデコードされるとスラッシュに戻ることがある（下の例）

/    →  %2F     （スラッシュをURLエンコード）
%2F  →  %252F   （先頭の%をさらにエンコード）

ファイルアップロード

ファイル名の拡張子がPDFでも、中身がPDFだという保証はありません。アップロードを受け付けるときは、次の点を組み合わせて確かめます。

• 拡張子と中身の形式が一致しているか

• 容量が上限を超えていないか

• 保存するファイル名は、元の名前ではなくサーバ側で生成した名前にする

• 公開領域の外に保存し、ダウンロードのたびに権限を確かめる

形式の確認を怠ると、スクリプトを別の形式に見せかけてアップロードされ、XSSと組み合わせて悪用されることがあります（4節の令和7年度秋期 午後問1）。

記述の型

• OSコマンドインジェクションの対策：「シェルを起動する関数を使わない」

• パストラバーサルの対策：「外部から受け取った値からファイル名だけを取り出して使う」「外部の値でファイル名を指定しない」

• アップロードの対策：「アップロードされたファイルの形式が、拡張子と整合しているかを確認する」

4. XSS（クロスサイトスクリプティング）：値がHTMLやスクリプトになる

なぜ危険なのか：同一オリジンポリシーを越えてしまう

XSSは、攻撃者が用意したスクリプトが、脆弱性のある正規サイトのページの一部として、利用者のブラウザで実行されてしまう脆弱性です。

ブラウザには同一オリジンポリシー（Same-Origin Policy）という制限があります。スキーム・ホスト名・ポート番号の三つがすべて一致するものを同一オリジンといい、オリジンが違うページのデータは読めないようになっています。そのため、攻撃者のサイトに置いたスクリプトからは、正規サイトのCookieやページの中身を読めません。

ところがXSSでは、スクリプトが正規サイトのページの一部として動くので、この制限が働きません。攻撃者のスクリプトには、次のことができてしまいます。

• そのサイトのCookieを読み取り、外部へ送る（セッションの乗っ取りにつながる）

• ページに偽の入力欄を表示して、カード番号などを入力させ、攻撃者のサイトへ送らせる

• 利用者になりすまして、そのサイトへ操作の要求を送る

三つの型は「スクリプトの通り道」で見分ける

【図3】XSSの三つの型：スクリプトの通り道と直す場所

• 反射型：リクエストに含まれたスクリプトを、サーバがそのままレスポンスに埋め込んで返す。典型例は検索結果画面やエラーメッセージ。攻撃者は罠のURLを利用者にクリックさせる

• 格納型：攻撃者が投稿したスクリプトがいったんサーバ（データベースなど）に保存され、そのデータを表示するたびに実行される。典型例は掲示板、レビュー、プロフィール欄。罠のURLは不要で、ページを開いた人全員が被害を受ける

• DOM-based：ブラウザ上で動く正規のJavaScriptが、URLなどの値をそのままページに書き込むことで起きる。DOMは、ブラウザがHTMLを読み込んだあと、JavaScriptから要素を追加・変更できるように組み立てた木構造のこと。スクリプトを組み立てるのはブラウザ側なので、サーバ側の処理に問題がなくても成立する。URLの「#」より後ろ（フラグメント）はサーバに送られないので、サーバのログにも残らない

見分けるときは、次の二つを確かめます（図3）。

• スクリプトはサーバに保存されるか → 保存されるなら格納型

• スクリプトはサーバのレスポンスに含まれるか → 含まれず、ブラウザの中で組み立てられるならDOM-based

反射型と格納型の原因は、サーバがHTMLを組み立てて出力する処理にあります。DOM-basedの原因は、ブラウザ側のJavaScriptにあります。直す場所が違うことが、この分類を覚える意味です。スクリプトがDOMを操作していても、サーバに保存されてから出力されるなら格納型です。「DOMを触っているからDOM-based」と早合点しないようにします。

根本対策：出力する直前に、出力先に合わせてエスケープする

反射型と格納型の根本対策は、HTMLを出力するときに、値を「文字」として扱わせるエスケープ処理です。HTMLの本文に値を埋め込むなら、少なくとも次の文字を置き換えます。

&  →  &
<  →  &lt;
>  →  &gt;
"  →  &quot;
'  →  &#39;

こうすると、scriptタグを入力されても、画面にはタグの文字がそのまま表示されるだけで、スクリプトとしては実行されません。

エスケープは、入力を受け付けたときではなく、出力する直前に行います。同じ値でも、埋め込む場所によって必要な処理が違うからです。

• HTMLの本文：上の置き換え

• タグの属性値：上の置き換えに加えて、属性値を必ずダブルクォートで囲む。囲まないと、空白の後ろが新しい属性（イベントハンドラ）として解釈される（下の例）

• href・srcなどURLを入れる属性：エスケープだけでは不十分。javascriptスキームのURLを入れられるとスクリプトが動くので、httpかhttpsのスキームで始まることを確かめる

• イベントハンドラ属性の中のJavaScript文字列：まずJavaScriptの文字列としてエスケープし、次にHTMLの属性値としてエスケープする。2段階が必要

• script要素の中のJavaScript文字列：JavaScriptの文字列としてのエスケープに加えて、値の中の終了タグで要素が終わってしまわないように、不等号なども置き換える

次は、引用符で囲んでいない属性値に、攻撃者が文字列を入れた場合の例です。空白の後ろが、新しい属性（イベントハンドラ）として解釈されます。

<!-- 入力値：abc onmouseover=alert(1) -->
<input value=abc onmouseover=alert(1)>

あわせて、HTTPレスポンスのContent-Typeヘッダで文字コードを明示します（例：UTF-8）。指定がないと、ブラウザが文字コードを推測し、エスケープをすり抜けられる場合があります。

利用者にHTMLの装飾を許す仕様（一部のタグの入力を認めるなど）では、全部をエスケープすると機能が壊れます。この場合は、許可するタグと属性を限定し、保守されたサニタイズの部品を使います。

DOM-based XSSの対策：危険なAPIを使わない

DOM-based XSSはブラウザの中で完結するので、サーバ側でいくらエスケープしても防げません。対策はJavaScriptの書き方です。

document.getElementById('msg').innerHTML = decodeURIComponent(location.hash.slice(1));

URLの「#」以降を取り出して、そのままページに書き込む処理です。ここに、次のようなフラグメントを付けたURLを踏ませると、画像の読込みエラーをきっかけにスクリプトが実行されます。

#<img src=x onerror=alert(1)>

innerHTMLで書き込んだscriptタグは実行されないため、攻撃ではこうした形が使われます。

• 値をHTMLとして解釈するAPI（innerHTML、document.write、eval など）に、外部からの値を渡さない

• 値を文字として扱うAPI（textContent、createElement など）を使う。上のコードは、innerHTML を textContent に変えれば、値はただの文字として表示される

• setAttribute を使う場合も、入れる属性に注意する。イベントハンドラ属性に外部の値を入れればスクリプトとして実行され、href・srcに入れるならスキームの確認が要る

• 使っているJavaScriptのライブラリを最新に保つ

innerHTML は「HTMLとして解釈して書き込む」、textContent は「ただの文字として書き込む」。コードを読ませる設問で狙われやすい違いです。

CSPとHttpOnlyは「保険」

CSP（Content-Security-Policy）は、ブラウザが実行してよいスクリプトの読込み元などを、HTTPレスポンスヘッダで指定する仕組みです（6節）。たとえば次の指定では、自サイトのスクリプトだけを許可します。unsafe-inlineという値を加えない限り、HTMLに直接書き込まれたスクリプトも実行されません。

Content-Security-Policy: script-src 'self'

ただし、CSPは「許可した読込み元」を信頼します。攻撃者が自サイトの中にスクリプトを置ければ、許可の範囲内として実行されます。CSPは被害を小さくする仕組みで、エスケープの代わりにはなりません。

Cookieの HttpOnly 属性は、JavaScriptからCookieを読めなくします。Cookieを盗まれることは防げますが、偽の入力欄の表示や、なりすましの要求は防げません。「HttpOnlyにすればXSSは起きない」は誤りです。Cookie属性の詳細は支援士解説2の4で扱います。

午後での問われ方

• 令和5年度秋期 午後問1：Webアプリの脆弱性が悪用されたインシデントが題材でした。解答例の対策は「レビュータイトルを出力する前にエスケープ処理を施す」というものです。保存された値が表示のたびに使われるので、型は格納型です。

• 令和7年度秋期 午後問1：HTTPレスポンスヘッダで、CSPのdefault-srcに自サイト（self）だけを指定しているサービスが題材でした。攻撃者は、スクリプトを別形式（拡張子はxlsx）のファイルに見せかけてサービス内にアップロードし、出力時にエスケープされていないタスク名に、アップロードしたファイルを読み込むscriptタグを差し込みました。ファイルは自サイト上にあるので、CSPの許可の範囲に入ってしまいます。解答例では、「アップロードされたファイルの形式が拡張子と整合しているかをチェックする」ことと、「出力時にエスケープ処理を施す」ことが対策として示されています。

採点講評で指摘されたつまずき

• 令和5年度秋期 午後問1では、XSSの種類を選ぶ設問で、スクリプトがDOMを使っていたことからか、「DOM Based XSS」と誤って答える受験者が散見されたと指摘されています。型は、スクリプトがサーバに保存されるか、レスポンスに含まれるかで判断します。

• 令和7年度秋期 午後問1では、CSPの内容や効果を問う設問の正答率がやや低かったとされています。CSPが何を制限し、どこに抜け道が残るかを説明できるようにしておきます。

記述の型

• 原因：「入力値をエスケープせずに、HTMLとして出力している」

• 対策：「出力時にエスケープ処理を施す」

• DOM-basedの対策：「innerHTMLではなくtextContentを用いる」

• 型の判別：「サーバに保存されるか」「レスポンスに含まれるか」の2点で判断する

• 攻撃者が入力する文字列：出力される場所を確かめる（下の例）

• CSPやHttpOnlyで十分か：「被害を抑える効果はあるが、XSSそのものは直らない」

出力される場所ごとの、攻撃者が入力する文字列の例です。

HTMLの本文          ： <script>…</script>
引用符のない属性値  ： （空白）onmouseover=…
innerHTMLへの書込み ： <img src=x onerror=…>

5. CSRF（クロスサイトリクエストフォージェリ）：本人のブラウザから要求を送らせる

仕組み

CSRFは、ログイン中の利用者に、攻撃者が用意したリクエストを送らせる攻撃です。

1. 利用者が、サイトAにログインしている

2. ログインしたまま、攻撃者が用意した罠サイトを開く

3. 罠サイトに仕込まれたフォームによって、利用者のブラウザからサイトAへ「パスワード変更」「登録情報の変更」などのリクエストが送られる

4. ブラウザはサイトAのCookie（セッションID）を自動で付けて送るので、サイトAは本人の正規の操作だと思って処理する

ブラウザの同一オリジンポリシーは、他のサイトの画面の内容を読み取ることは制限します。しかし、他のサイトへフォームを送信することまでは止めません。罠サイトはサイトAの画面を読めませんが、サイトAへのリクエストを送らせることはできます。

XSSとの違い

【図4】XSSとCSRFは、何が違うのか

• XSS：脆弱なサイトのページの上で、攻撃者のスクリプトが動く

• CSRF：攻撃者のサイトから、利用者のブラウザを使って、脆弱なサイトへ意図しない要求を送らせる。脆弱なサイトでスクリプトを動かす必要はなく、Cookieを盗む必要もない

対策も別物です（図4）。XSSの対策は出力時の処理で、CSRFの対策は状態を変える要求を受け付ける前の確認です。互いに代わりにはなりません。なお、XSSがあると、攻撃者のスクリプトが正規のページからCSRFトークンを読み取れる場合があります。両方の欠陥を、それぞれ直します。

対策

• CSRFトークン：サーバが推測困難な値（トークン）を発行し、正規の画面のフォームのhiddenフィールドに入れておく。リクエストを受けたら、トークンが正しいかを確かめる。罠サイトはサイトAの画面を読めないので、正しいトークンを知ることができない

• SameSite属性：他のサイトからのリクエストにCookieを付けないようにする。値は三つある

• Strict：他のサイトからの遷移では、Cookieを一切送らない。最も安全だが、外部のリンクから来たときの最初の画面ではログインしていない扱いになる

• Lax：他のサイトからの遷移でも、リンクをたどるGETの画面遷移ではCookieを送るが、POSTでは送らない。そのため、POSTによる多くのCSRFを防げる。ただしGETで状態が変わる設計だと防げない

• None：他のサイトからでも送る。Secure 属性が必要

• SameSiteは、CSRFトークンと組み合わせる補助的な対策と考える。Cookie属性の全体は支援士解説2の4で扱う

• 重要な操作の前に、パスワードを再入力させる：利用者の負担は増えるが、効果は高い

• 認可を要求ごとに確かめる：トークンが正しくても、その利用者にその操作を許してよいかは別の確認（8節）

• Refererヘッダでリンク元を確かめる：ただし、Refererを送らない設定の利用者は、正規の操作でも弾かれる

「POSTにしただけ」「確認画面を置いただけ」では対策になりません。罠サイトのフォームは、POSTでも、確認画面の次の要求でも送れるからです。

トークンは「誰のセッションのものか」まで確かめる

CSRFトークンを確かめていても、そのトークンが、要求を送ってきた利用者のセッションのものかを確かめなければ意味がありません。別の利用者のアカウントで取得したトークンでも通るなら、攻撃者は自分のアカウントで取得したトークンを罠のフォームに入れておけばよいことになります。トークンは利用者のセッションと結び付けて発行し、そのセッションのトークンと一致するかを確かめます。

午後での問われ方

• 令和6年度春期 午後問3：CSRFトークンを確認してはいるものの、別の利用者アカウントで取得したトークンでも処理されてしまう不備が題材でした。解答例の手口は、「攻撃者が自らのアカウントで取得したcsrf_tokenと一緒に利用者情報をサイトに送るように構成した罠のフォームに、利用者を誘導し、利用者情報を変更させる」というものです。

採点講評で指摘されたつまずき

• 令和6年度春期 午後問3では、CSRFの攻撃手法を問う設問の正答率が低く、攻撃者が取得したトークンを悪用する部分を書けていない受験者が多かったと指摘されています。「誰が、どのトークンを、どこに入れて、誰に送らせるか」まで、本文の状況に即して書きます。

記述の型

• CSRFの手口：「攻撃者が用意した罠のフォームから、ログイン中の利用者のブラウザで、意図しない要求を送信させる」

• CSRFトークンの不備：「トークンが利用者のセッションと結び付いていないので、攻撃者が自分で取得したトークンが使える」

• 対策：「CSRFトークンを利用者のセッションと結び付けて検証する」「SameSite属性をStrictまたはLaxにする」

6. ブラウザの仕組み：同一オリジンポリシー・CORS・セキュリティヘッダ

CORS：オリジンをまたぐ通信を、サーバが許可する仕組み

同一オリジンポリシーがあるため、あるサイトのページから読み込まれたスクリプトが、別のオリジンのWeb APIに対してXMLHttpRequestやfetchで送った要求の応答は、そのままでは読めません。それでも別のオリジンの資源を使いたいときに使うのが、CORS（Cross-Origin Resource Sharing）です。

CORSでは、API側のサーバがHTTPレスポンスヘッダで、どのオリジンからのアクセスを許可するかをブラウザに伝えます。

• Access-Control-Allow-Origin：アクセスを許可するオリジン

• Access-Control-Allow-Methods：使ってよいHTTPメソッド

• Access-Control-Allow-Headers：要求に含めてよいヘッダ

• Access-Control-Allow-Credentials：Cookieなどの認証情報を含む要求を許可するか

ブラウザは、要求の Origin ヘッダに送信元のオリジンを入れて送ります。サーバは、その値を許可するオリジンの一覧と照らし合わせ、一致したときだけ Access-Control-Allow-Origin にそのオリジンを入れて返します。単純でない要求（独自のヘッダを付ける、PUTやDELETEを使うなど）では、ブラウザが本番の要求の前にOPTIONSメソッドでプリフライトと呼ばれる確認を送ります。

注意点は、許可を広げすぎないことです。Access-Control-Allow-Origin に送られてきた Origin の値を無条件にそのまま返す実装では、どのサイトからでも応答を読めてしまいます。また、認証情報を含む要求ではアスタリスク（すべて許可）は使えない仕様になっているので、許可するオリジンを具体的に指定します。

セキュリティヘッダ：脆弱性が残ったときの被害を小さくする

HTTPレスポンスヘッダで、ブラウザの動きを制限できます。どれも脆弱性そのものを直すものではなく、残った脆弱性による被害を小さくする仕組みです。

• Content-Security-Policy（CSP）：ブラウザが実行してよいスクリプトの読込み元などを、サイトが指定する。script-src（スクリプトの読込み元）、default-src（個別に指定していない資源の既定値）、form-action（フォームの送信先）、frame-ancestors（自分のページを他のサイトに埋め込ませるか）などを指定する

• X-Frame-Options：自分のページを、他のサイトのframeやiframeの中に表示させるかを指定する。DENY なら一切禁止、SAMEORIGIN なら同一オリジンのページの中だけ許可する

• X-Content-Type-Options（nosniff）：ブラウザがファイルの中身から種類を推測する機能を止め、Content-Typeヘッダで指定した種類を強制的に適用させる

• Strict-Transport-Security（HSTS）：以後のアクセスで、ブラウザにHTTPSでの接続を強制させる。効果は max-age で指定した期間に限られ、初めてHTTPでアクセスしたときは守れない。詳しくは支援士解説3の1で扱う

• Cache-Control（no-store）：個人情報を含むページを、ブラウザなどにキャッシュさせない

クリックジャッキングは、攻撃者のページの上に、透明にした標的のサイトをiframeで重ねる攻撃です。利用者が標的のサイトにログインしたままだと、攻撃者のページのボタンを押したつもりで、透明な標的のサイトのボタン（退会、設定変更など）を本人の権限で押してしまいます。対策は、X-Frame-Options やCSPの frame-ancestors で、他のサイトに自分のページを埋め込ませないことです。

レスポンスヘッダにWebサーバの製品名やバージョンを出していると、既知の脆弱性を狙われやすくなります。不要な情報は出しません。

午後での問われ方

• 平成31年度春期 午後I問1：Web APIの設計が題材で、同一オリジンポリシーによる制限と、CORSを使った許可が問われました。解答例では、Access-Control-Allow-Origin に許可するオリジンを指定することや、要求の Origin ヘッダの値を許可するオリジンのリストと照合し、一致した場合に許可する処理が示されています。

• 令和6年度秋期 午後問4：脆弱性診断の報告書が題材で、セキュリティヘッダの効果が問われました。解答例には、サイトへの接続をHTTPSに強制できること（HSTS）や、Content-Typeヘッダで指定したMIMEタイプを強制的に適用できること（X-Content-Type-Options）が示されています。

記述の型

• CORSの設定：「Originヘッダの値を、許可するオリジンのリストと照合し、一致した場合だけAccess-Control-Allow-Originにそのオリジンを設定する」

• CSPの効果：「ブラウザが実行できるスクリプトの読込み元を、必要なドメインだけに限定できる」

• X-Content-Type-Optionsの効果：「Content-Typeで指定した種類を、ブラウザに強制的に適用させる」

• クリックジャッキングの対策：「X-Frame-Optionsやframe-ancestorsで、他サイトのiframeでの表示を禁止する」

7. 行き先を変える脆弱性：SSRF・オープンリダイレクト・ヘッダインジェクション

【図5】入力値が「行き先」を変える：SSRFとURLの検証

ここで扱う脆弱性は、入力値によって通信先、転送先、メールの宛先といった「行き先」が変わってしまうという共通の構図を持ちます。対策の基本も共通で、行き先を許可したものに限定することです。

SSRF：サーバに、内部への通信をさせる

SSRF（Server Side Request Forgery）は、公開しているWebサーバに不正なリクエストを送り、そのサーバを踏み台にして、外からは直接届かない内部のサーバなどへ通信させる攻撃です。

典型的なのは、「指定されたURLのページを、サーバが取ってきて表示する」機能です。URLを自由に指定できると、サーバは内部のサーバや管理画面にもアクセスしてしまいます。ファイアウォールが外からの通信を止めていても、通信の送信元は内部にある公開サーバ自身なので、内部の宛先に届きます（図5の上段）。

クラウドの仮想サーバには、サーバ自身からだけアクセスできるメタデータサービスがあります。特定のアドレス（たとえばIPアドレス169.254.169.254で始まるURL）にアクセスすると、そのサーバの設定情報や、クラウドのサービスを使うための認証情報（クレデンシャル）を返します。SSRFでここへアクセスさせれば、認証情報を盗めます。

メタデータサービスへのアクセス方式には、次の二つがあります。

• 方式1：特定のURLにGETでアクセスするだけで、情報を返す

• 方式2：まずトークンを発行するURLにPUTメソッドでアクセスしてトークンを手に入れ、そのトークンをリクエストのヘッダに含めないと情報を返さない

単純なSSRFで攻撃者が操れるのは、たいてい「サーバが取りに行くURL」だけです。メソッドをPUTに変えたり、ヘッダを付け足したりはできないので、方式2なら情報を取り出しにくくなります。

対策は次のとおりです。

• サーバが取りに行く先を、許可した宛先だけに限定する。名前解決した後のIPアドレスや、リダイレクト先も確かめる

• 公開サーバから内部のネットワークへ通信できる範囲を、ネットワーク側でも絞る

オープンリダイレクトとURLの検証の落とし穴

オープンリダイレクトは、URLのパラメータで指定された先へ利用者を転送する機能を悪用されることです。

https://www.example.com/login?redirect_url=https://evil.example/

本物のサイトから始まるURLなので利用者は安心してクリックしますが、攻撃者の偽サイトへ転送され、フィッシングに悪用されます。対策は、転送先を、登録しておいた許可リストの中に限定することです。

URLを検証するとき、「本物のサイトのURL（例：https://www.example.com）で始まっていればよい」と先頭だけを確かめると、次のようなURLが通ってしまいます（図5の下段）。

https://www.example.com.evil.example/
https://www.example.com@evil.example/

• 1つ目：ホスト名は右側ほど上位のドメインなので、これは evil.example というドメインの中のホスト。接続先は攻撃者のサーバ

• 2つ目：アットマーク（@）より前は利用者名として扱われ、接続先は evil.example

ホスト名は最初のスラッシュ（/）で終わります。そのため、ドメイン名の後ろのスラッシュまで含めて先頭が一致するかを確かめれば、ホスト名が本物と完全に一致するものしか通りません。

ヘッダインジェクション：改行で、ヘッダを付け足す

メールやHTTPのヘッダは、1行に1項目を書き、改行で区切ります。そのため、入力値に改行コード（CR・LF）が含まれると、そこから先が新しいヘッダとして扱われます。改行コードは、URLエンコードすると次の形になります。

%0d%0a

• メールヘッダインジェクション：入力値をもとにメールを送る機能で、改行コードを使ってBccなどのヘッダを付け足し、意図しない宛先にメールを送らせる。対策は、メールのヘッダを固定値にして入力値を出力しないこと、ヘッダに使う入力値に改行コードが含まれていたらエラーにすること、送信先のアドレスをhiddenフィールドなど利用者が書き換えられる場所に置かないこと

• HTTPヘッダインジェクション：入力値をもとに Set-Cookie や Location などのレスポンスヘッダを作る機能で、改行コードを使って任意のヘッダや本文を付け足される。勝手なCookieを発行されたり、偽の内容を表示されたりする。対策は、ヘッダを出力する専用の機能を使い、入力値の改行コードを確かめること。HTMLの改行タグ（brタグ）とは別物なので混同しない

午後での問われ方

• 令和6年度春期 午後問3：クラウド上のWebサイトのSSRFが題材でした。パラメータの値をメタデータサービスのクレデンシャル情報を返すURLに変える手口と、トークンを発行するURLにPUTメソッドでアクセスし、そのトークンをリクエストに含める方式の違いが問われました。

• 令和7年度春期 午後問3：スマートフォンのアプリが、カスタムURLスキームで受け取ったURLのページを開く機能が題材でした。そのページから認証トークンを取得する関数を呼べるかどうかを、呼出し元のURLの先頭が本物のドメインのURLかどうかだけで判断していた点が問われました。解答例には、本物のドメインの後ろに攻撃者のドメインを続けた形や、アットマークで攻撃者のドメインをつないだ形のURLが、この確認を通ってしまう例として示されています（上で示した2つの形と同じ）。

採点講評で指摘されたつまずき

• 令和6年度春期 午後問3では、クレデンシャル情報を取得する方式を問う設問で、二つの方式の違いに即して答えられていない受験者が多かったとされています。方式2では、PUTメソッドでトークンを得て、それをヘッダに含める必要がある点が鍵です。

• 令和4年度春期 午後I問1では、HTTPヘッダを付け足す攻撃に使う文字を問う設問で、HTMLの改行タグを選ぶ解答が多かったと指摘されています。HTTPのヘッダを区切るのは改行コード（CR・LF）で、HTMLのタグではありません。

記述の型

• SSRFの対策：「サーバが接続する先を、許可したURLだけに限定する」

• SSRFで狙われるもの：「クラウドのメタデータサービスから、認証情報を取得される」

• オープンリダイレクトの対策：「リダイレクト先を、許可リストに登録したURLだけに限定する」

• URLの検証の注意点：「ドメイン名の後ろのスラッシュまで含めて、先頭が一致するかを検証する」

• メールヘッダインジェクションの対策：「メールヘッダを固定値にし、入力値をヘッダに出力しない」

8. 認可の不備：IDを書き換えると他人のデータが見える

認証と認可は別の確認

• 認証：その人が本当に本人かを確かめる

• 認可：その人に、その対象への、その操作を許してよいかを決める

認証に成功したことは、何でも操作してよいことを意味しません。ログインした利用者Aが、利用者Bの注文履歴を見てはいけません。サーバは、リクエストのたびに「この利用者は、この対象に、この操作をしてよいか」を確かめます。

典型例：IDOR

もっとも典型的なのが、リクエストの中のIDを書き換えるだけで、他人のデータにアクセスできてしまう不備です（IDOR：Insecure Direct Object Reference と呼ばれます）。次のように注文番号で自分の注文を見られるAPIで、番号を書き換えたとき、そのIDの持ち主がログインしている本人かを確かめていなければ、他人の注文が見えます。

GET /api/orders?order_id=1001   （自分の注文）
GET /api/orders?order_id=1002   （番号を書き換えると、他人の注文が見える）

閲覧だけでなく、更新や削除でも同じです。

• 水平権限昇格：同じ権限の、ほかの利用者のデータにアクセスできてしまう（上の例）

• 垂直権限昇格：一般の利用者が、管理者向けの機能を使えてしまう

対策の考え方は一つです。「リクエストで指定された対象」と「認証で分かった本人」を、サーバ側で突き合わせる。リクエストの値は利用者がいくらでも書き換えられるので、画面に表示しない、ブラウザ側のJavaScriptで確かめる、といった方法は当てになりません。

• IDを推測しにくい値にするのは、補助的な対策です。IDが漏れれば、認可の確認がない限りアクセスできてしまいます

• APIごとに確認を書くと書き忘れが起きるので、認可の確認を共通の部品（モジュール）で行う設計にします

午後での問われ方

• 令和6年度春期 午後問1：スマートフォンのアプリと連携するAPIが題材でした。APIは、JWTで利用者を認証したうえで、パラメータで指定された利用者IDのデータを返していました。解答例の対策は、「JWTに含まれる利用者IDが、パラメータで指定された値と一致するかどうかを検証する」処理を、共通モジュールで行うことです。JWTそのものの検証（algがNONEでないことの確認など）は支援士解説2の4で扱います。

• 令和6年度春期 午後問3：ECサイトの注文情報が題材でした。注文を識別するコード（order-code）の下6桁を総当たりで試すと、他人の注文が見えてしまう不備が問われました。解答例の対策は、「cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違っていれば、エラーにする」というものです。IDを推測しにくくするだけでは、総当たりや漏えいに耐えられないことがよく分かる例です。

記述の型

• 認可の不備への対策：「リクエストで指定されたIDが、認証した利用者本人のものかを、サーバ側で検証する」

• 検証漏れを防ぐ設計：「認可の検証を、共通のモジュールで行う」

9. XMLとデシリアライズ：データの形式にも境界がある

XXE（XML External Entity）

XMLには、文書の中で「実体」を定義し、別の場所の内容を参照する機能があります。外部の実体を参照できる設定のまま、利用者から受け取ったXMLを読み込むと、次のような問題が起きます。

• XMLの中に、サーバ上のファイル（たとえばLinuxのパスワードファイル）を参照する実体を書かれ、その内容を応答に含めて返してしまう

• 内部のサーバのURLを参照する実体を書かれ、サーバが内部へ通信してしまう（7節のSSRFと同じ構図）

対策は、使わない機能をXMLパーサの設定で無効にすることです。外部実体の参照や、DTD（文書型定義）の処理を止めます。XMLを使わずに済む連携なら、JSONのような単純な形式を選ぶのも有効です。

安全でないデシリアライズ

デシリアライズは、保存や送信のために一続きのデータに変換したオブジェクトを、元のオブジェクトに戻す処理です。外部から受けたデータをそのまま復元すると、言語や形式によっては、復元の途中で意図しないメソッドが呼ばれ、任意のコードが実行されることがあります。

• 外部とのやり取りには、オブジェクトをそのまま復元する形式ではなく、JSONのような単純なデータ形式を使う

• 受け取る型と項目をあらかじめ決め、それ以外は受け付けない

• やむを得ず復元する場合は、改ざんされていないことを署名などで確かめる。ただし署名は改ざんの検知であって、送り主が悪意を持たないことの保証ではない

どちらも「データのつもりで受け取ったものが、処理系の中で命令や参照として働く」という点で、SQLインジェクションと同じ構図です。

10. メモリの安全性：C/C++では、領域の大きさと寿命を守る

【図6】メモリの安全性と多層の保護

C言語の文字列は、文字の後ろに終端文字（ヌル文字）を置きます。16バイトの配列に1バイト文字の文字列を入れるなら、終端文字の分を除いて最大15バイトです（図6）。日本語など複数バイトで表す文字では、見た目の文字数とバイト数は一致しません。

バッファオーバーフローは、確保した領域の外を読み書きしてしまう問題です。スタック上の配列からあふれた値が、関数の戻り先アドレス（関数の処理が終わった後に戻る場所。関数の戻り値とは別物）を書き換えると、攻撃者が用意した処理へ実行を移されるおそれがあります。

• コピーする前に、コピー先の大きさと終端文字の分を確かめる。strncpy のような長さを指定する関数でも、コピーする長さによっては終端文字を書かない場合があるので、仕様を確かめる。長い入力を切り詰めたときの動作も確かめる

• 必要な大きさの計算そのものが、整数のあふれ（整数オーバーフロー）を起こさないようにする

• 解放したメモリを後から参照するuse-after-freeは、大きさではなくメモリの寿命の問題。誰がいつ解放するかを明確にする

OSやコンパイラにも、攻撃の成立を難しくする仕組みがあります。

• DEP/NX：データ用の領域に置いたコードを実行させない

• ASLR：メモリの配置をランダムにし、アドレスを予測しにくくする

• スタックカナリア（スタック保護）：戻り先アドレスの手前に置いた値の変化から、上書きを検知する

ただし、これらは原因を直す代わりにはなりません。コードの欠陥を直したうえで、重ねて使います。

11. 競合状態：確認と更新の間に、別の処理が入る

【図7】確認と更新の間に、別の処理が入る

競合状態（レースコンディション）は、複数のプロセスやスレッドが同じ資源にほぼ同時にアクセスすることで、予定外の結果が生じる問題です。

予約の受付枠が残り1件のとき、二つの要求が同時に「空きあり」を確かめ、それぞれ予約を成立させると、枠を超えて受け付けてしまいます（図7）。確かめた時点と使う時点の間に状態が変わる問題は、TOCTOU（Time of Check to Time of Use）とも呼ばれます。対策は、確認と更新を一つの単位として扱うことです。たとえば「残数が1以上なら1減らす」という条件付きの更新をデータベースの中で一度に行う方法があります。複数の表にまたがる処理では、適切なロックとトランザクションの分離レベル、データベースの制約、失敗したときのロールバックを組み合わせます。複数のサーバが同じデータベースを使う構成では、1台のサーバのメモリ上のロックだけでは守れません。

Webアプリでは、複数の利用者のリクエストが同時に処理されます。Javaで static を付けて宣言した変数（クラス変数）や、サーブレットのインスタンス変数は、同時に処理されている複数のリクエストで共有されることがあります。ここに利用者ごとの情報を入れると、処理の途中で別の利用者の値に上書きされ、他人の情報が表示されることがあります。対策は、利用者ごとの情報をメソッドの中のローカル変数に置くことです。

午後での問われ方

• 令和5年度春期 午後I問1：Javaのソースコードが題材で、共有される変数（static で宣言した変数）が原因で起きる不具合の名称として、「レースコンディション」が問われました。同じ大問では、2節のプレースホルダも問われています。採点講評では、この名称を問う設問の正答率が低かったとされ、設計・実装・テストの各段階での対策も確認するよう求めています。

12. 午後のコード読解の進め方

午後のWebアプリの問題では、ソースコードやHTTPのやり取りの一部が示され、「どの行に問題があるか」「空欄に何が入るか」「どう直すか」が問われます。次の順で読むと、見落としが減ります。

1. 外から来る値を探す：リクエストのパラメータ、Cookie、ヘッダ、アップロードされたファイル、外部APIの応答を受け取っている行に印を付ける

2. 値を追いかける：その値を代入した変数が、どの処理に渡るかをたどる。途中で検証やエスケープをしているか

3. 利用先の種類を確かめる：SQL文の組立て、HTMLの出力、innerHTML、OSコマンドの実行、ファイルのパス、通信先のURL、レスポンスヘッダのどれか。種類によって必要な対策が決まるので、各節の「記述の型」を当てはめる

4. 本人の確認を探す：IDなどで対象を指定している処理では、その対象が認証した本人のものかを確かめている行があるか

5. 共有されるものを探す：static の変数、インスタンス変数、同時に更新される資源はないか

空欄補充では、問題文に示されたほかの箇所のコード（同じクラスの別のメソッドなど）に、正しい書き方の手がかりがあることが多いです。たとえば、ほかの箇所でプレースホルダを使っていれば、空欄にも同じ形が入る可能性が高くなります。

読み方の実例

次は、説明のために作った短いJavaのコードです（実際の過去問ではありません）。注文番号を受け取り、注文の備考を画面に表示します。

String id = request.getParameter("order_id");                        // 1
String sql = "SELECT * FROM orders WHERE order_id = '" + id + "'";   // 2
ResultSet rs = stmt.executeQuery(sql);                               // 3
out.println("<p>" + rs.getString("note") + "</p>");                  // 4

上の手順を当てはめると、次の三つの欠陥が見つかります。

• 1行目から2行目：外から来た id が、文字列連結でSQL文に入っている。SQLインジェクション。2行目と3行目を、プレースホルダと PreparedStatement に置き換える

• 2行目：指定された注文が、ログイン中の利用者のものかを確かめていない。IDを書き換えれば他人の注文が見える認可の不備。条件に利用者IDを加えるか、取得した注文の持ち主を確かめる

• 4行目：データベースから取り出した備考を、エスケープせずにHTMLとして出力している。備考が利用者の入力なら格納型XSS。出力時にエスケープする

一つのコードに、利用先の違う欠陥が並んでいることがよくあります。1行ずつ「この値はどこから来て、何として使われるか」を問えば、見落としが減ります。

脆弱性と対策の対応一覧

• SQLインジェクション：利用先はSQL文。根本対策はプレースホルダ。保険はWAF、DB権限の最小化、エラーを表示しないこと

• OSコマンドインジェクション：利用先はシェル。根本対策はシェルを起動する関数を使わないこと

• パストラバーサル：利用先はファイルのパス。根本対策は外部の値でファイル名を指定しないこと、ファイル名だけを取り出すこと

• XSS（反射型・格納型）：利用先はHTML。根本対策は出力時のエスケープ。保険はCSP、HttpOnly

• XSS（DOM-based）：利用先はブラウザのDOM。根本対策は textContent など文字として扱うAPI

• CSRF：利用先は状態を変える要求。根本対策はセッションと結び付けたCSRFトークン。補助はSameSite属性、再認証

• SSRF・オープンリダイレクト：利用先は通信先・転送先。根本対策は許可リストによる限定

• ヘッダインジェクション：利用先はメールやHTTPのヘッダ。根本対策はヘッダを固定値にすること、改行コードを拒否すること

• 認可の不備：利用先は対象を指定する処理。根本対策はサーバ側での本人の確認

• 競合状態：利用先は共有される状態。根本対策は確認と更新を一つの単位にすること

13. コーディング標準とレビュー

シラバスの小項目2-5には、セキュアプログラミングの原則・実践規範と、それに沿った実装のレビューが含まれます。実務では、次のことを決めておくと、レビューで確かめやすくなります。

• コーディング標準：言語やフレームワークごとに「何をしないか」「どう書くか」を具体的に書く。例：SQLは値をバインドする、画面への出力は自動エスケープのあるテンプレートや textContent を使う、シェルの呼出しは原則として避ける、アップロードされたファイル名を保存パスに使わない

• 統合開発環境（IDE）：警告、型の検査、静的解析の結果を、書いている場所で示してくれる。ただし警告がゼロでも、認可の誤りや競合状態がないことの証明にはならない

• レビュー：「入力 → 変換 → 利用先」をたどり、標準どおりか、例外処理や同時実行で条件が崩れないかを人が確かめる。使っているライブラリと、その更新の方針も対象に入れる

ツールによる検査（静的解析、動的な診断、依存部品の検査）の使い分けは、支援士解説2の6で扱います。

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　並び順の指定

画面で一覧の並び順を利用者に選ばせる。SQL文の組立てとして、最も適切なものはどれか。

• ア：利用者が選んだ文字列を、ORDER BY の後ろにそのまま連結する

• イ：並び順の指定もプレースホルダで渡せば安全である

• ウ：利用者の選択を、プログラム側で決めた列と順序の候補に置き換えて使う

• エ：利用者の選択から記号を取り除いてから連結する

正解：ウ。列名や並び順はSQLの構造なので、値のバインドでは扱えません（イ）。プログラム側で決めた候補から選ばせます。アとエは、構造に入力値が入り込む余地が残ります。

問2　DOM-based XSS

次の処理がある。最も適切な対策はどれか。

element.innerHTML = location.hash.slice(1);

• ア：サーバ側で、レスポンスのHTMLをエスケープする

• イ：innerHTML ではなく textContent で書き込む

• ウ：Cookieに HttpOnly 属性を付ける

• エ：URLの「#」以降をサーバのログで監視する

正解：イ。「#」以降はサーバに送られないので、サーバ側の処理（ア）やログの監視（エ）では対処できません。ウはCookieの読取りを防ぐだけで、スクリプトの実行は止められません。

問3　CSRFトークン

CSRFトークンを検証しているが、別の利用者のアカウントで取得したトークンでも処理が成功する。この状態で起き得ることとして、最も適切なものはどれか。

• ア：攻撃者が自分で取得したトークンを罠のフォームに入れ、ログイン中の利用者に送信させる

• イ：攻撃者が利用者のCookieを読み取り、外部へ送信する

• ウ：攻撃者がSQL文の構造を変え、テーブル名を特定する

• エ：攻撃者がサーバに内部ネットワークへの通信をさせる

正解：ア。トークンが利用者のセッションと結び付いていないため、攻撃者のトークンでも通ります。イはXSS、ウはSQLインジェクション、エはSSRFの説明です。

問4　リダイレクト先の検証

リダイレクト先のURLが「https://www.example.com」で始まるかだけを確かめている。この検証を通過して、攻撃者のサーバへ転送されるURLはどれか。

ア：https://www.example.com/news/
イ：https://www.example.com.evil.example/
ウ：https://www.example.com/login?next=/top
エ：https://www.example.com:443/

正解：イ。ホスト名は www.example.com.evil.example で、evil.example ドメインのホストです。ドメイン名の後ろのスラッシュまで含めて確かめれば防げます。

問5　注文情報のAPI

次のリクエストで、ログイン中の利用者の注文を返すAPIがある。order_idの値を書き換えると、他人の注文が見えた。根本的な対策として、最も適切なものはどれか。

GET /api/orders?order_id=1001

• ア：order_id を推測しにくいランダムな値にする

• イ：画面に order_id を表示しないようにする

• ウ：指定された注文が、ログイン中の利用者のものかをサーバ側で確かめる

• エ：通信をHTTPSにする

正解：ウ。指定された対象と認証した本人を、サーバ側で突き合わせます。アは補助的な対策で、IDが漏れれば防げません。イとエは、値の書き換えを防ぎません。

実務と国・自治体では

実務では、脆弱性の名前を知っていることより、仕様と受入れの確認に落とし込めるかが問われます。調達の仕様書に脆弱性名を並べるだけでは、実装と受入れがつながりません。たとえば、次のように対応させます。

• 仕様：検索条件は値としてバインドし、並び順は許可した候補から選ぶ。受入れ：引用符を含む正当な地名や氏名でも、条件が変わらずに検索できることを確かめる

• 仕様：申請本文は職員の画面でテキストとして表示する。受入れ：保存した入力が、別の利用者の画面で命令として動かないことを確かめる

• 仕様：承認や変更の操作には、CSRF対策と対象ごとの認可を設ける。受入れ：トークンが欠けた要求や、権限のない職員の操作を拒否することを確かめる

政府機関等の統一基準や、総務省の自治体向けガイドラインにも、既知の種類のWebアプリケーションの脆弱性を開発時に排除する対策が示されています。これらの位置付けと読み方は支援士解説1の1で扱います。

まとめ

• どの脆弱性も「値の使い道」で読める。 値がSQLの命令、HTMLのタグ、通信の行き先、他人のデータの指定になる場所が、境界の崩れる場所。

• 対策は利用先ごとに決まる。 SQLはプレースホルダ、HTMLは出力時のエスケープ、DOMは textContent、行き先は許可リスト、対象の指定はサーバ側での本人確認。

• CSP・HttpOnly・WAF・権限の最小化は保険。 被害を小さくするが、欠陥そのものは直らない。

• CSRFトークンはセッションと結び付けて検証する。 POSTにしただけ、確認画面を置いただけでは防げない。

関連記事

• 前提：ログインできれば、安全なのか｜支援士解説2の4（セッション管理・Cookie属性・JWT）

• 次に読む：脆弱性検出ゼロなら、安全と言えるのか｜支援士解説2の6（脆弱性の見つけ方）

• あわせて読む：ログインできれば、その先まで見てもいい？｜支援士解説3の8（認可と権限管理）

2026年10月改訂：午後の出題例と記述の型を加え、構成を見直しました。