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

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

⇄問題文と設問を画面2分割で開く⇱問題PDF

出題趣旨

アジャイル開発を行っている企業が増えている中，短期間でリリースすることを優先した結果，システムの脆弱性対応が後回しになっているケースも見られる。本問では，Webサイトのセキュリティを題材として，Webサイトにおける脆弱性対策の理解力，開発プロセスの変化に応じたセキュリティへの対応方法を検討する能力を問う。

設問1

    • ア
    • ・ダウンロードするライブラリに既知の脆弱性がないかを確認する。
      ・特定のWebサイトからの入手をルール化し，明文化する。
  • XSSを引き起こす診断コードについて問われています。
    図1のコードを見ると、metaタグのcontent属性として出力する内容として、URLのホスト名（serverName）、パス（scriptName）、クエリ文字列（queryString）が使用されています。クエリ文字列（URLの?以降の文字）を元にURLを組み立てていることから、パラメータをURLに付けて送るGETメソッドが対象になることがわかります。したがって、POSTメソッドの「ウ」「エ」は回答候補から除外できます。

    「ア」と「イ」の違いは、?の直後の"があるかないかだけです。実際に図1のコード内のqueryStringにそれぞれを当てはめてみると、次のようになります。
    //ア
    <meta property="og:url" content="https://www.b-sha.co.jp/confirm?"><img src=1 onerror=alert(1)><"">
    「ア」は1文字目の"によりmetaタグが閉じられ、img要素が挿入されます。HTMLの属性は'や"で囲まなくても動作するため、src=1 onerror=alert(1)は、src属性に1、onerror属性にalert(1)が設定されていると解釈されます。img要素のsrc属性（画像ファイルのパス）が1だと常にエラーを起こすため、onerror属性に指定したスクリプトが実行されるという仕組みです。
    //イ
    <meta property="og:url" content="https://www.b-sha.co.jp/confirm?><img src=1 onerror=alert(1)><"">
    「イ」はクエリ文字列がcontent属性の一部として解釈されるため、スクリプトが実行されることはありません。"が1つ余分となるため構文エラーとなります。

    したがって診断用リクエストとして適切なのは「ア」です。

  • 外部ライブラリの管理方法に関する再発防止策を問う問題です。
    本文中に「使用するライブラリは，マルウェアが含まれていない，既知の脆弱性が修正された，安全性が確認できているライブラリを公開しているWebサイトから…」と記載されています。しかし、実際にはXSS脆弱性を含むライブラリMが使用されており、この運用方法に問題があることがわかります。

    このような脆弱なライブラリの使用を防ぐには、単にWebサイトの信頼性を頼りにするのではなく、自社でライブラリのセキュリティチェックを行うことが重要ですす。具体的には、JVN（Japan Vulnerability Notes）などの脆弱性情報データベースを活用し、導入前にライブラリに既知の脆弱性がないかを確認することなどがあります。また、現在の運用では「開発部のメンバそれぞれが収集」とあり、個々の判断に依存したライブラリ管理に伴うリスクが顕在化したと言えます。開発者が個別に判断するのではなく、企業としての明確なルールを策定し、企業が指定したWebサイトや公式のリポジトリからのみライブラリを入手するように統一することが望まれます。

    ∴・ダウンロードするライブラリに既知の脆弱性がないかを確認する
    　・特定のWebサイトからの入手をルール化し，明文化する

設問2

    • a: 利用者ID
    • b: セッションオブジェクト
  • ※aとbは順不同
図2では、サイトXのキャンペーン応募ページにおいて、CSRF対策の一環としてcsrftokenというパラメータが用意されていることが確認できます。リクエスト内のcsrftokenを削除または変更した場合にエラーとなることから、 csrftokenを用いた改ざん防止策は一定程度機能していることがわかります。

しかし、別の利用者Bのcsrftokenに、図2中の利用者Aのcsrftokenの値を設定して送信したところ、利用者Bとして処理されたとあることから、csrftokenが利用者情報と適切に紐づいていないことが明らかです。本来、CSRFトークンは利用者ごとに発行され、その利用者のセッション情報と紐づけされるべきものです。

HTTPのセッション情報はサーバ側で管理される情報であり、一般的にはセッションオブジェクトと呼ばれます。サーバ側ではセッションオブジェクトにユーザーID等の情報を入れておくことで、どの利用者のセッション情報が識別できるようになっています。このセッションオブジェクトにCSRFトークンの値を格納しておくことで、利用者とCSRFトークンを紐づけます。

したがって、空欄a、bには「利用者ID」「セッションオブジェクト」が当てはまります。

∴ab＝利用者ID、セッションオブジェクト（順不同）

