現役セキュリティエンジニアによる情報処理安全確保支援士試験解説 [ 令和4年度春期試験午後Ⅰ ]

ホーム
実践記事
現役セキュリティエンジニアによる情報処理安全確保支援士試験解説 [ 令和4年度春期試験午後Ⅰ ]

実践記事

2022.11.17

この記事は投稿日から2年以上経過しています。

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

ただ、やはり情報処理技術者試験の山場は午後問です。
今回は午後問題の解説を実例やドキュメントなども踏まえて学習ができるように解説をいたします。

なお、今回は2022年度4月試験の午後問題の解説となります。
令和4年度春期試験

「TIPS:」：回答において重要な部分を補足しています。

「SecuAvail Knowledge (セキュアヴェイルナレッジ):」：問題に関連する弊社ナレッジを記載しています。筆者が調査して面白そうなトピックも扱っています。（※ 情報処理安全確保支援士受験の範疇を超えたセキュリティエンジニア向けの内容となっています）

※学生だった自分の知識量を意識して、全身全霊をかけて調査・解説をしています。説明の粒度の粗さにはご容赦ください。

午後Ⅰ 問1

設問1

（１）

解説：”イ(%0D%0A)”が正答です。

HTTPのリクエストヘッダにおける改行コードは「\r\n（ [キャリッジリターンラインフィード]）」です。※1
[ \r\n ] をパーセントエンコーディングすると、 [ %0D%0A ] になります。

IPAが公開している [ 安全なウェブサイトの作り方 ] のHTTPヘッダインジェクションの保険的対策に、 “外部からの入力の全てについて、改行コードを削除する。”」と記載があります。

Webアプリケーションのセキュリティ対策の問題は上記ページを確認しておくと、適切な回答ができるものと思います。

TIPS：

1. パーセントエンコーディング（URLエンコーディング）：
  符号化記法です。URL中にASCIIに存在しない或いは予約文字に該当する場合にはパーセントエンコーディングを行う必要があります。※2
  パーセントエンコーディングはURLのみで用いられるものでなく、POSTメソッドにおいて [ Content-Type : application/x-www-form-urlencoded ] が用いられる場合にも行われます。※3

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. 生のHTTPリクエストデータをサーバに送信する。
  用意するもの：Unix系サーバ（HTTPリクエストを受信可能）生のHTTPリクエストデータを送ることは簡単なように思えますが、そんなことはありません。
  telnetを用いてWebサーバと接続しても、改行コードが勝手に補完されるため、「生」のHTTPリクエストではありません。
  実際に生のHTTPリクエストを行う方法を記載します。
  1. 用意したUnix系サーバにログインします。
  2. 以下のコマンドを参考にワンラインコマンドを実行します。(echo -e の引数として渡す文字列がHTTPリクエストになります。)

exec 3<>/dev/tcp/localhost/80;echo -e "GET / HTTP/1.1\r\nHost: localhost\r\nConnection: Close\n\n" >&3;cat <&3

※以下のページを参考にさせていただきました
Linux JOURNAL Bashの組み込み/dev/tcpファイル(TCP/IP)の仕様に関する詳細
[ \r\n ] を他の文字に変更すると、400もしくは500番台のステータスコードが取得されるかと思います。

しかし [ \r\n ] を [ \n ] に変更した場合には、問題なくレスポンスが返ってくるかと思います。
これは、RFC7230の [ 3.5 Message Parsing Robustness ] に記載があります。

“［ start-line ／各ヘッダ］に対する行終了文字は， CRLF オクテット並びであるが、受信者は，［ 1 個の LF オクテット］を行終了文字として認識して, 先行する CR を無視してよい”

上記の仕様より、クライアントからのリクエストはCRLF [ \r\n ] で改行することが決まっていますが、受信側ではCR [ \r ] を無視してもよいようです。そのため結果的にHTTPのリクエストが成功するということのようです。

1. パーセントエンコーディング（URLエンコーディング）の結果を確認する。
  1. ブラウザの開発者ツールを開きます。（ブラウザを開いた状態で、F12を押すと開くものが多いです。）
  2. [ コンソール ] タブをクリックします。
  3. エンコーディングを行います。
    ・URLにおけるパーセントエンコーディングを実施する場合
    encodeURIの引数にエンコーディング対象の文字列を与えます。
    例：
    encodeURI('\r\n')
    ・ [ Content-Type : Content-Type : application/x-www-form-urlencoded ] においてパーセントエンコーディングを実施する場合
    encodeURIComponentの引数にエンコーディング対象の文字列を与えます。
    例：encodeURIComponent(‘+’)

