見出し画像

【登録セキスペ】令和6年春午後問3の解説（情報処理安全確保支援士試験）

せんない

このNoteでは「セキスペR6春午後問3」の解説をします。

最新問題なので、試験1ヶ月前後からの演習をお薦めします。それまでは旧セキスペの午後1問題を解き倒してください。

＞SCR05春PMI問2解説Note
＞SCR05春PMI問3解説Note
＞SCR04秋PMI問2解説Note
＞SCR04秋PMI問3解説Note
＞SCR04春PMI問2解説Note
＞SCR04春PMI問3解説Note


今回は「Cookieによるログイン省略」と「サーバクエリ」の2つがテーマでした。

本試験での得点は極めてキビシイ印象です。とはいえ、具体的手法を学ぶ良い機会だったので、過去問の学習コスパはかなり高いです。

知らないとかなり浮足立つ問題だったので、しっかり復習をして、本試験でCookieやWebクエリが出た時に落ち着いて取り組めるようになっておきたいですね。


このNoteは、私が独学97点合格した経験と、IT専門学校での授業のノウハウで書いています。合格のお手伝いに少しでもなったら嬉しいです。

それでは始めましょう！


設問1(1) | 問題文に忠実に芋づる


正答は、9（問い合わせ管理機能）。


問われている図3のスクリプトは、図3の題名の通り「問い合わせ機能のリクエストとレスポンス」です。

よって表1-9「問い合わせ管理機能」になります。



設問1(2) | cookieによる認証省略の悪用


模範解答は、「攻撃者が罠リンクを用意し、管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のWebサイトに送信させ、その値を読み取って利用することで管理者としてサイトXにアクセスし、利用者情報を取得する」。


XSS（クロスサイトスクリプティング）は、Webサイトに悪意のあるスクリプトを埋め込んでおいて、訪問者のWebブラウザで実行させる手口。偽サイトに誘導させるのが代表的な出口。

このあたりは午前対策でずっとやってきたので理解しています。＞5種類のWeb入力系攻撃解説Note

しかし「どうやって全会員の利用者情報を取得するんだろう」と疑問ですね。SQLインジェクションだったら、まだ分かるのですが。


今回理解すべきは3点。

  • Cookieによって認証済みである証明をする

  • 上の仕組みは、利用者だけでなく、管理者も対象である

  • 偽サイトは他サイト（サイトX）向けのcookie送付を要求できる

問題文にヒントがあります。

23頁の表1の上「ログインセッション管理は、cookieパラメータのSESSIONIDで行う」。

利用者（や管理者）がログイン認証に成功すると、サイトXのサーバはcookieを発行して渡します。cookieにはSESSIONIDが格納されています。利用者は次回アクセスするときにcookieをサーバに見せれば認証手続きをカットできます。これはcookieの有効期限内まで可能です。


攻撃の経緯を紐解きますね。

  1. 問合せフォームに偽サイトに誘導するスクリプトを入力する

  2. 管理者が問合せ管理機能で閲覧した時にスクリプトが実行。管理者が偽サイトに誘導される

  3. 偽サイトはアクセスしてきた管理者にサイトXのcookie送付を要求。管理者PC（Webブラウザ）はcookieを送付

  4. 攻撃者は送付されたcookieを使ってサイトXにアクセス。

  5. サイトXはcookieが有効期限内ならログイン済みとしてそのままシステムを使わせる。

  6. 攻撃者は管理者としてサイトXにログインできたので、サイト管理機能の会員管理機能で全会員の情報を窃取

以上のように、ログイン済み管理者のcookieを入手すれば、攻撃者はIDやパスワードを知らなくてもログイン済みとしてアクセスできるんですね。



設問2(1) | 攻撃者だって正規手順で入手する


模範解答は、「攻撃者が自らのアカウントで取得したcsrf_tokenと
一緒に利用者情報をサイトXに送るように構成した罠フォームに、詐欺メールなどで利用者を誘導して、利用者情報を変更させる」。


これは初見では無理です。模範解答を見て、問題文を見て、やっとこそ「こうかな」と推測するのが精一杯。



CSRF（クロスサイトリクエストフォージェリ）は、意図しない操作をさせる攻撃でしたね。＞5種類のWeb入力系攻撃解説Note

