S 社は，情報システムの構築，運用，コンサルティングなどのサービスを顧客に提供する従業員数 5,000 名の企業である。S 社にはセキュリティプロフェッショナルグループ（以下，SPG という）という組織があり，Web アプリケーションソフトウェア（以下，Web アプリという）の脆弱性を検査するサービス（以下，脆弱性検査という）を提供している。
SPG では，脆弱性検査に従事できる者を認定するために，技能試験を実施している。技能試験は，Web アプリに脆弱性が作り込まれた，技能試験用の Web サイト（以下，試験用サイトという）を用いて実施される。試験用サイトは，個人間で取引するオークションシステムを想定しており，“http://...”及び“https://...”の画面がある。図1に試験用サイトの画面構成と画面の遷移を，図2に画面 C の概要をそれぞれ示す。また，試験用サイトの機能のうち，セッション管理機能の仕組みを図3に，検索文字列の引継機能の仕組みを図4に示す。
図1 試験用サイトの画面構成と画面の遷移図2 画面 C の概要図3 セッション管理機能の仕組み図4 検索文字列の引継機能の仕組み
〔技能試験〕
SPG に新たに配属された従業員は研修検査員と呼ばれ，2か月間の研修を終えると，技能試験を受ける。技能試験に合格した者だけが脆弱性検査を実施できる規則になっている。技能試験では，脆弱性検査専用の Web ブラウザを使用する。検査専用の Web ブラウザには，一般的な Web ブラウザの機能に加えて，送信する HTTP リクエストやパラメタの値を意図的に変更する機能がある。
技能試験では，試験官とのディスカッション，検査手順や報告書の作成を通して，力量が判断され，合否が決定される。このたび，研修検査員の T 君が，技能試験を受けることになった。試験官は U 主任である。最初に，U 主任は，技能試験の前提として図1及び図2の内容を T 君に伝えた。
なお，図3及び図4の内容は T 君には伏せられている。
〔検査シナリオと HTTP ヘッダ〕
技能試験の開始に当たって，U 主任は，図5に示す検査シナリオの順番で画面にアクセスするよう T 君に指示した。T 君が検査シナリオを実行した際の HTTP リクエストヘッダ及び HTTP レスポンスヘッダを，図6に示す。
図5 検査シナリオ図6 検査シナリオを実行した際の HTTP ヘッダ（抜粋）
〔脆弱性に関するディスカッション〕
次は，図6に関する U 主任と T 君のディスカッションである。
U 主任：図6中のレスポンス X について，セキュリティ上，気になる点があれば指摘してください。
T 君：Set-Cookie ヘッダに，①secure 属性が設定されていません。secure 属性を設定しないと，セッション ID を第三者に盗聴されるリスクがあり，セッションハイジャックなどにつながると思います。
U 主任：他に，図6全体を通して，気になる点はありますか。
T 君：HTTP ヘッダインジェクションの脆弱性が存在する可能性があります。図7の検査コードをリクエストのクエリ文字列のパラメタの値にセットし，スクリプトの実行ができるかどうか，確認してみます。
図7 クエリ文字列のパラメタの値にセットする検査コード図8 ASCII 文字コード一覧（抜粋）
T 君が，図7の検査コードを用いて確認したところ，予想どおり，警告ダイアログが表示された。T 君は，HTTP ヘッダインジェクションの脆弱性が存在することを指摘した。
T 君：サーバ側での HTTP レスポンスヘッダの出力処理に問題があり，HTTP ヘッダインジェクションの脆弱性が存在すると思います。具体的には，入力された検索文字列を適切に処理せずに Set-Cookie ヘッダの値にセットしているものと思われます。この脆弱性を突いた攻撃では， b 攻撃と同様に，攻撃者が指定した任意のスクリプトをクライアント側で実行できます。
U 主任：仮に問題があるとした場合，Set-Cookie ヘッダの値をセットするサーバ側の処理において，どのような対策が考えられますか。
T 君：幾つかの対策があります。例えば，HTTP レスポンスヘッダを適切に出力するために，Web アプリの実行環境やプログラム言語が用意している，ヘッダ出力用の関数や API を使用する方法が考えられます。それが使用できない場合は， c するといった処理を開発者自身で実装する方法も考えられます。
U 主任：その他に気になる点はありますか。
T 君：はい。図6の一連の HTTP ヘッダのうち，例えば，行番号 d と行番号 e を見比べると，サーバ側のセッション管理に問題があり，セッションフィクセーションの脆弱性が存在する可能性があります。攻撃者が Cookie Monster Bug を突く攻撃や，前述した HTTP ヘッダインジェクション攻撃を組み合わせることによって，セッションフィクセーションを成功させる可能性があります。図9に攻撃手順の一例を示します。
図9 攻撃手順の一例
U 主任：セッションフィクセーションの脆弱性について，どのような対策が考えられますか。
T 君：例えば，サーバ側の処理を変更する方法があります。検査シナリオの画面遷移でいえば，ログイン後の，画面 E から画面 C に遷移する際の，サーバ側の処理において， g といった対策を行うことによって，この脆弱性を確実に防ぐことができます。
攻撃者が指定したスクリプトを，利用者の Web ブラウザ（クライアント側）で実行させる攻撃はクロスサイトスクリプティング（XSS）である。HTTP ヘッダインジェクションでは，ヘッダの区切りを注入して応答の本文にスクリプトを入れられるので，同様のことができる。正解はウ。
アの SQL インジェクションはデータベースへの問合せを書き換える攻撃で，スクリプトのクライアント側での実行とは違う。イの TCP SYN Flood は SYN パケットを大量に送ってサービスを使えなくさせる DoS 攻撃。エのディレクトリトラバーサルは，“../”などで公開範囲の外のファイルを読み出す攻撃で，いずれもクライアント側でスクリプトを動かすものではない。
解答例は“ウ”。
設問2(3)30字以内解答欄1つ
本文中の c に入れる適切な処理を，30 字以内で具体的に述べよ。
〔c〕解答例
出力文字列に改行コードがあるとエラー画面を出力
出力文字列の改行コード以降の文字列を削除
解説
本文の根拠
T 君の発言
それが使用できない場合は，
T 君の発言
入力された検索文字列を適切に処理せずに Set-Cookie ヘッダの値にセットしている
この脆弱性は，検索文字列に含まれる改行コード（CR・LF）が Set-Cookie ヘッダの値にそのまま入ることで起きる。ヘッダ出力用の関数や API が使えない場合は，開発者が自分で，出力する文字列の改行コードを扱う処理を実装する。解答例は二つで，“出力文字列に改行コードがあるとエラー画面を出力”と“出力文字列の改行コード以降の文字列を削除”。どちらも，改行コードを含んだままヘッダに出さないという点が同じで，どちらか一つを書けばよい。
セッションフィクセーションは，攻撃者が用意したセッション ID を，利用者にログインさせて使わせる攻撃で，ログインの前後でセッション ID が変わらないと成り立つ。図5の検査シナリオは，画面 A で Cookie が発行されたあと，画面 E でログインして画面 D へ進む。図6では，行09でサーバが発行したセッション ID（134D96E470da240421svr5B019）が，画面 B へのアクセス（行17）にも，ログイン後の画面 D へのアクセス（行27）にも，同じ値で付いている。ログインの前後でセッション ID が更新されていないので，d は“09 又は 17”，e は“27”になる。備考に“順不同”とあるので，d と e の組は入れ替えてもよい。
図9中の手順4及び5について，利用者 K がログインした後，攻撃者 J が利用者 K になりすますことができるのはなぜか。“セッション ID”という字句を含めて 40 字以内で述べよ。
解答例
攻撃者Jが取得したセッションIDで利用者Kにログインさせているから
解説
本文の根拠
図3
以後，同一のセッション ID によるアクセスには，同一のセッションオブジェクトが利用され，サーバでセッションが管理される。
図9 手順3，4，5
利用者 K がログインする。
図9 手順5
攻撃者 J は，利用者 K になりすまし，本来はアクセス権限がない画面にアクセスできるようになる。
サーバは，セッション ID をキーにして，ログイン状態を保持するセッションオブジェクトを管理している（図3）。K のブラウザには J が取得した“01234”が設定されていて，K がそのセッション ID のままログインするので，サーバ側では“01234”のセッションオブジェクトがログイン済みになる。J は同じ“01234”を持っているため，そのセッション ID を使ってアクセスすれば K として扱われる。
セッションフィクセーションは，ログイン前に攻撃者が知っていたセッション ID がログイン後も有効なまま使われることで成り立つ。そのため，ログインに成功したときに，サーバが新しいセッション ID を発行してそのセッションに切り替えれば，J が持っている“01234”はログイン済みのセッションと結び付かなくなる。認証の後にセッション ID を更新することは，OWASP の Session Management Cheat Sheet も勧めている。
問題文は“画面 E から画面 C に遷移する際の，サーバ側の処理”と処理の時点を示しており，ログインに成功したその時点で ID を更新する対策を書く。Set-Cookie ヘッダの値を直す対策（設問2）では，Cookie の植え付け自体を防ぐだけで，ID が変わらないという問題は残る。
L 社ネットワーク上の全てのサーバ，ネットワーク機器及び PC は，NTP サーバと時刻同期を行っている。
L 社での PC に関する環境を図2に示す。
図2 PC に関する環境（抜粋）
L 社のサーバ，ネットワーク及び PC は，IT 部が，M 部長の下，リーダの N さんを中心に 10 名で設計，構築，保守・運用を行っている。
L 社では，サーバごとに個別の利用者 ID を IT 部の各従業員に付与しており，サーバの保守・運用時には，その利用者 ID を用いて SSH でサーバに接続し，管理者権限に昇格して作業を行う規則になっている。また，IT 部ではサーバの保守・運用に使用する利用者 ID 及びパスワードの情報を PC に保管してはならない規則となっている。
〔情報漏えいインシデント〕
4月23日に，L 社が加盟しているセキュリティ情報共有団体から L 社に連絡が入った。海外のセキュリティ団体が入手した C&C（Command & Control）サーバの通信履歴の中に，L 社に割り当てられている IP アドレスからの通信が含まれていたとのことであった。セキュリティ情報共有団体からは，C&C サーバの IP アドレス及びポート番号，送信元 IP アドレス並びに C&C サーバ側の受信日時の情報が提供された。受信日時は協定世界時（UTC）で4月16日7時13分であった。
〔初期対応〕
M 部長から指示を受け，N さんが確認したところ，送信元 IP アドレスは間違いなく L 社のものであった。また，①この IP アドレスから当該 C&C サーバへの通信が発生していたことも確認できた。送信日時は日本時間で4月16日16時13分であった。これらの確認結果を基に，セキュリティ情報共有団体に更なる情報提供を依頼したところ，当該 C&C サーバに送信された情報が提供された。その中には，L 社のファイル配信サーバのホスト名，IT 部の V さんに付与された当該サーバの利用者 ID 及びパスワードが含まれていた。
N さんは，調査結果を M 部長に報告し，次の緊急対応を実施した。
ファイル配信サーバ上での当該利用者 ID の無効化
FW による，当該 C&C サーバへの通信の遮断
N さんは M 部長の指示で，漏えい元を特定するために，C&C サーバへの通信の送信元を調査した。その結果を図3に示す。
図3 C&C サーバへの通信の送信元の調査結果
N さんは当該 PC をネットワークから切り離した上で，M 部長に図3の調査結果を報告した。
〔詳細調査と暫定対応〕
N さんは M 部長の指示で，当該 PC に対するディジタルフォレンジックスによる調査を，セキュリティ専門会社に依頼した。セキュリティ専門会社による調査報告を図4に示す。
N さんは，影響範囲及びマルウェア感染経路を特定するための追加調査を立案し，M 部長から実行承認を得た。追加調査の内容を図5に示す。
図5 影響範囲及びマルウェア感染経路を特定するための追加調査
L 社では，AV ベンダとの間で，マルウェアの調査及び対応するウイルス定義ファイルの作成を依頼できる契約を結んでいる。N さんは，図4で報告された3種類のマルウェアについて，対応するウイルス定義ファイルの作成を AV ベンダに依頼し，そのウイルス定義ファイルを用いて追加調査1を実施した。その結果，L 社内の他の PC 及びサーバでは，これらのマルウェアの感染は確認されなかった。
N さんは，追加調査2として，ファイル配信サーバ上に保存されている操作ログ，アプリケーションプログラムのログ及び配信ファイルのアーカイブを調査した。ファイル配信サーバから3月28日以降に配信されたファイルは，全て N さんが V さんに指示して配信したものであることが確認できた。
N さんは，追加調査3として，L 社内のサーバのうち，V さんの利用者 ID でアクセス可能な全てのサーバ上のアクセスログを調査し，最初のマルウェア感染後に V さんの利用者 ID で当該 PC からアクセスされたサーバを特定した。当該サーバとして，ファイル配信サーバ以外に，NTP サーバ，DHCP サーバ兼内部 DNS サーバ及びプロキシサーバの3台が確認できた。これら3台のサーバ上の操作ログを更に詳細に確認したところ，各サーバに対する V さんの利用者 ID での操作は，全て N さんの指示に基づく保守・運用作業であり，不正な操作が行われた形跡はなかった。これら3台のサーバは，L 社ネットワーク構成において重要であり，サービス停止ができないものであった。N さんは，これらのサーバ上で不正な操作が行われた形跡がなかったこと及びサービス停止ができないことから，⑤これらのサーバ上で実行可能で効果の見込まれる対策を実施した。
N さんは，追加調査4として，3月1日から28日までに V さんが受け取った電子メールを調査するとともに，V さんへの聞き取りを実施した。その結果，V さんが，3月28日に，インターネットファックスサービスを装った電子メールを受け取り，添付ファイルを開いていたことが判明した。AV ベンダに調査を依頼した結果，このファイルはダウンローダをインストールすることが分かった。
N さんは，これらの結果を M 部長に報告した。
M 部長は，追加調査3について，⑥これら3台のサーバ上のログに対する改ざんの痕跡が残っていないことを確認したか，N さんに尋ねた。N さんは，ログの改ざんを想定した調査は行っていなかったことを報告し，ログの再調査を実施した。再調査の結果，これら3台のサーバ上のログに対する改ざんの痕跡は残っていなかった。N さんは，M 部長に再調査の結果を報告した。
3台のサーバ（NTP サーバ，DHCP サーバ兼内部 DNS サーバ，プロキシサーバ）は，V さんの利用者 ID でアクセスされていたが，不正な操作の形跡はなく，サービスを止められない。この条件で効果があり，すぐに実施できるのは，漏えいした V さんの利用者 ID を各サーバで無効化することである。ファイル配信サーバでは初期対応で同じことを済ませており，3台でも同様にできる。
Z 社は，従業員数 300 名の衣料品販売企業であり，インターネット上で衣料品を購入できるショッピングサイト（以下，Z サイトという）を7年前から運営している。Z サイトは，携帯電話，スマートフォン及び PC を対象としたサイトであり，オンライン決済にはクレジットカードを採用している。クレジットカード情報は会員情報として保存せずに，決済の都度入力してもらう方式にしている。利用者は，会員登録をすれば，購入金額に応じたポイントをためて，購入代金への充当や，他社のギフト券への交換ができる。Z サイトの現在の会員数は約 400 万人である。
Z サイトの会員の利用者 ID は，会員のメールアドレスであり，パスワードは，携帯電話での利便性を考慮し，数字6桁の固定長となっている。同じ日の0時から 24 時の間に連続5回認証に失敗した利用者 ID は，アカウントロック状態となり，翌日にその状態が解除される仕組みとなっている。
〔不正アクセスの発生〕
ある日，Z サイトの問合せ窓口の担当者から，Z サイトの運用を担当しているシステム運用部の A 主任に連絡があり，ポイントが勝手にギフト券に交換されたという被害の連絡を，会員 11 名から受けたことが報告された。報告を受けた A 主任がログサーバを調査したところ，特定の IP アドレスから，Z サイトの会員ページへのログイン試行が，短時間のうちに大量に発生していたことが分かった。A 主任は，上司である B 部長の指示の下，全会員に事象を告知するとともに，経営陣の承認を経て Z サイトを緊急閉鎖し，以前にセキュリティ診断を依頼したことがある Y 社に，この不正アクセスの調査を依頼した。大量のログイン試行のログを表1に示す。
表1 大量のログイン試行のログ（抜粋）
〔不正アクセスの調査結果〕
3日後，Y 社による，不正アクセスの詳細な調査が終了した。次は，A 主任が B 部長に調査結果を報告した際の会話である。
A 主任：Y 社の調査によると，パスワードを固定した上で，約 70 万個の文字列を次々に利用者 ID として入力し，ログインを試行するという攻撃があったとのことでした。試行された利用者 ID のうち，7万個については，利用者 ID として実在していました。また，実際に 560 件の利用者 ID については，不正ログインまで成功しており，さらに，130 件については，ポイントが不正に交換されていました。
B 部長：ポイントが不正交換された会員への連絡は済んでいるのかね。
A 主任：はい，不正交換された会員を含め，不正ログインされた会員への個別連絡と，全会員への注意喚起は完了しています。
B 部長：分かった。経営陣には私から報告しておく。
A 主任：不正ログインされた会員に対して，パスワードリセットを実施したいのですが，よろしいでしょうか。
B 部長：Z サイトの再開までにはパスワードリセットも必須だが，それよりも，今回のような攻撃は今後も繰り返される可能性があるので，Y 社に依頼して，現在の Z サイトのアカウント管理の問題点を調査してもらってくれ。パスワードリセットと Z サイトの再開時期については，問題点の調査結果を見た上で考えることにする。
A 主任：分かりました。それでは再度 Y 社に調査を依頼します。
A 主任は，早速 Y 社に調査を依頼し，当日中に Y 社による調査が開始された。
〔問題点の調査結果と改善案〕
調査開始から4日後，Z サイトのアカウント管理における問題点の調査結果の報告が Y 社からあり，複数の問題点が存在することが分かった。Y 社が報告した Z サイトのアカウント管理の主要な問題点を図1に示す。
図1 アカウント管理の主要な問題点
また，Y 社は，これらの問題点についてそれぞれ図2の改善案を提示した。
図2 改善案
A 主任は，これらの改善案を実施するためのシステム改修の見積作業に取り掛かった。
〔暫定再開の検討〕
見積りの結果，ハッシュ値の保存に必要な領域が，1アカウント当たり 16 バイトから a バイトに変更されるのに加え，ソルトの保存領域の追加などの改修やディスクの増設が必要となり，再開まで3か月掛かることが分かった。A 主任は，そのことを B 部長に相談したところ，3か月間の Z サイト閉鎖は，経営上の影響が非常に大きいので，何らかの対応を行った上で暫定再開する方法を Y 社と検討するよう指示を受けた。次はその時の，A 主任と Y 社の C 氏との会話である。
A 主任：システム改修の3か月間，Z サイトを閉鎖することは，当社にとって影響が非常に大きいことから，何らかの対応を行った上で暫定再開させたいのですが，良い方法はないでしょうか。
C 氏：経営上の影響を考えると暫定再開はやむを得ないですね。図3のようなパスワードに対する攻撃（以下，パスワード攻撃という）を検知し対応する仕組みを導入し，攻撃を検知した場合は都度対応する運用とした上で，暫定再開する方法はいかがでしょうか。ただし，暫定再開に当たっては，不正ログインされた会員のパスワードリセットを忘れずに実施してください。また，ポイントの交換については，システム改修が完了するまで停止した方が良いと思います。
図3 パスワード攻撃を検知し対応する方法
A 主任：分かりました。ところで，三つの方法は，それぞれどのようなパスワード攻撃を検知することができるのですか。
C 氏：方法(ア)では，パスワード総当たり攻撃や辞書攻撃を検知します。方法(イ)では，今回の攻撃のように，同一 IP アドレスからのリバースブルートフォース攻撃を検知します。方法(ウ)では， c から行われるパスワード攻撃を検知します。ただし，どの方法も，攻撃を 100％検知できるというわけではありません。
A 主任：分かりました。それらの対応であれば1週間でできそうです。
A 主任は，暫定再開に向けた作業を行い，1週間後，Z サイトを暫定再開した。
〔本格再開の検討〕
A 主任は，本格再開に向けた作業を確認するために，再び C 氏に相談した。次はその時の A 主任と C 氏との会話である。
A 主任：パスワード攻撃の監視と対応を継続すれば，システム改修にもう少し時間を掛けてもよいのではないかと考えているのですが。
C 氏：それは危険です。実は問題が幾つかあります。例えば，パスワード攻撃には，方法(ア)～(ウ)を組み合わせても検知できないものがあります。現行のパスワード強度と改善後のパスワード強度を比較評価するため，その攻撃が行われた場合に，どのくらいの時間で攻撃が成功するかを計算してみましょう。
C 氏は，方法(ア)～(ウ)を組み合わせても検知されずに行われるパスワード攻撃が成功するまでの所要時間を，図4のように説明した。
図4 パスワード攻撃が成功するまでの所要時間の計算
A 主任：なるほど，暫定期間を延ばすと，検知を擦り抜けて不正ログインされる可能性が十分に現実的になるということですね。それでは，パスワード強度の変更とパスワード保存方法の変更が完了したことを条件として本格再開の時期を設定します。他に気をつけることはありますか。
C 氏：会員には②他のサイトで使っていないパスワードを設定してもらうよう注意喚起した方がいいですね。
A 主任：分かりました。
A 主任は，Z サイトの本格再開に向けたシステム改修計画をまとめ，B 部長とともに経営陣の承認を取り，3か月後に本格再開を果たした。
パスワードを固定した上で，約 70 万個の文字列を次々に利用者 ID として入力し，ログインを試行するという攻撃があったとのことでした。
C 氏の発言
方法(イ)では，今回の攻撃のように，同一 IP アドレスからのリバースブルートフォース攻撃を検知します。
図3 方法(イ)
システム運用部は，当該 IP アドレスからの接続をファイアウォールのルール設定で遮断する。
今回の攻撃は，パスワードを固定して利用者 ID を変えながら試行するリバースブルートフォース攻撃で，利用者 ID ごとの失敗回数は増えにくいため，方法(ア)のアカウントロックの数では検知できない。方法(イ)は，同一の IP アドレスから短時間に大量のログイン試行が行われることを検知して，その IP アドレスを FW で遮断する方法なので，しきい値を設定する対象は“単位時間当たりの同一IPアドレスからのログイン試行数”になる。
方法(イ)は同一 IP アドレスからの試行数を数えるので，その検知を避けるには，一つの IP アドレスの試行数がしきい値に届かないように，複数の IP アドレスに分散して攻撃すればよい。分散した攻撃は，IP アドレスごとの数ではなく，サイト全体のログイン失敗数に表れるので，方法(ウ)がそれを検知する。図4の(ⅲ)と本文の c は同じ字句で，“多数のIPアドレス”になる。
講評は，設問2の(2)と(3)は正答率が高かったとしている。
15字以内で，解答例は9字。“複数の IP アドレス”でもよいが，“同一 IP アドレス”と書くと方法(イ)で検知されてしまうので誤りである。
利用者はいくつものサイトで同じパスワードを使い回しがちで，利用者 ID にメールアドレスを使うサイトでは，ID も同じになる。ほかのサイトから流出した利用者 ID とパスワードの組合せをリストにして，このサイトのログインに試す攻撃（パスワードリスト攻撃）が成り立つ。このサイトでだけ使うパスワードにしてもらえば，他サイトの流出で被害を受けない。
Z サイトのパスワード強度を上げても，他サイトで流出したパスワードをそのまま使われる攻撃は防げない。だから，利用者への注意喚起が要る。講評は，設問4は正答率が高く，パスワードリスト攻撃への理解が進んでいるようだとしている。
45字以内で，解答例は36字。“他のサイトから流出した”“利用者 ID とパスワードの組合せ”“パスワード攻撃”を残す。“総当たり”や“辞書”では，下線②の注意喚起の理由にならない。
