支援士 科目B（午後）の認証・API・スマホアプリ問題の解き方｜JWT・セッション固定・アクセスキーは「仕様の一文」で解く【過去問3問で解説】

情報処理安全確保支援士（SC、登録セキスペ）の科目B（旧・午後問題）で、Web系の次に出やすいのが認証・API・スマホアプリの問題です。JWT、セッションID、APIkey、アプリに埋め込んだ鍵など、「利用者を誰だと判断しているか」を突く問題がまとまって出ています。

この記事では、この分野の過去問3問を使って、「なぜその答えになるのか」「問題文のどの文に着目すれば答えが出るのか」を解説します。答えはIPAの解答例、つまずきやすい設問はIPAの採点講評で確認しています。分析にはAI（Claude）も使っています。

科目B全体の出題傾向は、科目Bの出題傾向を10回分分析した記事にまとめています。この記事は、その分野別シリーズの2本目です。1本目はWeb問題（XSS・CSP・CSRF）の解き方です。

結論：認証・API問題は「3つの着眼点」で解ける

3問を並べてみると、答えの根拠になる文の場所はほぼ決まっていました。

1. 「サーバは何を信じて利用者を決めているか」を仕様から探す。JWTのヘッダのalg、パラメータのmid、hiddenフィールドのsessionIDなど、クライアントが送ってくる値をそのまま信じている箇所が脆弱性になる
2. 秘密の値（鍵・トークン）が「どこに置かれ、どこを通るか」を追う。アプリの中、HTTPのヘッダー、メールの本文。置き場所が分かれば、攻撃者の取り方がそのまま答えになる
3. ID・番号の「作り方」の注記を読む。「〇から始まる連番」「年月日＋登録順」と書いてあれば、推測される前提で設問が作られている

JWTやOAuthの深い知識より、仕様の表と注記の一文を拾えるかが点数を分けています。採点講評でも「設問文をよく読んで」「具体的に」という指摘が目立ちます。

この記事で使う過去問3問

令和6年春期 問1（問題PDF）：JWTの「alg」を書き換えてなりすまし

スマホアプリからクラウド上のAPIを呼び出すヘルスケアサービスで、脆弱性診断の結果に対策を考える問題です。

設問1：セッション管理を行わない性質は「ステートレス」

着目する文： 「RESTful APIの設計原則の一つにセッション管理を行わないという性質がある」。

答えはステートレスです。サーバ側でセッションを持たないので、利用者の識別はリクエストに付いてくるJWTだけで行うことになります。この前提が、後の設問すべてにつながっています。

設問2(1)：4桁のコードは平均何秒で破られるか

着目する文： 表2の「毎回ランダムに生成される数字4桁の文字列」と、表3の「1秒間に10回試行する総当たり攻撃」。

4桁の数字は10,000通りです。平均すると半分の5,000回で当たるので、5,000回 ÷ 10回/秒 = 500秒。解答例も500です。表2には「生成してから10分以内」という有効期限も書かれています。500秒は10分（600秒）より短いので、期限内に突破される可能性が高い、という流れです。

対策の表5では、空欄dに連続失敗回数がしきい値を超えたらアカウントをロックする処理が入り、あわせて文字列Xを6桁に変える案が出ています。「試行回数を制限する」「桁数を増やす」の2本立ては、総当たり対策の定番です。

設問2(2)：JWTの何を検証すればいいか

着目する文： 「表4中の”RS256”の代わりに”NONE”を指定し、“user01”を他の利用者IDに改ざんしたJWTを送信したところ、改ざんしたJWTの検証が成功し」。

JWTは「ヘッダ.ペイロード.署名」の3つの部品でできていて、ヘッダのalgに署名のアルゴリズムが書かれています。図4には、ライブラリが「JWT内のヘッダに指定されたアルゴリズムに基づいてJWTを検証する」とあります。つまり、攻撃者がalgをNONE（署名なし）に書き換えると、ライブラリは「署名なし」として検証を通してしまいます。

