情報処理安全確保支援士（SC、登録セキスペ）の科目B（旧・午後問題）で、いちばん出やすいのがWebアプリケーションの脆弱性の問題です。令和5年秋期以降の新形式5回では、毎回1問以上出ています。
この記事では、Web系の過去問4問を使って、「なぜその答えになるのか」「問題文のどの文に着目すれば答えが出るのか」を解説します。答えはIPAの解答例、つまずきやすい設問はIPAの採点講評で確認しています。分析にはAI（Claude）も使っています。
科目B全体の出題傾向（出やすい分野ランキング・問題文のクセ・過去問リンク集）は、科目Bの出題傾向を10回分分析した記事にまとめています。この記事は、その分野別シリーズの1本目です。
結論：Web問題は「3つの着眼点」で解ける
4問を並べてみると、答えの根拠になる文の場所はほぼ決まっていました。
- 入力した値が「どの画面に」出力されるかを追う。入力した画面と表示される画面が違えば格納型XSS。表示される画面は、問題文の機能一覧の表から探す
- ブラウザの動きは、問題文に書かれた設定（ヘッダー・属性）だけで判定する。CSPの
default-src 'self'、cookieに付いている属性（HttpOnly・SameSite）を見る - 攻撃者の手順は、機能一覧の表の部品を組み合わせて作る。「誰が」「どの機能で」「何を取れるか」は、表の説明欄に書いてある
XSSやCSRFの知識そのものより、問題文の表と図から根拠を拾えるかが点数を分けています。採点講評でも「本文の状況に即して解答してほしい」という趣旨の指摘が繰り返し出てきます。
この記事で使う過去問4問
| 回 | 題材 | 出てくる脆弱性・技術 | 採点講評で正答率が低かった設問 |
|---|---|---|---|
| 令和5年秋期 問1 | ECサイトの商品レビュー | 格納型XSS、cookieの窃取 | 設問1(1)でDOM Based XSSと誤答する受験者が散見 |
| 令和6年春期 問3 | クラウド上のWebサイトの診断 | XSS、CSRF、SameSite属性、認可制御の不備、SSRF | 設問1(2)・設問2(1)の正答率が低い |
| 令和6年秋期 問3 | ECサイトのWebスキミング | XSSの種類、偽フォーム、カード情報の漏えい | 設問1c・設問2(1)の正答率がやや低い |
| 令和7年秋期 問1 | SaaSでの従業員による攻撃 | CSP、XSS、CSRFトークンの奪取、ファイルアップロード | 設問1・設問2(5)がやや低い、設問4が低い |
先に問題を解いてから読みたい方は、上の表のリンクから問題PDFを開いてください。以下、答えに触れます。
令和5年秋期 問1（問題PDF）：レビュー欄に分割して仕込まれたXSS
ECサイトの商品レビューページで、「16件表示されるはずのレビューが2件しか表示されない」という問合せから始まる問題です。
設問1(1)：XSSの種類は「格納型」
着目する文： 図1の「商品レビューを投稿したり閲覧したりするページを提供する」と、図3のHTML。
攻撃者（会員A）が投稿したレビューがサーバに保存され、ページVを開いた別の会員のブラウザでスクリプトが実行されています。保存されてから表示されるので、答えはイ 格納型XSSです。
採点講評によると、スクリプトの中でDOMを使っていたためか、「DOM Based XSS」と誤答した受験者が散見されました。種類は「スクリプトの中身」ではなく、「どこから入って、どこで出力されたか」で決まります。
| 種類 | 入力値の流れ | 見分けるポイント |
|---|---|---|
| 反射型 | リクエストに含めた値が、そのままレスポンスに出る | わなリンクを踏ませる。表示されるのは踏んだ本人だけ |
| 格納型 | 投稿などで保存された値が、後で別の画面に出る | 1回の攻撃で、見に来た多数の利用者が被害に遭う |
| DOM Based | サーバを通らず、ページ内のJavaScriptがURLなどを読んでDOMに書き込む | サーバのレスポンスには攻撃文字列が出てこない |
設問1(2)の対策は、解答例では「レビュータイトルを出力する前にエスケープ処理を施す」です。「入力時にチェックする」ではなく、出力時のエスケープが定番の答えです。
設問2：文字数制限をどう超えたか
着目する文： 図1の「レビュータイトルとレビュー詳細の欄は（中略）それぞれ50字と300字の入力文字数制限を設けている」と、図3のレビュータイトルの中身。
図3のレビュータイトルを並べると、こうなっています。
<div class="review-title">Good<script>xhr=new XMLHttpRequest();/*</div>
<div class="review-title">*/url1="https://□□□.co.jp/user/profile";/*</div>
（省略）
<div class="review-title">*/xhr2.send(form);}</script></div>各タイトルの末尾が/*、次のタイトルの先頭が*/です。間にあるHTMLタグがJavaScriptのコメントになり、15件のレビューがつながって1つのスクリプトになる仕組みです。だからレビューが2件しか表示されなかった、という冒頭の問合せにもつながります。
解答例は「HTMLがコメントアウトされ一つのスクリプトになるような投稿を複数回に分けて行った」です。採点講評では、「開発者ツールで入力制限を削除してから投稿した」のように、HTMLを確認していない解答が一部に見られたと書かれています。答えの根拠は、必ず図の中にあります。
設問3：スクリプトは何をしているか
着目する文： 図1の会員プロフィール機能の説明と、問題文の最後の「HttpOnly属性を付与していないこと及びアップロードされた画像ファイルの形式をチェックしていないこと」。
図4のスクリプトは、document.cookie（セッションID）を中身にしたa.pngというファイルを作り、アイコン画像としてアップロードしています。図1には、アイコン画像はレビューページにも表示されると書いてあります。
- 設問3(1)：XHRで取得したトークンと一緒に、セッションIDをアイコン画像としてアップロードする
- 設問3(2)：攻撃者は、会員のアイコン画像をダウンロードして、セッションIDの文字列を取り出す
- 設問3(3)：ページVにアクセスした会員になりすまして、Webアプリの機能を使う
「HttpOnlyがない」「画像の形式をチェックしていない」という2つの不備は、本文の最後にヒントとしてわざわざ書かれています。問題文の後半に出てくる「〜していないこと」は、ほぼ確実に設問で使う情報です。
設問4：別ドメインから同じスクリプトを動かしても失敗する理由
攻撃者が自分のドメインのサイトに同じスクリプトを置いても、攻撃は成功しません。解答例は「スクリプトから別ドメインのURLに対してcookieが送られない仕組み」です。同じスクリプトでも、ECサイト自身のページで動くからcookieが使える、というのが格納型XSSの怖さです。
令和6年春期 問3（問題PDF）：診断で見つかったXSSとCSRF
リリース前のWebアプリ診断で、XSS・CSRF・認可制御の不備・SSRFが見つかる問題です。採点講評では全体の正答率が「やや低かった」とされています。ここではXSSとCSRFを扱います。
設問1(1)：XSSが出力されるのはどの機能か
着目する文： 「図3中のレスポンスボディには，問合せ機能で入力した値は出力されていない」と、表1のサイトXの機能一覧。
問合せ機能で入力したスクリプトは、その場の画面には出ません。では、問合せの内容を表示するのはどの画面かを表1から探します。表1には「問合せ管理機能：問合せ機能で入力された問合せ情報が閲覧できる」とあり、答えは項番9です。
ここで分かるのは、スクリプトが実行されるのは問合せ管理機能を使う人、つまり管理者のブラウザだということです。これが設問1(2)につながります。
設問1(2)：全会員の利用者情報をどう取るか
着目する文： 「SESSIONIDには，値とSecure属性だけがセットされる」、表1の「会員管理機能（閲覧，変更，削除）」、「サイト管理機能は（中略）接続元の制限は行わない」。
採点講評でも、正答率が低かった理由として「スクリプトを実行できるのは管理者であること」と「利用者情報は会員管理機能で取得できること」の2つを結びつけられていない点が挙げられています。
組み立てると、次の流れになります。
- HttpOnly属性がない → スクリプトで管理者のcookieを読める
- 管理者のブラウザでスクリプトを動かし、cookieを攻撃者のサイトに送らせる
- 接続元の制限がない → 攻撃者はそのcookieでサイト管理機能にアクセスできる
- 会員管理機能で全会員の利用者情報を取得する
解答例は「攻撃者がわなリンクを用意し，管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のWebサイトに送信させ，その値を読み取って利用することで管理者としてサイトXにアクセスし，利用者情報を取得する」です。解答例は「わなリンクを踏ませる」という書き方なので、管理者にスクリプトを実行させるきっかけまで書くのが安全です。HttpOnlyがない・接続元を制限しない、という一見地味な記述が、答えの部品になっています。
設問2(1)：CSRF対策の「穴」はどこか
着目する文： 表2の手順3。
| 手順 | csrf_tokenの値 | 応答 |
|---|---|---|
| 1 | 空 | エラー |
| 2 | パラメータ自体なし | エラー |
| 3 | 異なる利用者アカウントで取得したcsrf_tokenの値 | 正常に処理 |
手順3から、トークンが利用者（セッション）と紐付いていないことが分かります。攻撃者は自分のアカウントで正しいトークンを取得し、それを埋め込んだわなフォームを作れば、ほかの利用者に利用者情報を変更させられます。
採点講評では、「攻撃者が取得したトークンを悪用する部分」を書けていない受験者が多かったとされています。CSRFの一般的な説明（わなページに誘導する）だけでは足りず、この問題の穴（他人のトークンが通る）を手順に入れる必要があります。
設問2(2)：SameSite属性の表を埋める
表3は、外部のWebサイトからサイトXに遷移したときに、cookieが送られるかどうかです。
| SameSite属性の値 | 外部サイトから遷移（GET） | 外部サイトから遷移（POST） |
|---|---|---|
| Strict | a：× | b：× |
| Lax | c：○ | d：× |
Strictは外部からの遷移では一切送らず、LaxはリンクをたどるようなGETの遷移だけ送ります。CSRFで使われるPOSTのわなフォームは、Laxでも防げる、というのがこの表のポイントです。
令和6年秋期 問3（問題PDF）：Webスキミングで偽フォームが出た
「クレジットカード情報を入力する画面が2回表示される」という問合せから始まる問題です。実際の原因は、Webサーバ上のJavaScriptファイル（customize.js）がPUTメソッドで置き換えられたことでした。
設問1：アクセスログから攻撃を読む
着目する文： 表2のアクセスログと、Gさんの「1回の攻撃で多数の利用者に対して偽フォームの表示が可能です」。
- 5行目の
/cart?add="><script>document.getElementById(…は、XSSを狙った攻撃（a：5、b：クロスサイトスクリプティング） - 「1回の攻撃で多数の利用者に」表示できるのは、保存されて多くの人に表示される格納型（c）
- 2行目の
/login?id=hoge&pw=' UNION select 1 FROM…は、SQLインジェクション（d：2、e）
採点講評では、cの正答率がやや低く、「ログから攻撃を分析するためにも」XSSの3種類の違いを理解してほしいと書かれています。令和5年秋 問1と同じ論点が、翌年また出ているということです。
設問2：書き換えられた画面と、パラメータの改ざん
着目する文： 図2（整形後のファイルK）の3行目と、図3の配送先・支払方法選択画面のHTML。
ファイルKの3行目は、支払方法のラジオボタンが入ったdiv.radioの中身を、カード番号などの入力欄と<input type="hidden" name="order[Payment]" value="1">に置き換えています。
- 設問2(1)：書換え後の画面を図示する。支払方法のラジオボタン（クレジットカード決済・銀行振込）が消え、カード情報の入力欄に置き換わる
- 設問2(2)：パラメータ名
order[Payment]、値1。図3でクレジットカード決済のラジオボタンがvalue="1"なので、支払方法がクレジットカード決済に固定される
採点講評では、設問2(1)で「書換え対象のラジオボタンの選択肢が残っていた」など、過不足のある解答が散見されたとされています。innerHTMLは「中身を丸ごと置き換える」ので、元のラジオボタンは残りません。
設問3：404が返ってきても、カード情報は盗まれている
着目する文： 図2の12〜14行目と、Rさんの「404のステータスコードが返ってきた」。
ファイルKは、入力されたカード情報をURLのクエリパラメータに連結して、攻撃者のサーバにGETで送っています。Webアプリケーションが用意されていなくても、Webサーバのアクセスログにはリクエストされた URI が残るので、攻撃者はそこからカード情報を取り出せます（設問3(1)）。
採点講評では、「通信を盗聴する」「キーロガーを仕掛ける」といった解答が散見されたとされています。図2のコードがGETでクエリパラメータに載せていることに気付けるかどうかが分かれ目でした。
設問3(2)の f は「配送先・支払方法選択画面にアクセスしたアカウント名」です。本文の「送信していない利用者はできるだけ含めたくない」「直前までの操作をした利用者」という条件から、偽フォームが表示される画面までたどり着いた人に絞り込みます。
令和7年秋期 問1（問題PDF）：CSPをすり抜けたXSS
一般利用者だった元従業員が、自分に割り当てられていないプロジェクトのファイルを持ち出していた、という問題です。直近の回で、CSP（Content Security Policy）が設問の中心になりました。
設問1：default-src 'self' で何ができなくなるか
着目する文： 図1のHTTPレスポンスヘッダーのContent-Security-Policy: default-src 'self';。
- a：Sサービス以外のドメインからのリソースの読込み → できない
- b：scriptタグ内に直接記述されたスクリプトの実行 → できない
'self'は「同じオリジンからの読込みだけ許可する」という意味です。そして、CSPを設定すると、'unsafe-inline'を書かない限りインラインスクリプト（タグ内に直接書いたスクリプト）は実行されません。採点講評では設問1の正答率はやや低く、CSPの内容や緩和効果について理解を深めてほしいとされています。
設問2：攻撃の流れを、表1の機能から組み立てる
着目する文： 表1の「プロジェクト進捗管理」の説明欄と、図2・図3。
表1には「未完了のタスクのうち締切日を過ぎたものは，プロジェクト進捗管理画面にそのタスク名と締切日からの経過日数が表示される」とあります。図2では、このタスク名の部分に<script src="/files/F1234567890.xlsx"></script>が出力されています。
| 設問 | 答え | 根拠 |
|---|---|---|
| (1) 悪用された機能 | ロール管理 | 図3が/management/rolesetにis_admin: "1"を送っている |
| (2) c | タスク名 | 表1でタスク名が画面に表示される |
| (3) d | 個人タスク<script src="/files/F1234567890.xlsx"></script> | 図2から抜き出す |
| (4) e・f・g | 管理者／タスクの締切日を過ぎる／利用者のロールを管理者に設定する | ロール管理は管理者の機能。表示されるのは締切日を過ぎたタスク |
ロール管理は管理者しか使えない機能なので、管理者のブラウザでスクリプトを動かす必要があります。そのため、管理者が見るプロジェクト進捗管理画面に表示されるよう、締切日を過ぎるのを待っていた、という流れです。
設問2(5)：CSPをどうやって回避したか
着目する文： 「（類似したタスクの）攻撃は，CSPの設定で防御できていた」と、表1のスレッド投稿機能の「アップロードできるファイルの拡張子は（中略）7種類である」。
最初の攻撃は、タスク名に直接スクリプトを書いたのでCSPに止められました（設問1のb）。そこで攻撃者は、スクリプトを.xlsxファイルとしてSサービス自身にアップロードし、<script src="/files/…">で読み込ませました。同じオリジンのファイルなので、'self'の条件を満たしてしまいます。
解答例は「図3のスクリプトをSサービス内にアップロードする工夫」です。採点講評でも、設問2(5)はやや正答率が低く、「CSPによる制御を回避する攻撃手法」について理解を深めてほしいと書かれています。CSPは万能ではなく、同じオリジンに攻撃者がファイルを置ければ回避される、という点が出題者の狙いだと考えられます。
設問3・4：対策と開発プロセス
| 設問 | 答え（解答例） | 根拠 |
|---|---|---|
| 3(1) h | アップロードされたファイルの形式が拡張子と整合しているかをチェックする | 拡張子だけのチェックだったので、中身がスクリプトでも通った |
| 3(2) i | プロジェクト進捗管理 | タスク名を表示している画面 |
| 3(3) | 出力時にエスケープ処理を施す | 令和5年秋 問1と同じ定番の答え |
| 4 j | Sサービスの仕様を理解した専門家による脆弱性検査 | 「診断ツールXで検知されないもの」を見つける検査 |
設問4は正答率が低く、採点講評では「ログ分析を行う」「WAFを導入する」「多要素認証の仕組みを導入する」など、運用や製品導入の解答が散見されたとされています。問われているのは開発プロセスで、すでに挙がっているSAST（ソースコードの静的解析）と並ぶ「検査」です。設問の見出し（〔開発プロセスの見直し検討〕）の枠から外れないことが大事でした。
4問に共通する「問題文のここを見る」チェックリスト
| 問題文に出てきたら | 何に使うか | 出てきた問題 |
|---|---|---|
| 機能一覧の表（○○管理機能：〜を閲覧できる） | XSSの出力先、攻撃者が使う機能、被害の範囲 | 全4問 |
| cookieの属性（HttpOnlyがない、Secureだけ） | スクリプトでcookieを読める → 窃取・なりすまし | 令和5年秋 問1、令和6年春 問3 |
CSPヘッダー（default-src 'self'） | 外部読込み・インラインスクリプトはできない。同じオリジンのファイルは読める | 令和7年秋 問1 |
| CSRFトークンを使ったリクエストの表 | トークンがセッションと紐付いているか | 令和6年春 問3、令和7年秋 問1 |
| 「〜をチェックしていない」「〜の制限は行わない」 | ほぼ確実に設問で使う。攻撃手順の部品になる | 令和5年秋 問1、令和6年春 問3、令和7年秋 問1 |
| アクセスログの表 | URIの中身で攻撃の種類を判定。クエリに載った情報はログに残る | 令和6年秋 問3 |
| 「1回の攻撃で多数の利用者に」 | 格納型XSS | 令和6年秋 問3 |
CBT方式の科目Bでは、問題文にマーカーを引けます。「〜していない」「〜は行わない」という否定の記述に色を決めてマーカーを引いておくと、設問を解くときに探しやすくなります。
最低限おさえる知識はこれだけ
Web問題で、問題文に説明がないまま前提にされていた知識は、次のくらいでした。
| 知識 | 押さえるポイント |
|---|---|
| XSSの3種類 | 反射型・格納型・DOM Based。「どこから入り、どこで出力されたか」で見分ける |
| XSSの対策 | 出力時のエスケープ処理 |
| HttpOnly属性 | 付いていないと、JavaScriptでdocument.cookieを読める |
| SameSite属性 | Strictは外部からの遷移で送らない。LaxはGETの遷移だけ送る |
| CSRFトークン | 推測できないだけでなく、セッション（利用者）と紐付けて検証する |
| CSP | default-src 'self'で外部の読込みとインラインスクリプトを止める。同じオリジンのファイルは止められない |
| innerHTML | 要素の中身を丸ごと置き換える |
コードの読み方は、科目Bのコード問題を全部解説した記事にまとめています。令和5年秋 問1と令和6年秋 問3のスクリプトは、そちらでも扱っています。
過去問の解説動画を見るなら
過去問の解説動画には、Udemyの講座を使っています。科目Bの過去問解説（令和7年秋・令和7年春・令和6年秋）と、XSS・CSRFなどを短く解説する「小問題解説」が入っていて、この記事で扱った論点を動画で見直せます。
令和8年度対応｜参考書の著者が教える 情報処理安全確保支援士 科目A・科目B対策（Udemy）
講座の内容を見る
まとめ
- Web問題は新形式で毎回出る。4問を並べると、答えの根拠は「機能一覧の表」「cookieやCSPの設定」「〜していない、という記述」にほぼ集まっている
- XSSの種類は「どこから入り、どこで出力されたか」で決まる。DOMを使ったスクリプトでも格納型になる
- CSRFは、一般論ではなくこの問題のトークンの穴を手順に入れる
- CSPは同じオリジンに置かれたファイルで回避される
- 対策を問われたら、設問の見出しの枠（開発プロセス、Webアプリに追加すべき処理など）から外れない
Web系を確実に取る分野にするなら、この4問を解き直すのがおすすめです。解き直すときは、答えを覚えるのではなく、根拠になった文がどこにあったかを確認すると、初めて見る問題でも同じ場所を探せるようになります。
シリーズ2本目では、認証・API・スマホアプリの問題（JWT・セッション固定・アクセスキー）を解説しています。
この分野の攻撃と基本の対策の組み合わせは、聞き流し用の一問一答動画（攻撃と対策・42問・YouTube）でも耳で復習できます。
関連記事
- 情報処理安全確保支援士 科目B（午後）の出題傾向を分析｜出やすい分野ランキングと過去問リンク集
- 支援士 科目B（午後）のコード問題を全部解説｜「書く」はJava・SQL・正規表現の定番だけ
- 【受験結果84点】情報処理安全確保支援士 科目A-2の問題予想と新規問題対策
- 情報処理安全確保支援士（登録セキスペ）に挑戦します【学習計画・教材】
- 支援士 科目B（午後）のインシデント対応・ログ解析問題の解き方｜ログは「時系列に並べて、2つのログで裏付ける」【過去問2問で解説】
参考にした情報
- IPA 過去問題（令和5年度秋期 午後 問1、令和6年度春期 午後 問3、令和6年度秋期 午後 問3、令和7年度秋期 午後 問1の問題・解答例・採点講評）
- IPA 安全なウェブサイトの作り方
この記事で引用した問題文・コード・解答例は、IPAが公開している過去問題からの抜粋です。一部を省略・要約し、表の形に整理しています。
よくある質問（FAQ）
Q1. 支援士の科目Bで、Webアプリの問題は毎回出ますか？
令和5年秋期〜令和7年秋期の新形式5回では、毎回1問以上、Webアプリかスマホアプリの脆弱性を主題にした問題が出ています。XSSは令和5年秋 問1、令和6年春 問3、令和6年秋 問3、令和7年秋 問1の4問で問われました。
Q2. XSSの種類（反射型・格納型・DOM Based）は、どう見分ければいいですか？
攻撃文字列が「どこから入り、どこで出力されたか」で見分けます。投稿などで保存され、後で別の画面に表示されるなら格納型です。令和5年秋 問1では、スクリプトがDOMを使っていたためにDOM Based XSSと誤答する受験者が多かったと、IPAの採点講評に書かれています。
Q3. CSPを設定していれば、XSSは防げますか？
完全には防げません。令和7年秋 問1では、CSPの default-src ‘self’ でインラインスクリプトは止められていましたが、攻撃者がスクリプトをxlsxファイルとして同じサービス内にアップロードし、scriptタグで読み込ませることで回避しました。出力時のエスケープと、アップロードされたファイルの形式のチェックが対策として問われています。
Q4. Web問題の対策を問われたとき、何を書けばいいですか？
設問の見出しの範囲で答えます。令和7年秋 問1の設問4は開発プロセスの見直しを問うていましたが、ログ分析やWAFの導入など、運用や製品導入の解答が多く、正答率が低かったと採点講評に書かれています。XSSそのものの対策なら、出力時のエスケープ処理が定番の答えです。