図4は、「会員機能（編集）」でsei（姓）・mei（名）・mail（メールアドレス）を変更するリクエスト。

表2-1, 2ではcsrf_tokenがないとリクエストが通らないこと、3では他の利用者アカウントで取得したcsrf_tokenで通ってしまうことが書かれています。

ここで図4より、会員情報を変更するIDの特定は、SESSIONIDで行う点。SESSIONIDが一定時間ログインを保証していますから。そして、SESSIONIDは今までの問題から、偽サイトでログイン済みCookieを摂取すれば良いです。

まとめます。ある利用者の会員情報を改変するリクエストを送ります。

  • 変更される会員：SESSIONID：話の流れから窃取は偽サイトでログイン済みCookieを摂取

  • sei, mei, mailなど：攻撃者が作るリクエストパケット

  • csrf_token：他の利用者が取得したものでOK（SESSIONIDの利用者でなくて良い）

  • csrf_tokenの入手方法は、問題文に記述なし→自分で正規ログインして入手する

以上より作文をします。

「攻撃者は予め正規のログインをして会員機能（編集）からcsrf_tokenを入手する。攻撃者が用意した偽サイトに利用者を誘導し、ログイン済みCookieを送付させる。攻撃者はログイン済みCookieにあったSESSIONIDと自身が入手したcsrf_tokenを含めた会員機能（編集）のリクエストを作成し、当該利用者の姓名メールアドレスなどの会員情報を変更する」



設問2(2)abcd | 知らなくても英語で半分取れる


正答は、

  • a：×

  • b：×

  • c：○

  • d：×


CookieのSameSite属性の仕様なので、知らなければ仕方ありません。SameSiteは、別のドメインのサイトに遷移した際に、クッキーを送らない設定です。


ただし知らなくても英語から少し推測できます。

Strictって「厳しい」「厳密な」という意味。私は、HSTS（HTTP Strict Transport Security）で覚えていました。＞HSTS解説Note

Laxは「緩い」って意味らしいです。なんとなく「リラックスかな？」と思いはしましたが、どちらが×かは勘で外しました。

「外部WebサイトからサイトXに遷移」した時に、セキュリティ的にStrict（厳しい）設定なら、GETやPOSTは使えそうにないなぁと。

Laxは「きっと片方×」なんだろうと。私はGETはURLで見えるのでGETを×にして、外しました。仕様なので仕方ありません。自分なりに「理屈ある勘」で外したので後悔はありません。

それでも4個のうち2個は得点できたので良いですね。


さて、cookieの属性は午前問題にも午後問題にも出ています。

以下の5個は必ず知ってお下さい。あとは過去問演習の度に増やしていきましょう。

  • expires：Cookieの有効期限

  • domain：Cookieが有効となるドメイン名

  • path：Cookieが有効となる領域（パス）

  • secure：HTTPSの時のみCookieを送付する

  • HttpOnly：Cookieの適用範囲をHTTP, HTTPSの時のみにする

＞Cookieの解説Note



設問3(1) | 少し観察すれば分かる


模範解答は、「order-codeの下6桁を総当たりで試行する」。


「order-codeを知らなくても」なりすましに成功するってことは、通信パケットの盗聴すらしないということ。

図5と図6のorder-codeを見ます。

  • 202404-AHUJKI

  • 202404-BAKCXW

最初の6桁はYYYYMM、最後の6桁が注文毎に採番される注文管理番号なんですね。この6桁を当てれば良いんです。

実は地味にちらっと「管理番号が短すぎるなぁ」と思っていたんです。例えばヤマト運輸さんのお問い合わせ番号（送り状番号）は12桁あります。半分なんですよね。

ちょっと余談。アルファベットと数字なので桁だけでは分からないので、パターン数を数えています。

  • 今回の問題：26の6乗は、308,915,776

  • ヤマト運輸：10の12乗は、1,000,000,000,000　

3,000倍違います。


「総当たり」をしなくても、一発当てれば攻撃に成功します。

よって別解。「order-codeの下6桁を闇雲に試す」20文字。ちょっと弱いですが正解だと思います。