解答例は、検証対象のデータがJWTヘッダ内のalgに指定された値、検証内容がNONEでないことを検証するです。

採点講評では、この設問の正答率はやや低く、既に実装されている対策を解答するものが散見されたとあります。「署名を検証する」は図4にすでに書かれている処理です。問題文の仕様に書いてある処理のどこに穴があるかを答えます。

設問2(3)：利用者IDの取り違えを防ぐ

着目する文： 表3の項番2「パラメータmidに他の利用者IDを指定すると、他の利用者IDにひも付く利用者情報を取得、改変できてしまう」。

利用者APIは、パラメータmidで指定された利用者の情報を返します。JWTで本人確認をしていても、midに他人のIDを書けば他人の情報が取れてしまう状態です。解答例は、JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理です。

「認証（誰か）」と「認可（その人がこのデータを触ってよいか）」は別物、という典型的な出題です。

設問2(4)：見落とされたパラメータstatus

表3の項番3は、リクエストにstatus=paidを勝手に追加すると、無償利用者が有償利用者になってしまう脆弱性です。表5では、実装が指定されたパラメータを検証せず、全て共通モジュールPに送信していたことが原因とされ、空欄cの答えは共通モジュールPです。仕様にないパラメータを受け付けてしまう問題は、一般にマスアサインメントと呼ばれます。

設問3：Log4Shell型の新しい脆弱性とWAF

後半は、新たに公表された脆弱性への対応です。解答例を見ると、

• 設問3(1)：脆弱性があるかを確かめるために、テストサーバのindex.htmlへのアクセスを記録し、確認する仕組みを置く。図8の検証コードで実行させるコマンドは、デコードすると「wget http://（テストサーバ）/index.html」です。コマンドが実行されれば、テストサーバのindex.htmlにアクセスが来るので、それを記録すれば脆弱性の有無が分かります
• 設問3(3)：WAFのルールに書くパターンは\W[jJ][nN][dD][iI]\W（大文字小文字を混ぜた「jndi」）
• 設問3(4)：WAFを「遮断」ではなく「検知」にする利点は誤検知による遮断を防ぐことができる。代わりにアラートを受信したら攻撃かどうかを精査する

採点講評では、設問3(1)の正答率がやや低く、図6の攻撃の流れに合っていない解答が散見されたとあります。正規表現の書き方は、コード問題の記事でもまとめています。

令和6年秋期 問4（問題PDF）：セッション固定から、APIで大量の個人情報へ

転職支援サイトのセキュリティ診断の問題です。一つ一つは小さな脆弱性を組み合わせて、WebAPIから求職者の個人情報を大量に抜く流れを組み立てます。

設問1：セッションフィクセーションは「ログイン前後で値が同じ」

着目する文： 「form内のhiddenフィールドであるsessionIDの値だけでセッション管理を実施していた。しかし、表Bのいずれの画面遷移においても、HTTPレスポンス中のsessionIDの値が同一であった」。

ログインの前に払い出されたsessionIDが、ログインした後もそのまま使われています。攻撃者は自分で手に入れたsessionIDを被害者に使わせ、被害者がログインするのを待てば、同じsessionIDでログイン済みの状態に入れます。これがセッションフィクセーション（セッション固定）です。

図Aの攻撃手順の空欄は、解答例では次のとおりです。

採点講評では、設問1(2)は正答率が高かったとあります。セッション固定の仕組みと「ログイン時にIDを振り直す」という対策は、得点源にしておきたい論点です。

設問1(5)：HTTPヘッダーで何ができるか

表Dの空欄e・fは、出力されていなかったHTTPヘッダーの効果です。解答例は、

• e：Mサイトへの接続をHTTPSに強制することができる（HSTS、Strict-Transport-Securityの効果）
• f：Mサイトのコンテンツに対して、Content-Typeヘッダーで指定したMIMEタイプを強制的に適用することができる（X-Content-Type-Options: nosniffの効果）