WAFのログにおいてシグネチャに合致した文字列をパーセントエンコーディングやデコードすることがあるため、度々使用します。

補足情報：
※1 RFC7230 [ 3. メッセージ形式 ] に記載があります。

※2 RFC3986 [ 2.1 パーセントエンコーディング ] に記載があります。

※3 MDN 開発者向けのウェブ技術 > HTTP > HTTPリクエストメソッド > POST に記載があります。
FireFoxとGoogle Chromeにて動作確認済みです。
[ Content-Type : application/x-www-form-urlencoded ] を用いる場合には、URL中のパーセントエンコーディングとは異なるエンコーディングが行われます。
(MDN )

（２）

解説：”プレースホルダ（プレスホルダ）”が正答です。

IPAが公開している [ 安全なウェブサイトの作り方 ] のSQLインジェクションに以下の記載があります。
“SQL 文の雛形の中に変数の場所を示す記号（プレースホルダ）を置いて、後にそこに実際の値を機械的な処理で割り当てるものです。”

なお、プレースホルダはプログラミング言語のリファレンスにおいても記載があります。
Oracle社のJavaに関するドキュメントを例として提示します。
“IN パラメータは、SQL 文が作られた時点ではその値が指定されていないパラメータです。その代わり、文には IN パラメータのプレースホルダとして疑問符 (?) を付けます。「?」は、パラメータマーカとしても知られています。”

なお、HTMLにもinputタグにおけるplaceholder属性があります。
inputの入力欄内に薄く文字列を表示します。プレースホルダと聞いたときに、混同しないように注意しましょう。

（３）

解説：”改行コード”が正答です。

IPAが公開している [ 安全なウェブサイトを作り方 ] のメールヘッダインジェクションの保険的対策として、”改行コードを削除する”と記載があります。

IPAの文章においては、「あるいは改行コードだけではなく、制御コード全てを削除してもよいかもしれません。」と記載がありました。制御コードと記載しても正答とは思います。

設問2

（１）

解説：”クエリ文字列のidに、未参加のプロジェクトのプロジェクトIDを指定する。”が正答です。
以下のようなフローでアプローチできていればよいと思います。

問題文の”未参加のプロジェクトに参加しているかのように偽るための操作”に注目します。
上記の文面から、アクセス制御に関する脆弱性と推測しましょう。
“[Sシステムの改修におけるアクセス制御の要件]”に記載された、利用者のアクセス制御に関する記述を確認します。
[方法]に具体的な内容が記述されています。
記述内容より、[情報選択機能]におけるアクセス制御が外部からの入力に依存していることが分かります。

ここまでわかれば、後は回答するだけです。

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. アクセス制御の脆弱性は、WAFを導入して防げるのか

結論としては難しいと思います。
なぜならば、 [ アクセス制御に用いる情報 ] はアプリケーション側が保持しているものであり、WAFからそれを参照して制御するような機能を保持していないためです。（私が存じ上げないだけかもしれませんが）

アクセス制御に関する不備は、OWASP Top10 2021においてA01に挙がっています。可能な限りアクセス制御の設計は慎重に行いましょう。

（２）

解説：”プロジェクトを示すパラメタを外部から指定できないから”もしくは”セッション情報からプロジェクトIDを取得するから”のいずれかが回答となっています。

・「プロジェクトを示すパラメタを外部から指定できないから」
アクセス制御の不備の問題の根本は、外部からの入力をそのままアクセス制御に用いていることでした。解決した理由として、プロジェクトIDを外部から指定できなくなった旨を記述すればよいと思います。

・「セッション情報からプロジェクトIDを取得するから」
セッション情報については、[ TIPS ] にて解説しています。
セッション情報に利用者情報を紐づけている旨が [ 方法2 ] に記載されています。
セッションIDから利用者情報を取得できますので、外部からプロジェクトIDを取得することはなくなります。

TIPS：

1. セッション情報について
  開発を実際にされている方々にとってはおなじみかもしれませんが、改めて説明したいと思います。
  まず、Webアプリケーション界隈では、HTTPのセッション= [ Cookieなどのアクセス識別子を用いた一連のアクセスのこと ] を指します。(詳細は [ SecuAvail Knowledge (セキュアヴェイルナレッジ) ]にて)