また、下6桁を書かなくても行けるんじゃないかなぁ。「order-codeの英字にブルートフォース攻撃する」26文字。ブルートフォースはパスワードクラックの一種ですが、通じるので良いでしょう。＞4種類のパスワードクラックの解説Note



設問3(2) | なりすましか本人か


模範解答は、「cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違って入れば、エラーにする」。


設問3(1)、下線④より、order-codeに弱点があったので、下線⑤にてWebアプリに処理を追加することになりました。

問題文からヒントを探します。order-codeの記述は図5と図6にしかありません。こういう時って注記にヒントがあるんです。高度でよくやる手口。

図5の注記にorder-codeが「値から利用者を特定することができる」。

よって、order-code（注文管理番号）でリクエストしてきた利用者が、本人なのか確認すれば良いと分かります。


私の解答は「リクエストした利用者が、order-codeから特定した利用者と一致するかの確認処理」42文字。60文字に足りませんが、60文字がそもそも長いので、色んな書き方があるんだと判断します。

模範解答の「cookieの値」までは考えが及びませんでした。おそらくcookieのSESSIONIDから利用者IDを特定するのだと思います。

私の解答が正答になるか、失点か部分点なのかは分かりませんが、悪くない方向だとは思います（そう信じたい）。ちょっと解答するためのヒントや誘導が足りない気がしますから、採点基準も厳しくはしないかなぁと。



設問4(1) | まだ使ってない情報がある


模範解答は、「変更後のURLにPOSTデータを送ることができないから」。


サーバサイドリクエストフォージェリ（SSRF）とは、公開サーバを介して他のサーバからの応答を得る攻撃。

今回はサーバYがサイトPから情報を得る機能を悪用して、サーバYからクレデンシャル情報を返すURLにアクセスさせて、クレデンシャル情報を入手します。


下線⑥「図7のリクエストパラメータの値をWebサーバYのCMSの管理ログイン画面のURLに変更」するので、では「WebサーバYのCMSの管理ログイン画面のURL」を探します。

図2には、今まで使っていない情報がたっくさん残っています。

図2の最後「CMSについて」より、WebサーバYのhttp://■■■.jp/adminがURL。さらに「ログインは、POSTメソッドでは許可されるが、GETメソッドでは許可されない」と書いてます。

図7を見返すと「GET」を使ってます。これですね。


私の解答は「図2より、WebサーバYのCMSの管理ログインはGETメソッドでは許可されていないから」43文字なのでオーバー。

「図2より、ログインはGETメソッドでは許可されていないから」29文字。図2よりと根拠を付けました。単に「GETメソッドではログインできない」だと、理解しているのか示せてませんから。

逆に「図2より、ログインはPOSTメソッドのみに許可されているから」30文字。これで模範解答に近くなりました。



設問4(2) | pageパラメタータに気づくか


模範解答は、「パラメータpageの値をIMDSのクレデンシャル情報を返すURLに変更する」。


図7をよく見ると、GETメソッドで、サイトPの新着情報（https://△△△.jp/topic/202404.html）を入手するリクエストをWebサーバYにしています。

問われているのは「WebサーバYにクレデンシャル情報を入手するリクエスト」なので、pageの値を「サイトPのURL」から「IMDSのクレデンシャル情報を返すURL」にして、取ってきてもらうということです。


これは初見では無理ですね。

少し補足します。Webサーバは指定されたURLを表示するのが基本機能ですが、プログラムを実行できます。

例えば「https://www.google.com/search?q=IPA」とすると、「IPA
」という文字列をWebサーバに渡して「IPAってキーワードでWebサイトを検索してね」とリクエストしています。

この理解で図7の「/top?page=https://△△△.jp/topic/202404.html」を見ると、「このURLを表示してね！」という命令だと分かりますでしょうか。

よって「/top?page=https://○○○.○○○.○○○.○○○/meda-data/credential」とすれば、クラウドWのクレデンシャル情報を得られます。このURLは、図2に書いてあります。



設問4(3) | なるべく機械的に解く


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


正直、詳細を理解なんてできないので、問題文から機械的に情報を引き出して解答を作ってみます。

IMDSのアクセス方式を方式2にするとのことなので、図2の方式2を見ます。