採点講評では、fの正答率が低かったとあります。ヘッダー名を覚えるだけでなく、「設定すると何が起きるか」を一文で言えるようにしておく必要があります。

設問2：脆弱性を組み合わせて、気付かれずに乗っ取る

着目する文： 図3の注1「画面09でメールアドレスを変更した場合…変更前のメールアドレスに、確認用URLが記載されたメール(あ)を送信する」と、2.2.2の「メール(あ)がabc@example.comだけに送信され、本来の宛先である変更前のメールアドレスには送信されなかった」。

普通にメールアドレスを書き換えると、確認メールが本来の担当者に届いて気付かれます。そこで攻撃者は、メールヘッダーインジェクションを使います。解答例のgは、画面09で、会社名に、図Cのabc@example.comを攻撃者のメールアドレスに変更した文字列を入力して変更ボタンをクリックするです。確認メールが攻撃者にだけ届くので、本来の担当者は何も気付きません。

その後、メールアドレスを攻撃者のものに変えてパスワードを再設定し、解答例のhにあるとおり、再設定後のパスワードを入力して、WebAPIキーを確認又は発行することで、WebAPIから大量の求職者属性情報を取れる状態になります。画面05・07でパスワードの再確認が求められるので、パスワードを知っている状態にしておく必要があった、という点がポイントです。

採点講評では、設問2gの正答率が低く、攻撃の後の流れに合っていない解答が散見されたとあります。「メールヘッダーインジェクションで何ができるか」を一般論で書くのではなく、図Dの次の手順（メールアドレスの変更）につながる操作を書く必要があります。

設問3：WebAPIの被害を減らす仕様の改善

着目する文： 図2の注1「求職者がMサイトに利用者登録をした年月日の8桁の数字の後ろに、日ごとに000001から登録順に割り当てられる6桁の数字を加えた数字14桁の文字列」と、「任意の求職者IDを指定して、求職者属性情報を取得する」。

求職者IDは推測できるうえに、APIは任意の求職者IDで情報を返します。利用契約では「当該企業への問合せ・応募に関する対応だけ」と範囲を決めているのに、仕様がそれを守らせていません。解答例の改善案は、

• 求職者IDを推測困難な生成方法に変える（APIkeyが盗まれても、問合せ・応募をした求職者の情報だけに被害を抑えられる）
• WebAPIのアクセス元IPアドレスを限定する
• WebAPIで取れる求職者属性情報を、個人を特定できないものだけにする

などです。採点講評では、被害を軽減できない誤答が散見されたとあります。「なぜ被害が減るのか」を、仕様のどこを変えたからかとセットで書くのがコツです。

令和7年春期 問3（問題PDF）：アプリに埋め込んだ鍵は取られる

写真をアップロードしてフォトグッズを注文するスマホアプリの問題です。JVN（Japan Vulnerability Notes）で公表されているスマホアプリの脆弱性を題材にした、と出題趣旨に書かれています。

設問1(1)(2)：アクセスキーを取る2つの方法

着目する文： 図5の「アクセスキーをHTTPリクエストのAuthorizationヘッダーに指定する方式」と、「アクセスキーは、鍵長256ビットの共通鍵とAES-CBCアルゴリズムで暗号化し、Fアプリ内にリソースとして保存する。…AES-CBCの共通鍵及び初期ベクトルは、Fアプリのコード中に定数として定義する」。

• (1) 通信を盗聴できた場合：Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す
• (2) アプリから取る場合：Fアプリを解析し、暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し、暗号化されたアクセスキーをAES-CBCで復号する

暗号化していても、鍵が同じアプリの中にあるなら守れていません。設問は、問題文に書かれた置き場所をそのままたどれば答えが出る作りです。

設問1(3)：全利用者の写真をダウンロードする方法

着目する文： 図4の注記「“nnnnnnnn”は注文番号であり、00000001から始まる十進数の連番である」。

写真は「注文番号.zip」というファイル名でストレージに置かれます。アクセスキーがあれば全ファイルを操作できるので、解答例はファイル名に含まれる注文番号を00000001から順に増やしてダウンロードを試行するです。