Cookieを用いたセッション管理は以下のような動作と覚えておけばよいと思います。※1

1. 特定のリクエストをトリガーに、セッションIDが発行されます。セッションIDにはサーバ側にてデータを紐づけることができます。（セッションデータ）
2. クライアントへ、Set-CookieヘッダにセッションIDを含めてレスポンスを行います。
3. 次回リクエスト時、払い出されたセッションIDをCookieに含めると、Webアプリケーションにて一致するセッションIDを用いてセッションデータが取得できる。

セッション情報というのは、Cookie内のセッションIDから引き出せる値です。

サーバサイドの処理にてセッション情報としてプロジェクトIDを紐づけておけば、次回アクセス時に外部からの入力に依存しないで情報選択機能を利用できるわけですね。

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. 「HTTPセッション」という曖昧な言葉

「HTTPセッションって、HTTP/1.1で実装されたKeep-Aliveヘッダを用いた一連の通信のことですか？」と疑問に思われる人は、恐らく情報処理安全確保支援士を受験される方にはいないと思いますが、念のため補足をします。

「HTTP セッション」で検索すると最も上位にくる、MDNのHTTPセッションについての説明と本問題文のセッションは別の意味であり、上記で説明している事項に近いです。

本来「セッション」という表現は、多くの場合アプリケーションレイヤにおける一つの接続における通信確立状態を指します。（プロトコルによって概念が異なるケースがあるため、ここでは「多くの場合」と記載しています。）

ただし、HTTPはステートレスなプロトコルであるため、慣習的にCookie等のアクセス識別子を使った一連の通信をセッションと呼びます。

また、「セッション」という言葉はセキュリティ機器であるUTMにおいては、異なる定義がされています
UTMはプロトコルに依存せず、一連の通信をセッションとして管理します。
セッションという言葉一つもケースバイケースで指し示すものが異なりますので、注意しましょう。

なお、私はお客様と会話をするときには、「Cookieを用いたHTTPセッション」あるいは「1コネクションにおけるHTTP通信」などと記述や呼称を区別して混同を防ぐように心がけています。

補足情報：

※1 ｐｈｐマニュアル [ PHPマニュアル > 関数リファレンス > セッション関連 > Sessions > 例 ] を参考にしています。

（3）、（4）

申し訳ありません、こちらについては的確な解説が難しいため、割愛いたします。力不足で申し訳ありません。

設問3

解説：“情報番号 = ? AND プロジェクトID = ?”が正答となっています。

脆弱性を持つアプリケーションを作成しましたので、確認してみたいと思います。
ログイン後、/menuから「情報の投稿」をクリックします。

情報選択機能を「方法1」から「方法2」に変更したことで、適切なプロジェクトの情報のみがプルダウンに表示されるようになりました。

ただ、修正を行った箇所は情報選択機能の画面「/select」のみですので、情報表示機能の画面「/show?no=…」については修正されていません。
修正が行われないと、以下のように自分が参加していないプロジェクト外の「情報」にアクセスできてしまいます。

「情報」の主キーである、「情報番号」はユニークな値ですので、SQL上は情報番号のみがあれば取得可能です。
しかし、図3の7行目のソースコードに「利用者の参加プロジェクトのプロジェクトIDを利用者テーブルから取得し、代入する処理」があります。
利用者のプロジェクトIDと情報番号で論理積を求めなければ、アクセス制御の不備につながってしまいます。

午後Ⅰ 問2

設問１

（１）

解説：”a：ア（A）”、”b：エ（TTL）”が正答です。

[ a ] ： FQDNからIPアドレスを取得するときに利用されるRR(リソースレコード)を選べという問題です。

これはA（アドレス）レコードですね。暗記問題です。
A、CNAME、MX、NS、PTR、SOAについては利用用途を覚えておきたいです。※1

[ b ] ： DNSの名前解決が関わる処理において必ず重要になる、キャッシュ時間を表すものを選べという問題でした。

答えは、TTL(Time To Live)です。

DNSは現代のインターネットを支える技術であるため、思わぬところで知識が求められることがあります。
DNSに苦手意識のある方は、一度学びなおしてみるとよいと思います。

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. UTMのFQDNオブジェクトとTTL

UTMでは [ FQDNオブジェクト ] を生成することができます。