設問3

    • c: イ
    • d: ア
    • e: ア
    • f: ア
    • g: イ
    • h: イ
    • i: エ
    • j: イ
  • クリックジャッキングは、ユーザーを騙して意図しない操作をさせる攻撃手法の一つです。この攻撃では、悪意のあるページをユーザーの目に見えない形で配置し、ユーザーが本来意図していないボタンをクリックさせることで、不正な操作を誘導します。

    図3では、画面αがサイトX本来の画面（利用者情報の公開範囲を設定するページ）、画面βが攻撃者が用意した罠サイト上のページとなります。実際にクリックイベントを発生させたいのは画面αなのでこちらが手前、画面βは奥に配置されます。また、利用者に見せたいのは画面βなのでこちらが可視状態、画面αは透明状態で表示します（画面αはHTMLのifreme要素などを用いて取得されます）。これにより、ユーザーは目に見えているのは罠サイト、実際にクリックイベントが発生するのは正規のサイトという状態になります。この状態ではユーザーは画面βのボタンをクリックしているつもりでも、実際には手前の画面αのボタンを押してしまうことになります。
    pm21_1.png/image-size:184×210
    本文中の空欄に適切な語句を当てはめると、次のようになります。

    攻撃者は、画面「β」を利用者から見て「奥」に「可視の」状態で罠サイトを公開し、サイトXの画面「α」を利用者から見て「手前」に「透明」状態で重ねて表示する。

    ∴c＝イ：β、d＝ア：奥、e＝ア：可視の
    　f＝ア：α、g＝イ：手前、h＝イ：透明

    【補足】
    本文中で扱っているのは「正規のページを透明にし、悪意のあるページを可視化するパターン」ですが、クリックジャッキングにはもう一つ、「正規のページを可視化して奥に配置し、その手前に透明な悪意のあるページを重ねるパターン」もあります。この場合、ユーザーは正規のボタンを押したつもりが、実は悪意のあるページのボタンを押してしまうことになります。問題を解く際には、どのパターンに該当するかを見極めることが重要です。

  • 選択肢のレスポンスヘッダーはそれぞれ次のようなものです。
    Content-Disposition
    クライアントがコンテンツをどのように処理するかを指示するために使用される。コンテンツをWebページ内で表示するのか、ダウンロードするのかをwebブラウザに指示することが可能
    Content-Security-Policy（CSP）
    Webページにおけるスクリプトの実行やリソースの読込みを制御するために使用される。リソースの種類ごとに詳細な制御が行うことができ、W3Cで標準化されている。frame-ancestorsの設定により、他サイトでのframe/iframe要素による読込みを制御できる
    X-Content-Type-Options
    クライアントがContent-Typeヘッダーに従ってコンテンツを解釈するように強制するための設定。Content-Typeヘッダーは、サーバが送るデータの種類（例: text/html や application/json など）を指定するものである。この設定により、クライアントがコンテンツの種類を勝手に推測（MIMEスニッフィング）して処理するのを防ぎ、悪意のある攻撃を防止できる
    X-Frame-Options
    他ドメインのサイトからのframe/iframe要素による読み込みを制限する。iframeとしての埋め込みを完全に禁止する「DENY」、同一オリジン（ドメイン）内からの埋め込みのみ許可する「SAMEORIGIN」、特定のURLからの埋め込みのみ許可する「ALLOW-FROM origin」を設定可能
    クリックジャッキングは、罠サイトがiframe要素で正規のサイトを表示できることを悪用するため、これを防ぐためには、他のサイトにiframe要素を介して自サイトを表示させないことが根本的な対策となります。これを実現するための有効なHTTPヘッダーが「X-Frame-Options」と「Content-Security-Policy（CSP）」です。空欄jは「標準化されている」とあるので「Content-Security-Policy」、空欄iが「X-Frame-Options」となります。

    ∴i＝エ：X-Frame-Options
    　j＝イ：Content-Security-Policy

設問4

    • topicの値をhttps://db-y.b-sha.co.jp/に変更した。
設問では、サイトYのSSRF脆弱性を利用して、どのように不正アクセスが可能となったかを問われています。

SSRFは、攻撃者がWebアプリケーションを悪用し、本来アクセスできない内部ネットワークや他のサーバへ不正なリクエストを送信させる攻撃手法です。通常、内部ネットワークのサーバは外部から直接アクセスできないように保護されています。しかし、Webアプリケーションが内部のサーバにリクエストを送信する機能を持つ場合、攻撃者がリクエストのURLを改変することで、Webアプリケーションを踏み台にして内部サーバへアクセスできてしまうことがあります。

表2によると、サイトYは個人向けのブログサイトであり、「A社のニューストピックを表示する」機能を持っています。また、図4のリクエスト（GET /news?topic=……）を見ると、topicパラメータの値に指定されたURLから情報を取得し、それを表示する仕組みになっていることがわかります。この仕組みが悪用されると、攻撃者がtopicの値を任意のURLに変更し、サイトYのWebサーバ経由で内部サーバ内のファイルにリクエストを送信させることが可能になります。

