情報処理安全確保支援士試験解説 [ 令和4年度秋季試験午後Ⅰ問1 ]

ホーム
実践記事
情報処理安全確保支援士試験解説 [ 令和4年度秋季試験午後Ⅰ問1 ]

実践記事

2023.07.20

セキュリティエンジニアを目指す学生の皆様も、既にセキュリティエンジニアとして従事している皆様も、情報処理安全確保支援士を取得するために日々研鑽をされていると思います。

秋季試験午後Ⅰ問1のいくつかの問題をピックアップして解説していきます。

過去問関連リンク：https://www.ipa.go.jp/shiken/mondai-kaiotu/2022r04.html

参考になるものがあれば幸いです。

午後Ⅰ 問1

設問1

(2)

解説：”エ（UDP）”が正答です。

なお、DNSにおいて「TCPフォールバック」という方式が利用される場合には、TCP 53番ポートを利用して名前解決要求が送信されます。
https://jprs.jp/related-info/guide/topics-column/no8.html

しかし、DNSキャッシュポイズニングの脆弱性は、UDP特有の「通信相手とコネクションを張らない」という部分により生まれます。
そのため、この問題自体はUDPが正答と判断することができます。

(4)

解説：”サーバﾞ証明書を検証し、通信相手がWサーバであることを確認する実装”が正答です。

SSL/TLS証明書を用いるHTTPS通信では2つの目的があります。

通信の暗号化
通信相手が利用する証明書の妥当性確認

ここで通信相手が利用する証明書の妥当性確認というのが本回答において重要なポイントになります。

証明書についてエラーが発生するケースは以下の通りです。

証明書の有効期限が切れている
証明書が信頼できる認証局から発行されていない（UAが把握していないCAの証明書である）
証明書のドメイン名とリクエスト時のドメイン名が一致していない
証明書が無効にされている
証明書チェーンが不完全/不正確な場合

※他にもあるかもしれません。
一般的にはユーザエージェントにて、上記に合致するケースではエラーとして処理されます。

例を出して確認をしてみます。
[ test.secuavail.com ] は 192..0.2.1 としてコンテンツサーバに登録されています。
クライアント端末はDNSキャッシュポイズニングの影響をうけ、 [ fake.secuavail.com ] が 192.0.2.1 としてキャッシュされてしまっているとします。

上記のような場合には、ブラウザに [ test.secuavail.com ] と入力してリクエストを送ると、 [ fake.secuavail.com ] のサーバへとリクエストが送信されます。
この時に証明書の検証が問題なければ、証明書のドメイン名とリクエスト時のドメインが一致していないという証明書エラーが発生します。

本来、HTTPS通信であれば、何らかの証明書が適用されている必要がありますので、ユーザエージェントによって検証が行われるはずです。
しかし、開発時に公的な証明書が発行できない場合などには、明示的に証明書エラーを無効にすることがあります。
それに気づかぬままソフトウェアがリリースされてしまわないように気を付ける必要があります。

設問3

(1)

解説:”攻撃リクエストをPOSTメソッドで送信させるスクリプトを含むページを表示させる仕組み”が正答です。

まずCSRF攻撃について振り返りましょう。

この攻撃について理解するには、以下のポイントを押さえておく必要があります。

HTTPリクエストについて大まかな理解（割愛）
Cookieの仕様
JavaScriptを利用したHTMLの操作

CSRF攻撃はCookieとユーザエージェントの仕様をつきます。

Cookieはデフォルトの属性値では、同一オリジン（認証を行ったサイト）へのリクエストへ送出されます。

HTMLとJavaScriptを組み合わせることで、あるイベントと同時に任意なサイトへHTTPリクエストを送ることができます。

上記を踏まえて、ログインが必要な掲示板サイトを例にCSRF攻撃を理解しましょう。

掲示板へはログイン後に、自分のアカウントへ書き込みを行います。
掲示板に書き込む時にはCookieと掲示板に書き込む情報が送られます。
この場合に、悪意を持った第三者が掲示板へ書き込むように、HTMLとJavaScriptを記述したページを用意されたとします。
掲示板にログイン中に、あなたがその罠ページにアクセスすると、勝手にCookieと書き込み内容が送信されてしまい、あなたのアカウントによって悪意を持った第三者の意図した書き込みが行われてしまいます。

CSRF攻撃についてさらに理解を深めるにはこちらをご参照ください。

なお、引っかかりそうなポイントとして、XSSに用いられる攻撃方法を回答してはいけません。

詳細は説明しませんが、CSRFは同一オリジンポリシーによって阻害されない方法で、罠サイトから攻撃先サイトへリクエストを送れることがポイントとなっています。
“同一オリジンポリシーは重要なセキュリティの仕組みであり、あるオリジンによって読み込まれた文書やスクリプトが、他のオリジンにあるリソースにアクセスできる方法を制限するものです。”
（引用元：https://developer.mozilla.org/ja/docs/Web/Security/Same-origin_policy）