UTMの通信ポリシーの宛先にFQDNオブジェクトを設定した場合には、そのFQDNが名前解決された結果のIPアドレスへの通信が行えるようになる設定です。

あるサービスが特定のFQDNを使用するとします。
サービスへの通信を許可する際に、そのサービスで使用されているIPアドレスを全て登録すると、手間がかかります。また、サービスで使用されるIPアドレスが変更された場合にも手動で設定変更しないといけません。

しかしFQDNオブジェクトを使用すれば、サービスで使用されるFQDNさえ変更されなければ勝手に名前解決されるIPアドレスも更新されるため、管理の手間がかなり省かれます。

このFQDNオブジェクトは実際にどのような挙動をしているのかというと、UTMがFQDNオブジェクトのFQDNを名前解決し、その結果得られたIPアドレスをポリシーに適用しているようなイメージになります。
ここでTTLを理解しておくことが重要になります。

私が遭遇したのは、以下のケースです。
[セキュリティ機器にFQDNオブジェクトを作成するケース]

特定のFQDNのみに通信が行われるようにポリシーを設定していたものの、ある日突然そのFQDNへの通信が行えなくなりました。

お客様にて、そのFQDNのAレコードを更新されたのですがTTLが長く設定されており、更新以前のAレコードによって名前解決されたIPアドレスをUTMがそのままポリシーに適用しました。クライアントで保持している名前解決結果とUTMが保持する名前解決結果が一致しなくなったことで、通信ができなくなったとのことでした。

上記のような事象が発生しうるため、きっちりと設計は行いましょう。

また、UTM機器ではAレコードに設定されたTTLを無視して独自にキャッシュ時間を定義できるもの（FortiGate）のほか、独自のコマンドを実行するとキャッシュを更新することができる(PaloAlto)ものなど、仕様が異なります。いざという時に困らないように仕様を把握しておきましょう。

1. 名前解決結果のIPアドレスをどのように扱うのか

FQDNを用いる設定を行う場合には「名前解決したときに、初めに結果が返ってきたIPアドレスのみを使う」「名前解決結果のIPアドレス全てを使う」のどちらなのかを確認しておくとよいです。

必ずしも、名前解決結果全てのIPアドレスが利用される仕様だけではありません。
動作の詳細が記載されていない製品の場合には、上記のどちらであるのかを確認するべきと考えます。

参考情報：

※1 JPRS用語辞典 [ リソースレコード（RR） ]を参照するとよいです。

（２）

解説：”外部からLAN側への通信の許可設定が変更される。” が正答になっています。
“LAN側の機器から受け付けたリクエストの内容で、ポートフォワーディングの設定とファイアウォール機能の設定を行う（LAN側で機能を有効にしている場合の動作）”であるため、これがWAN側で有効にできる仕様の場合には、外部から上記の設定変更が可能になります。

（３）

解説：”PCからのファイル操作ではアクセスできない領域のファイルが暗号化されたから”が正答となっています。

調査結果を確認すれば、ヒントがありましたので比較的簡単だったかと思います。

設問2

（１）

解説：”c：パストラバーサル”が正答です。

IPAが公開している [ 安全なウェブサイトの作り方 ] に [ 1.3 パス名パラメータの未チェック／ディレクトリ・トラバーサル ] がありますので、こちらで攻撃内容については確認しましょう。

なお、正答ではパストラバーサルとありましたが、ディレクトリトラバーサルでも正当になると思われます。
OWASPのPath Traversalのページに、”A path traversal attack (also known as directory traversal) ”と記載がありました。※1
また、dot-dot-slash/directory climbing/backtrackingなどといった名称もあるそうです。それらに類するものでも問題は無いと思います。

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. UTM（FortiGate,PaloAlto）とWAF（BIG-IP）におけるパストラバーサルとディレクトリトラバーサルのシグネチャについて

FortiGate、PaloAlto、BIG-IP(AWAF)においては、ディレクトリトラバーサルが一般的と思われます。FortiGateとPaloAltoのIPS情報のDBにおいて、パストラバーサルとディレクトリトラバーサルにてIPSのシグネチャ数を検索したところ、ディレクトリトラバーサルのほうが倍以上ヒットしました。

「パストラバーサルの脆弱性」として報告された脆弱性は、シグネチャ名称でもパストラバーサルとしてシグネチャ生成がされているようですので、そもそも脆弱性の報告もディレクトリトラバーサルとして報告されることが多いと思われます。
またBIG-IP(AWAF)もディレクトリトラバーサルという名称を使っています。

