【情報処理安全確保支援士試験 令和6年度 春期 午後 問3 No.3】

情報処理安全確保支援士試験 令和6年度 春期 午後 問3

【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問3（一部、加工あり）】

[認可制御の不備について]
 Z社が認可制御の不備を検出した経緯は、次のとおりであった。
⑴Z社は、利用者α、利用者βという二つの利用者アカウントを用いて注文履歴を閲覧した際のリクエストを確認した。注文履歴を閲覧した際のリウエストを図5及び図6に示す。

⑵図5のリクエストのパラメータorder-codeの値を図6中の値に改変してリクエストを送った。
⑶利用者αが本来は閲覧できないはずの利用者βの注文履歴を閲覧できるという攻撃が成功することを確認した。
⑷さらに、ある利用者がほかの利用者が注文した際のorder-codeを知らなくても、④ある攻撃手法を用いれば攻撃が成功することを確認した。

 Z社は、⑤サイトXのWebアプリに追加すべき処理を説明した。

下線④について、どのような攻撃手法を用いれば攻撃が成功するか。30字以内で答えよ。：order-codeの下6桁を総当たりで試行する。

「さらに、ある利用者がほかの利用者が注文した際のorder-codeを知らなくても、④ある攻撃手法を用いれば攻撃が成功することを確認した。」

 Z社による認可制御の不備を検出した経緯から以下が分かります。

• 利用者の注文履歴閲覧時のリクエストには、order-codeというパラメータが含まれている。
• order-codeには、「注文管理番号（例：202404-AHUJKI）」が入っており、これが識別子となっている。
• Z社は、order-code の値を他人のものに変えて送信したところ、認可制御が不十分なため、他人の注文履歴が閲覧できてしまうことを確認した。

 そして、ここでの問題点は以下のとおりです。

• アクセス制御が「ログインしていること」のみで、注文番号の正当性（所有者確認）を行っていない。
• 注文番号のパターンから「年月＋6桁の英数字」と推測できるため、下6桁の部分が狙い目になる。

 したがって、攻撃手法としては、order-codeの下6桁の文字列（例：AHUJKI）の部分を、総当たり（ブルートフォース）で変えて試行し、サーバの応答から存在するかどうかを判別して、他人の注文履歴を取得することが想定できます。

 このような認可制御の欠落は、情報漏洩や個人情報の不正取得に直結する重大な脆弱性であり、対策としては、次のような処理が必要です。

• アクセスログの監視とレート制限を導入する。
• 利用者ごとに注文履歴へのアクセス権をサーバ側で厳密にチェックする。
• 予測困難なランダムな識別子を使用する。

ブルートフォース攻撃とは

• ブルートフォース攻撃（Brute-force attack、総当たり攻撃）は、パスワードや暗号キーなどを解読するために、考えられるすべての組み合わせを機械的に一つずつ試していく攻撃手法です。「力任せ」「強引な」という意味から名付けられており、シンプルながらも確実性の高いサイバー攻撃の一つです。
• 具体的な手口
  • 攻撃者は、パスワードや暗号キーの全パターンを自動的に入力し、正解が見つかるまで繰り返します。
  • 例えば、4桁の数字パスワードなら「0000」から「9999」まで10,000通りを順に試します。
  • 一般的には専用のプログラムやツールを使い、膨大な組み合わせを高速に試行します。
• 種類
  • 総当たり型（インクリメンタル）攻撃
    IDやパスワードを一方を固定し、もう一方を全パターン試す手法。
  • リバースブルートフォース攻撃
    よく使われるパスワードを固定し、様々なIDで試す手法。
  • パスワードリスト型攻撃（辞書攻撃）
    既知のパスワードリストを用いて効率よく試す手法。ブルートフォース攻撃と組み合わせて使われることも多い。
• 特徴と脅威
  • 原始的な手法ですが、理論的には時間さえかければ必ず突破できるという確実性があります。
  • 近年はコンピューターの性能向上により、より短時間で多くの組み合わせを試せるようになり、脅威が増しています。
  • 成功すると正規のアカウントで不正ログインされるため、発覚しにくいのも特徴です。
• 代表的な対策
  • パスワードの桁数や複雑さを増やす
  • アカウントロックやCAPTCHAによる試行回数制限
  • 多要素認証の導入
  • 不正アクセスの監視とアラート設定

下線⑤について、サイトXのWebアプリに追加すべき処理を、60字以内で具体的に答えよ。：cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違っていれば、エラーにする。

「Z社は、⑤サイトXのWebアプリに追加すべき処理を説明した。」

1. 問題の背景

• 利用者が注文履歴を参照する際、リクエストに含まれる「order-code」によって参照する注文が指定されます。
• しかし、認可制御が不十分なため、他人の「order-code」を指定してもその注文情報が取得できてしまう状況が確認されています（図5・図6参照）。

2. 必要な対策

 Webアプリには、次のような認可処理（アクセス制御）を追加する必要があります。

• クッキーに含まれるセッションID（SESSIONID）などを用いて、現在のログイン利用者アカウントを特定する。
• 指定された「order-code」に紐づく注文情報の所有者が、現在のログイン利用者であるかを照合する。
• 一致しない場合は、不正アクセスとしてエラーを返す。

3. 解答の要点

 解答は上記の処理内容を簡潔にまとめたもので、次のポイントを押さえています。

• 「cookieの値で利用者アカウントを特定」：セッションIDからログイン中の利用者を特定。
• 「order-codeの値から特定したものと違っていればエラー」：注文番号と利用者の対応を確認し、不正なアクセスを遮断。

---

 このような処理の追加により、他人の注文情報を不正に閲覧する攻撃を防止することが可能になります。これは認可（Authorization）機能の基本です。