本文中ではD社の診断によって「topicの値を変更することでサイトYのDBサーバにアクセスできることが確認された」とあります。ここで、表2の注釈を確認すると、サイトYのDBサーバのメンテナンス用WebインターフェースのURLは「https://db-y.b-sha.co.jp/」であることがわかります。つまり、図4のリクエストのtopicの値を「https://db-y.b-sha.co.jp/」に変更することで、サイトYのWebサーバ経由でDBサーバの管理画面へアクセスできたということになります。通常であれば、DBサーバのメンテナンス用Webインタフェースは外部から直接アクセスできないように制限されているはずですが、サイトY内部のWebサーバからのリクエストだったため、この制限が回避されてしまったことになります。

設問では「どの値をどのように変更したか」が問われているため、正解は「topicの値をhttps://db-y.b-sha.co.jp/ に変更した」となります。

∴topicの値をhttps://db-y.b-sha.co.jpに変更した

設問5

    • k: V氏が用意したサイト
    • returnURLの値を固定値にする。
  • サイトZでは、P社宿泊サイトと連携し、駅名を入力するとその駅周辺の宿泊施設情報を取得する機能を提供しています。SSRF脆弱性は図6の登録されていない駅名を検索したときの処理で確認されたので、まず図6の処理の流れを整理しておきます。
    1. 利用者が「abc」を入力し、サイトZにリクエストを送信
    2. サイトZがP社宿泊サイトにリクエストを送る（returnURLにサイトZ自身のエラーページを指定）
    3. P社宿泊サイトはreturnURLに設定されたエラーページにリクエストを送るようリダイレクトを指示する
    4. サイトZはエラーページを取得する
    5. サイトZが利用者にエラーページを表示
    図5の注釈を確認すると、「returnURLには，登録されていない駅名が入力されたときに利用されるURLを指定する。サイトZは，(1)のHostヘッダの値を，returnURL中のホスト名として指定する」とあります。つまり、手順2のリクエスト中のreturnURLは「Hostヘッダーの値＋error」と形で組み立てられていることがわかります。

    Hostヘッダーは、HTTPリクエスト時にどのホスト（ドメイン名）に対するリクエストであるかを指定するヘッダーです。通常は1つのサーバが複数のドメインをホスティングする場合、適切なドメインを識別するために使用されます。Hostヘッダーは、HTTPリクエストヘッダーなので、利用者が任意の値を設定することができるため、サイトZのようにHostヘッダーの値を利用してリクエストやレスポンスを組み立てている場合、攻撃者の用意した罠サイトに誘導されてしまうことがあります。この攻撃は「Hostヘッダーインジェクション」と呼ばれます。

    表4手順1には「Hostヘッダの値をV氏が用意したサイトのFQDNに変更」と記述されているので、サイトZはHostヘッダーの値をもとにReturnURLの値を「V氏が用意したサイトのFQDN＋error」してP社宿泊サイトにリクエストを送信します。エラー時にはP社宿泊サイトから「V氏が用意したサイトのFQDN＋error」へのリダイレクトが指示されるため、サイトZ（のWebクライアント）はV氏が用意したサイトにアクセスしてしまうことになります。したがって、空欄kには「V氏が用意したサイト」が当てはまります。

    ∴k＝V氏が用意したサイト

    【補足】
    手順2の駅近辺の"お得情報"を取得するリクエストには、サーバに認証情報を伝えるAuthorizationヘッダーが含まれています。リクエスト先から「301 MOVED PERMANENTLY（リダイレクト指示）」を受け取った場合、WebクライアントはレスポンスのLocationヘッダーに指定されたURLにリクエストを転送します。このリクエストの転送によって、Authorizationヘッダーの値が攻撃者の用意したサイトに送られ、不正取得されてしまいます。

  • 本件のSSRF脆弱性の原因は、Hostヘッダーの値をそのまま利用してreturnURLを組み立てるというサイトZの仕様です。V氏はこの仕様を利用し、Hostヘッダーの値を自身が用意したサイトのFQDNに変更し、サイトZに不正なリクエストを送信させることで、P社宿泊サイトにアクセスする際の認証情報（Authorizationヘッダーの値）を窃取することができました。

    そもそもサイトZのエラーページのURLは「https://z.b-sha.co.jp/error」で固定されていますから、Hostヘッダーの値を使う必要性はありません。したがって「returnURLの値を固定値にする」対策が有効となります。これにより、Hostヘッダーが改ざんされても不正なリクエストの送信を防ぐことができます。

    ∴returnURLの値を固定値にする