参考情報：

※1 Path Traversal

（２）

解説：”OSコマンドインジェクション”が正答となっています。

“任意のOSコマンドを実行できてしまう”の部分でOSコマンドインジェクションが頭に思い浮かぶと思います。
その後の文章でも他の脆弱性を疑わせる文面はないため、OSコマンドインジェクションと回答できます。

（３）

解説：”URLデコード => パス名の正規化 => 除外リストとの比較”が正答となっています。

実際の例を出した方が分かり易いかと思います。
例 [/images/..%2fping.cgi] において

・”①URLデコード => ②パス名の正規化 => ③除外リストとの比較”の場合
①/images/../ping.cgi
②/images/ping.cgi
③/imagesに合致する

設問3

（１）

解説：”POSTメソッドで送信したボディがアクセスログに残っていなかったから”が正答となっています。

問題文中に以下の記載があります。
「表3からは、GETメソッドを使用して実行されたOSコマンドの内容はわかったが、POSTメソッドを使用して実行されたOSコマンドの内容は分からなかった。」

GETメソッドにおいてサーバに情報を送る方法といえば、「クエリ(クエリパラメータ/クエリストリング)」です。※1
クエリはURIの一部でありますので、GET、POSTいずれでも利用可能です。

[POSTメソッドで実現可能なサーバに情報を送る方法] – [GETメソッドで実現可能なサーバに情報を送る方法] = [HTTPリクエストボディを使用してリクエストを送る] が一般的な認識かと思います。

そのため、POSTメソッド特有のHTTPリクエストボディがどのように扱われているのかを気にすれば回答できたと思います。
（GETメソッドにおいてHTTPリクエストボディを用いてリクエストを送ることができない旨の記載はみつけられませんでした。
※詳しくは [ SecuAvail Knowledge ] をご参照ください。）

Webアプリケーションにおいて、HTTPリクエストボディのログを取得するというのは現実的ではありません。技術的には可能ですが、ログ容量がかなりかさむためです。
そのような事情もあり、少なくともApacheではデフォルトでHTTPリクエストボディを取得しない設定ではないかと存じます。

ログを取得するとしても、Webサーバやアプリケーションサーバでは取得せずに、ログ送出用のリバースプロキシを用意するほか、スイッチでミラーポートを用意するなどといった対応になるかなと思います。

そういったことが難しい場合には、アクセス制御に関するログを取得するようにするほか、SQLのログを取得するといった方法で証跡を残すことなどは検討できるかと思います。

いざインシデントが発生した時に証跡を追えなくなることがないように、ログ取得については事前に確認しておきましょう。

SecuAvail Knowledge (セキュアヴェイルナレッジ)：

1. GETメソッドでもHTTPリクエストボディを送信して応答されるのか
  POSTメソッドにおいて、HTTPリクエストボディを送信できる仕様について記載されている箇所を見つけました。RFC7230 [ 4.3.3 POST ] に「［ターゲットリソースが，自前の特有な意味論に則って，要請内に同封された表現を処理する］ことを要請する。」と記載があります。ここでいう「表現」は「［所与のリソースの［過去の／現在の／欲される］状態を反映する］ように意図された，［プロトコルを介して通信するに適した形式による情報］であり，［表現メタデータからなる集合, および表現データのストリーム（長さ無制限にもなり得る）］からなる。」と記載があります。「ペイロード本体」は、[ message-body ]であり、HTTPメッセージは [ start-line ] , [ header-field CRLF ],[ message-body ] に分けられます。
  そのため、POSTはHTTPリクエストボディをを送信するための方法として解釈ができるかと思います。

また、GETメソッドにおいては以下の記述がありました。
「 GET 要請メッセージのペイロードには、意味論は定義されない — 既存の実装には、ペイロード本体を伴って送信されてきた GET 要請を却下するものもある。　」

GETメソッドを使用して、ペイロード本体（HTTPリクエストボディ）を含めたリクエストを送った場合には、ミドルウェアの実装によって挙動が異なるようです。

WAFの設定で、GETリクエストにHTTPリクエストボディが含まれている場合には遮断する設定があり、こういった実装にWebアプリケーションの挙動を依存させない目的と思われます。

参考情報：

※1 RFC3986 [ 3.4. クエリ ] に記載があります。