採点講評では、この設問の正答率は低く、抽象的な解答が散見されたとあります。「アクセスキーを使ってダウンロードする」だけでは足りず、連番という注記を使って、どのファイル名を指定するかまで書く必要があります。

設問2(3)：テスト用の通信解析ツールで証明書エラーを出さない設定

脆弱性1は、アプリがサーバ証明書の検証エラーを無視して通信を続けるというものです。これを直すと、開発中に通信解析ツール（中間で通信を見るプロキシ）を使ったテストができなくなります。解答例は、開発用のスマホに通信解析ツールのプライベート認証局のルート証明書をインストールし、信頼設定を行うです。

採点講評では正答率が低く、同様の方法はネットワーク機器のTLSインスペクション機能などでも利用されるので理解してほしい、と書かれています。「検証を無効にする」のではなく、検証が通るように信頼する認証局を足すという発想です。

設問3：署名付きURLは「どこで」作るか

着目する文： 図5の方式bの説明「(ii) アクセスキーを秘密鍵とする」と、図4の(あ)〜(お)。

署名付きURLは、アクセスキーを秘密鍵にしてHMAC-SHA256で署名を作ります。つまり、作る場所にアクセスキーが必要です。アプリの中で作ると、また鍵をアプリに置くことになります。

解答例は(い)、つまりA社Webサーバが注文番号を採番した後、アプリに注文番号を通知する前です。サーバで「この注文のファイルだけ」の署名付きURLを作ってアプリに渡せば、アプリはアクセスキーを持たずに済みます。

採点講評では、攻撃者による解析が容易なスマホアプリ上という解答が散見されたとあり、秘密情報の処理をサーバ上で完結させるのが基本だと書かれています。

設問1(4)・設問4：WebViewは「何でも開く」

着目する文： 図8のF-URLの例f-app://campaign?url=https://www.a-sha.co.jp/campaign/□□□と、図7「呼出し元のWebページのURLの先頭は”https://www.a-sha.co.jp”か」。

F-URLのurlクエリパラメータに書いたURLを、アプリはそのままWebViewで開きます。開く前のチェックは仕様のどこにもありません。そのため設問1(4)の解答例には、攻撃者のドメインをk-sha.co.jpとして、次のURLが並んでいます。

• https://k-sha.co.jp/（そのまま攻撃者のサイト）
• https://www.a-sha.co.jp.k-sha.co.jp/（先頭が一致するようにサブドメインとして付け足す）
• https://www.a-sha.co.jp@k-sha.co.jp/（@より前はユーザー情報として扱われる）

下の2つは、図7のgetToken関数のチェックが末尾の/を含まない先頭一致であることも突いています。攻撃者のサイトで認証トークンまで受け取れてしまう形です。

設問4(1)の問題点は、解答例ではURLを確認する手段がないです。WebViewはアプリの画面の一部にページを表示するだけなので、ブラウザのようにURLを見て偽サイトに気付くことができません。設問4(2)の対策は、WebViewを呼び出す前に、URLの先頭がhttps://www.a-sha.co.jp/であるかを検証するです。末尾の/まで含めて比べることと、トークンを渡すときではなくページを開く前に検証するのがポイントです。

3問に共通する「問題文のここを見る」チェックリスト

CBT方式の科目Bでは、問題文にマーカーを引けます。注記（注1・注記）はとくに読み飛ばしやすいので、IDや番号の作り方が書かれていたら必ず色を付けておくと、設問を解くときに探しやすくなります。

最低限おさえる知識はこれだけ

認証・API・アプリの問題で、問題文に説明がないまま前提にされていた知識は、次のくらいでした。

Web系の基本（XSS・CSRF・CSP）は、シリーズ1本目のWeb問題の記事にまとめています。

過去問の解説動画を見るなら