設問6

    • ①②: ・一部のセッション管理の脆弱性
      ・認可／アクセス制御の脆弱性
    • 改良フェーズにおける1か月の休止期間
    • ・専門技術者による脆弱性診断が必要なときは，改良リリースを次回に持ち越す。
      ・半年に一度，改良リリースの期間を長くする。
      ・定期的に，期間の長い改良リリースを設ける。
    • CSRF対策用トークンの発行，HTMLへの埋め込み，必要なひも付け，及びこれを検証する処理
  • 表1のWebセキュリティ管理基準を確認すると、脆弱性診断には以下の2つの種類があります。
    ツールによる診断・レビュー（項番2、3、4）
    セッション管理の脆弱性は「一部だけ」対象
    認可・アクセス制御の脆弱性は対象外
    専門技術者による診断（項番5）
    セッション管理の脆弱性が「すべて」対象
    認可・アクセス制御の脆弱性も対象
    この違いから、専門技術者による脆弱性診断でのみ発見できる脆弱性は、「一部のセッション管理の脆弱性」および「認可・アクセス制御の脆弱性」とわかります。「セッション管理の脆弱性」とだけ答えてしまうと不完全な回答になってしまうため、必ず「一部の」を付ける必要があります。

    ∴①一部のセッション管理の脆弱性
    　②認可・アクセス制御の脆弱性

  • A社のWebセキュリティ管理基準（表1）では、専門技術者による脆弱性診断（項番5）の実施期間は10日間程度とされています。しかし、B社ではアジャイル開発を採用しており、改良リリースの周期が約2週間であるため、改良リリースごとに脆弱性診断を実施することは非現実的です。

    図7の開発プロセスを確認すると、半年に1回、1か月の休止期間が設けられています。この期間は、開発部のメンバーが長期休暇の取得、研修の受講、Webサイトの点検などを行う時期とされており、通常の開発業務が一時的に停止されるため、脆弱性診断を実施するのに最適な時期であると考えられます。したがって、改良リリースに影響を与えずに脆弱性診断を行える適切な時期は「改良フェーズにおける1か月の休止期間」となります。

    ∴改良フェーズにおける1か月の休止期間

  • アジャイル開発を継続しながら、専門技術者による脆弱性診断が長期間行われない事態を避けるためには、診断を計画的に組み込む必要があります。図7の注記1によると、B社では2週間ごとに改良リリースを行っていますが、大規模な改修がある場合には1カ月のリリース間隔を設けることもあるため、リリース期間は一定の調整が可能であると考えられます。

    B社の開発プロセスでは2週間ごとに改良リリースを行う一方で、大規模な改修の際にはリリース間隔を1カ月に延長する柔軟性があります（図7の注記1）。この特性を活かし「半年に一度、改良リリースの期間を延長し、その間に脆弱性診断を行う」ことで、診断が長期間実施されない事態を防ぐことができます。

    また「改良リリースのスケジュールを調整し、診断が必要な場合は次回のリリースに持ち越す」方法も考えられます。これにより、開発の進行を妨げずに診断の機会を確保できます。
    さらに「定期的に、期間の長い改良リリースを計画的に設ける」ことで、セキュリティ診断を継続的に行う仕組みを作ることも有効です。これによりアジャイル開発のスピードを維持しながら、脆弱性の早期発見と対策が可能になります。

    ∴専門技術者による脆弱性診断が必要なときは，改良リリースを次回に持ち越す
    　半年に一度，改良リリースの期間を長くする
    　定期的に，期間の長い改良リリースを設ける

  • 今回の診断で発見されたサイトXのCSRF脆弱性の原因は、CSRFトークンと利用者ID、またはセッションオブジェクトが適切に紐づいていなかったことにあります。CSRF対策の根本対策は、処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報（CSRFトークン）が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行することです。これを実現するには次の一連の機能が必要となります。
    CSRFトークンの発行
    リクエストごと、またはセッションごとに一意のトークンを生成する
    HTMLへのトークン埋込み
    フォーム送信時にCSRFトークンを隠しフィールド（hiddenパラメータ）として埋め込む
    トークンとセッション情報の紐づけ
    トークンが利用者のセッション情報と適切に関連付けられるよう管理する
    リクエスト時のトークン検証
    送信されたトークンとサーバ側のトークンを比較し、一致しない場合はリクエストを拒否する
    これらの機能を適切に実装することでCSRF攻撃を防ぐことができます。近年のWebフレームワークには、CSRF対策が標準で組み込まれているものが多くあります。これらのフレームワークを活用することは検討に値します。

    ∴CSRFトークンの発行，HTMLへの埋め込み，必要なひも付け，及びこれを検証する処理
© 2014-　情報処理安全確保支援士ドットコム　All Rights Reserved.
▲
Pagetop