情報処理安全確保支援士 2022年 春期 午後2 問01

　 　A社は、従業員1,500名の中堅システム開発会社である。A社では、セキュリティ品質の高いWebサイトを開発するために、表1に示すWebセキュリティ管理基準を定めて運用している。

〔A社によるB社の子会社化〕 　B社は、従業員200名の新興のITサービス会社であり、各種SaaSを提供している。アジャイル開発の能力が高く、機能の追加や性能の改善を頻繁に行っている。B社とA社とは協業関係にあったが、両社の経営陣は、双方の強みを生かせると判断し、A社によるB社の子会社化について合意した。 　B社のクラウド環境には、コーポレートサイト（以下、サイトBという）、及びB社が提供中の三つのSaaSそれぞれのWebサイト（以下、サイトX、サイトY、サイトZという）がある。それらの概要を表2に示す。

　子会社化に当たって、B社のWebサイトのセキュリティ水準を確認することになり、A社の品質管理部でセキュリティ技術を担当しているRさんが対応することになった。 　 〔B社のWebサイトのセキュリティ水準の確認〕 　Rさんは、サイトB、サイトX、サイトY及びサイトZに対する脆弱性診断をD社に依頼した。診断の結果、検出された脆弱性を表3に示す。

〔サイトBのXSS脆弱性〕 　D社は、サイトBに①診断用リクエストを送ることで、XSS脆弱性があることを確認した。このリクエストは、ライブラリMを使ってプログラムCが処理する。ライブラリMのコードを図1に示す。 　

　ライブラリMは、SEOのためのライブラリである。 　B社では、開発部のメンバそれぞれが、開発時に利用可能なライブラリを収集している。使用するライブラリは、マルウェアが含まれていない、既知の脆弱性が修正された、安全性が確認できているライブラリを公開しているWebサイトから、ファイルサーバにダウンロードし、利用している。ファイルサーバは、開発部のメンバであればアクセス可能である。 　今回使われていたライブラリMは、既知のXSS脆弱性の対策をしていないバージョンであった。その結果、ライブラリMを使っているサイトB、サイトX、サイトY及びサイトZにおいて、同じXSS脆弱性が検出された。 　これを受けて、B社における②再発防止策について検討した。 　 〔サイトXのCSRF脆弱性〕 　サイトXは、セッションIDをJSESSIONIDというcookieに格納している。D社は、サイトXのキャンペーン応募ページでCSRF脆弱性を検出した。 　CSRF脆弱性を確認した手順は、次のとおりであった。 　 　（1）診断用利用者（以下、利用者Aという）の利用者IDでサイトXにログインし、キャンペーン応募ページで送信されるリクエストの内容をツールを使って確認した。リクエストの内容を図2に示す。

　リクエストの内容を確認後、cstftokenをCSRF対策用のパラメタと考え、リクエスト中のcsrftokenの値を削除して送信した場合と1文字変更して送信した場合を試したところ、どちらもエラーになった。 　（2）利用者Aとは別の診断用利用者（以下、利用者Bという）の利用者IDでサイトXにログインし、キャンペーン応募ページで送されるリクエスト中のcsrftokenの値に、図2のcsrftokenの値を設定して送信したところ、利用者Bとして処理された。

　この結果から、csrftoken とa又はbとをひも付けるという対策ができていないことが分かった。 　 〔サイトXのクリックジャッキング脆弱性〕 　サイトXでは、クリックジャッキングによって、利用者が気付かずに利用者情報の公開範囲を変更させられてしまう脆弱性が検出された。攻撃者が図3の画面を用いてクリックジャッキングを行う場合を仮定してみる。このとき、クリックイベントは、利用者から見て手前にある画面上で発生するものとする。