過去問の解説動画には、Udemyの講座を使っています。科目Bの過去問解説（令和7年秋・令和7年春・令和6年秋）が入っていて、この記事で扱った令和7年春 問3と令和6年秋 問4を動画で見直せます。

令和8年度対応｜参考書の著者が教える 情報処理安全確保支援士 科目A・科目B対策（Udemy） 講座の内容を見る

まとめ

• 認証・API・アプリの問題は、「サーバが何を信じて利用者を決めているか」を仕様から探すと、脆弱性の場所が分かる
• JWTはヘッダのalgをクライアントに選ばせない。利用者APIはJWTの利用者IDとパラメータが一致するかを確認する
• セッションフィクセーションの対策はログイン時にセッションIDを振り直すこと
• アプリに置いた鍵は、暗号化していても同じアプリに復号の鍵があれば取られる。秘密の処理はサーバで行う
• 注記に書かれたIDや番号の作り方は、ほぼ確実に設問で使われる

この分野は、知識の量より問題文の仕様を一文ずつ疑えるかで差がつきます。解き直すときは、答えを覚えるのではなく、根拠になった文がどこにあったかを確認すると、初めて見る問題でも同じ場所を探せるようになります。

シリーズ3本目では、ネットワーク・リモートワークの問題（VPN・DDoS・無線LAN）を解説しています。

この分野の攻撃と基本の対策の組み合わせは、聞き流し用の一問一答動画（攻撃と対策・42問・YouTube）でも耳で復習できます。

関連記事

• 情報処理安全確保支援士 科目B（午後）の出題傾向を分析｜出やすい分野ランキングと過去問リンク集
• 支援士 科目B（午後）のWeb問題の解き方｜XSS・CSP・CSRF
• 支援士 科目B（午後）のコード問題を全部解説｜「書く」はJava・SQL・正規表現の定番だけ
• 情報処理安全確保支援士（登録セキスペ）に挑戦します【学習計画・教材】
• 支援士 科目B（午後）のインシデント対応・ログ解析問題の解き方｜ログは「時系列に並べて、2つのログで裏付ける」【過去問2問で解説】

参考にした情報

• IPA 過去問題（令和6年度春期 午後 問1、令和6年度秋期 午後 問4、令和7年度春期 午後 問3の問題・解答例・採点講評）
• JVN（Japan Vulnerability Notes）

この記事で引用した問題文・解答例は、IPAが公開している過去問題からの抜粋です。一部を省略・要約し、表の形に整理しています。

よくある質問（FAQ）

Q1. 支援士の科目Bで、JWTやAPIの問題は出ますか？

出ています。令和6年春期 問1はAPIセキュリティが主題で、JWTのヘッダのalgをNONEに書き換えて他の利用者になりすます脆弱性と、パラメータで指定した利用者IDとJWTの利用者IDが一致するかを確認していない脆弱性が問われました。令和6年秋期 問4でも、求人企業向けのWebAPIとAPIkeyが題材になっています。

Q2. JWTの改ざん対策は、何を答えればいいですか？

令和6年春期 問1の解答例は「JWTヘッダ内のalgに指定された値」が「NONEでないこと」を検証する、です。採点講評では、既に実装されている対策（署名の検証など）を答える誤答が散見されたとあります。問題文の仕様のどこに穴があるかを答えるのがポイントです。

Q3. セッションフィクセーションの対策は何ですか？

ログイン時に、使用済みのセッションIDを無効にした上で、新しいセッションIDを発行することです。令和6年秋期 問4の解答例もこの内容で、採点講評ではこの設問の正答率は高かったとあります。

Q4. スマホアプリの問題では、何に注意して読めばいいですか？

鍵やトークンが「どこに置かれ、どこを通るか」を追います。令和7年春期 問3では、アプリ内に暗号化して保存したアクセスキーも、復号用の共通鍵が同じアプリの中にあるため取得できる、という設定でした。署名付きURLをどこで生成するかの設問では、スマホアプリ上と答える誤答が散見され、秘密情報の処理はサーバ上で完結させるのが基本だと採点講評に書かれています。