「トークンを発行するURLにPUTメソッドでアクセスし、レスポンスボディに含まれるトークンを入手してから、そのトークンをリクエストヘッダに含めて特定のURLにアクセスすると情報を取得できる」。

さらに図2の上には「特定のURLにアクセスされると特定の情報を返す。例えば～略～クラウドW上のサービスのクレデンシャル情報を返す」とあり、クレデンシャル情報の入手法が書かれています。

上の「特定URL」を下の「クレデンシャル情報を返す」URLに、挿げ替えれば良いのです。

「トークンを発行するURLにPUTメソッドでアクセスし、レスポンスボディに含まれるトークンを入手してから、そのトークンをリクエストヘッダに含めて」「クレデンシャル情報を返す」「URLにアクセスすると情報を取得」する。

個人的には良い問題とは思えません。本文から超長い文章を3つツギハギしただけじゃないですか。



設問4(4) | 設問4(2)との芋づる問題


模範解答は、「パラメータpageの値がサイトP以外のURLならエラーにする」。


設問4(2)に正解してないと無理ですね。

図7が言っているのは、URLがサイトPなのは構わないんです。なぜなら21頁に「サイトYは、サイトPで取り扱っている情報などを表示する」なので、サイトYにアクセスして情報を取ってきて表示するのは構いません。

しかし下線⑥⑦⑧では、page=に設定するURLをサイトPから他に買えて悪用できるから問題になりました。

ということで「サイトP以外を拒否する」旨、逆に「サイトPだけを許可する」旨の作文をすれば良いのです。

よって模範解答は、「パラメータpageの値がサイトP以外のURLならエラーにする」。逆に「パラメータpageの値がサイトPのURLのときだけ処理する」。

設問には「追加すべき処理」なので、pageの処理をするコードはあるのでその後に処理を追加すると考えて、「pageの値がサイトP以外のURLの時、処理を進めない」27文字、でも良いかもです。



個人的に気になっている点


今回の問題には、セキュリティ的なリスクを残したままになっています。


サイトXのサイト管理機能への接続端末制限をしないまま


23頁最後「（サイトXの）サイト管理機能は、D社の内部ネットワーク以外からも利用する可能性があり、サイトXでは、接続元の制限は行わない」。

この所為で、攻撃者がサイトXの管理者になりすませるので、制限すべきです。

外部ネットワークからアクセスする「可能性」なら優先度は低いですし、せめて接続端末をクライアント証明書なりMACアドレスなりで制限するのは、今までの問題の王道解答でした。



初期パスワードのまま使用している


22頁図2の最後「D社では、各CMSの管理者アカウントは初期パスワードのまま運用する」。

だめでしょ。もし初期パスワードが製品共通の初期値であるなら、CMS製品を使っている人だったら初期パスワードを知っている可能性があるのではないですか？



まとめ


お疲れ様でした！


今回の学びは2点でした。

  • 一度ログイン成功した後のCookieで、次回は認証不要

  • サーバのプログラムへのパラメータの送り方（google検索を例）

具体的な手法を理解する問題になってきたなぁという印象です。

なかなか初見では混乱して得点できないかもしれません。とはいえ、2年以内に似ている手口が出ている印象もあります。

粘り強く過去問を解いて、対応力をつけていきたいですね。

今回感じたのは「文字数無制限の作文」が顕著になったこと。

ものすごく書き方が色々あり得るか、ものすごく長く本文を引用するか、だと思います。失点リスクしかないので、私は避けたいです。

かなり難しい問題でした。

とりあえず手始めにCookieから学んではどうでしょう。私が勉強した当時もちょくちょく出てたので学習ノートにまとめました。＞Cookieの解説Note



ぜひ「情報セキュリティスペシャリスト」に合格してくださいね。

＼私の3ヶ月の学習履歴／

p.s. 普段は >> 専門学校とIT就職のブログ << をやってます。
でわでわ（・ω・▼）ノシ


この記事が参加している募集

#スキしてみて

550,653件

学習方法・問題特集のNoteは全て無料提供を続けます▼ もしご覧になったNoteが有益だったり、私の志に共感されたりしましたら、サポート頂けますと励みになります▼ もちろんコメントでも結構です(・ω・▼)ノシ