　攻撃者は、画面cを利用者から見てdにe状態で罠サイトに公開し、サイトXの画面fを利用者から見てgにh状態で重ねて表示する。この状態のサイトにアクセスした利用者は、意図せず利用者情報の公開範囲を変更させられてしまう可能性がある。 　クリックジャッキング脆弱性の対策には、レスポンスヘッダにiを含める方法とjを含める方法がある。後者は標準化されている。 　 〔サイトYのSSRF脆弱性〕 　サイトYでは、例えば、図4のリクエストを受け取ると、A社のニューストピックを取得し、表示するようになっている。

　この処理にSSRF脆弱性があった。D社は、③図4のリクエスト中の値を変更してサイト Y に送り、サイト Y の DB サーバのメンテナンス用の Web インタフェースにアクセスできることを確認した。 　 〔サイトZのSSRF脆弱性〕 　サイトZでは、最近、新機能が開発された。新機能の一つである、旅行会社 P 社の宿泊サイト（以下、P 社宿泊サイトという）との連携機能でSSRF脆弱性が検出された。その機能は、駅名を入力すると、その駅近辺のホテルの割引クーポンなどの“お得情報”を表示できるというものである。利用者が、P 社宿泊サイトに登録されている駅名の一つ、“東京”を入力したときの流れを図5に、登録されていない架空の駅名である“abc”を入力したときの流れを図6に、D社の専門技術者 V氏がSSRF脆弱性を検出した手順を表4に示す。

　表4の手順によって、V氏は、Authorizationヘッダの値を受け取ることができた。P社の協力の下、この値を用いることで、本来許可なしではアクセスできないP社宿泊サイトや同じAuthorizationヘッダの値を利用するP社保有のサーバへのアクセスが可能になることを確認した。 　D社からは、P社宿泊サイトからのレスポンスに含まれるURLが想定されたものかを調べて想定外の値の場合はそのURLにはアクセスしないようにするという、SSRF脆弱性への対策が提案された。加えて、④別の対策も実施することが望ましいとのことであった。 　 　Rさんは、D社の脆弱性診断で検出された脆弱性について、B社の開発部のE課長に報告した。その後、B社の開発部によって対策が実施され、D社による再度の脆弱性診断で問題が修正されたことが確認された。 　 〔開発プロセスの見直し〕 　B社のWebサイトのセキュリティ水準について、Rさんは、開発プロセスの観点からも調査を進めた。 　B社では、顧客に機能の追加要望や性能の改善要望をヒアリングしながら、開発部内で目標を設定し、アジャイル開発を行っている。また、社外の研修などでセキュアプログラミングの知識を習得し、その知識を生かしてWebサイトを開発している。 　B社の開発プロセスの概要を図7に示す。

　Rさんは、B社のWebサイトのセキュリティ水準を十分なものにするためには、A社のようなWebセキュリティ管理基準をB社に導入する必要があると考えた。次は、B社の開発プロセスについてのRさんとE課長の会話である。 　 　Rさん：B社でも表1のとおりに実施できますか。 　E課長：開発フェーズにおいてはできると思います。しかし、改良リリースの周期は2週間程度です。専門技術者による脆弱性診断には、その周期の大半を費やしてしまうので、省略できないでしょうか。 　Rさん：⑤ソースコードレビューやツールによる脆弱性診断では発見できないが、専門技術者による脆弱性診断では発見できる脆弱性が多くあります。専門技術者による脆弱性診断を改良リリースにおいて毎回実施できない場合でも、当該診断が長期間行われないことを避けるために、⑥時期を決めて実施することや、⑦開発プロセスを見直すことを検討してみてください。 　E課長：分かりました。そのほかに、アジャイル開発に合った脆弱性対策はないでしょうか。 　Rさん：Webサイトの実装に必要となる一般的な機能や定型コードを、ライブラリとしてあらかじめ用意したフレームワークには、⑧脆弱性対策が組み込まれていて、それがデフォルトで有効になっているものもあるので、利用を検討してみてください。 　 　その後、B社は、セキュリティを考慮したアジャイル開発を行うことになった。