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

共通の文章

Webサイトのセキュリティに関する次の記述を読んで,設問1こ6に答えよ。 A社は,従業員1.500名の中堅システム開発会社である。A社では,セキュリティ 品質の高いWebサイトを開発するために,表1に示すWebセキュリティ管理基準を 定めて運用している。 表1 Webセキュリティ管理基準(抜粋) 1・概要設計,基本設計,詳細設計それぞれの設計レビューにおいて, 要件レビューWebサイトに関するセキュリティ要件をレビューする。 2ツールによる|・Webサイトのリリースまでに実施する。 ソースコード|・期間は,3日間くらいが目安である。 に・開発環境の特性などが原因で実施できない場合,AS 3を行う。 ・ツールが検出した指摘事項について,開発担当者は,脆弱性かどう か,対策が必要かどうかを判断する。 ・セッション管理の脆弱性は,一部だけが対象である。 ・認可・アクセス制御の脆弱性は,対象外である。 3プロジェクト|・項番2が実施できない場合,Webサイトのリリースまでに実施する。 メンバによる|・期間は,10日間くらいが目安である。 ソースコード|・A社の指定した既知の脆弱なコードパターンを見つける。 レビュー・レビューでの指摘事項について,開発担当者は,脆弱性かどうか,対 策が必要かどうかを判断する。 ・セッション管理の脆弱性は,一部だけが対象である。 ・認可・アクセス制御の脆弱性は,対象外である。 4ツールによる|・Webサイトのリリースまでに実施する。 脆弱性診断・期間は,3日間くらいが目安である。 ・Webサイトをテスト環境で稼働させ,ツールでWebサイトに様々な HTTPリクエストを送り,その応答を評価する。 ・ツールが検出した指摘事項について,開発担当者は,脆弱性かどう か,対策が必要かどうかを判断する。 ・セッション管理の脆弱性は,一部だけが対象である。 ・認可・アクセス制御の脆弱性は,対象外である。 5|専門技術者に|・Webサイトのリリースまでに実施する。 よる脆弱性診|・期間は,10日間くらいが目安である。 断・専門会社"に委託する。 ・Webサイトをテスト環境で稼働させ,Webサイトに様々なHTTPリク エストを送り,その応答を評価する。 ・診断による指摘事項について,専門技術者と開発担当者は,対策が必 要かどうかを協議して判断する。 ・セッション管理の脆弱性は,対象である。 ・認可・アクセス制御の脆弱性は,対象である。 注!脆弱性診断サービスを提供しているD社に委託している。 —_2— [A社によるB社の子会社化]. B社は,従業員200名の新興のITサービス会社であり,BH SaaSを提供してい る。アジャイル開発の能力が高く,機能の追加や性能の改善を頻繁に行っている。B 社とA社とは協業関係にあったが,両社の経営陣は,双方の強みを生かせると判断 し,A社によるB社の子会社化について合意した。 B社のクラウド環境には,コーポレートサイト(以下,サイトBという),及びB 社が提供中の三つのSaaSそれぞれのWebサイト(以下,サイトX,サイトY,サイ トZという)がある。それらの概要を表2に示す。 表2 B社のWebサイトの概要 サイト名及びURL サイトB・B社に関する情報を発信している。IaaS上のWebサ https:/Awww.b-sha.co.jp/|・コンテンツマネジメントシステム(CMS)を導入|一バで構成され し,運用している。ている。 サイトX・会社又は組織向けのコミュニケーションサービス|IaaS上のWebサ https://x.b-sha.co.jp/であり,利用する会社間又は組織間で,情報共有|一バ及びデータ やチャットが行える。RAG At ・利用する会社又は組織は,B社の提携企業の新商|(以下,DBサー 品のモニターになると,“キャンペーン応募"を|バという)Che サイトXで行える。成されている。 サイトY・個人向けのブプログサイトであり,利用者が情報を https://y.b-sha.co.jp/発信できる。 ・“A社のニューストピック"を表示できる。 サイトZ・ソフトウェア開発企業向けのWebサービスであ https://z.b-sha.co.jp/る。利用者はグループを作ることができ,そのグ ループ内で,スケジュール,タスク,ソースコー ドなどのプロジェクト情報を共有できる。 ・外部のWebサイトと連携して,経費精算,出張申 q請などの業務手続を行う機能を提供予定である。 I注”DBサーバには,B社のシステム担当者と,それぞれのサイトのWebサーバとがアクセスで きる。各DBサーバには,レコードの更新や削除が簡単にできるメンテナンス用のWebインタ フェースがある。そのURLを次に示す。 ・サイトXのDBサーバ:https:/db-x.b-sha.co.jp/ ・サイトYのDBサーバ:https://db-y.b-sha.co.jp/ ・サイトZのDBサーバ:https://db-z.b-sha.co.jp/ 子会社化に当たって,B社のWebサイトのセキュリティ水準を確認することにな り,A社の品質管理部でセキュリティ技術を担当しているRさんが対応することにな DY Hp —3= [B社のWebサイトのセキュリティ水準の確認〕 Rさんは,サイトB,サイトXX,。サイトY及びサイトZに対する脆弱性診断をD tt に依頼した。診断の結果検出された脆弱性を表3に示す。 表3検出された脆弱性(抜粋) サイト名脆弱性名 ・クロスサイトスクリプティング(以下,XSSという)脆弱性 サイトX・XSS脆弱性 ・クロスサイトリクエストフォージェリ(以下,CSRFという)脆弱性 ・クリックジャッキング脆弱性 サイトY・XSS脆弱性 ・サーバサイドリクエストフォージェリ(以下,SSRFという)脆弱性 サイト2Z・XSS fest ・SSRF脆弱性 (4-4 k BO XSS脆弱性] D社は,サイトBに①診断用リクエストを送ることで,XSS脆弱性があることを確 認した。このリクエストは,ライブラリMを使ってプログラムCが処理する。ライ ブラリMのコードを図1に示す。 (省略) 1:out.println("<meta property=\"og:url\”content=\"https://"+serverNamet”/” +scriptNamet”?”+queryStringt”’\”>”); (省略) 注記serverNameには,リクエストのURLのホスト名が格納されている。scriptNameには, URLのパス名が格納されている。queryStringには,URLのクエリ文字列以降の値がURL デコードされて格納されている。 図1ライブラリMのコード ライブラリMは,SEOのためのライブラリである。 B社では,開発部のメンバそれぞれが,開発時に利用可能なライブラリを収集して いる。使用するライブラリは,マルウェアが含まれていない,既知の脆弱性が修正 された,安全性が確認できているライブラリを公開しているWebサイトから,ファ イルサーバにダウンロードし,利用している。ファイルサーバは,開発部のメンバ であればアクセス可能である。 ーー4 ws 今回使われていたライブラリMは,既知のXSS脆弱性の対策をしていないバージ ョンであった。その結果,.ライブラリMを使っているサイトB,サイトX,サイトY 及びサイトZにおいて,同じXSS脆弱性が検出された。 これを受けて,B社における②再発防止策について検討した。 [サイトXのCSRF脆弱性〕 サイトXは,セッションIDをJSESSIONIDというcookieに格納している。D社 lk,サイト双のキャンペーン応募ページでCSRF脆弱性を検出した。 CSRF脆弱性を確認した手順は,次のとおりであった。 (1)診断用利用者(以下,利用者Aという)の利用者IDでサイトXにログインし, キャンペーン応募ページで送信されるリクエストの内容をツールを使って確認し た。リクエストの内容を図2に示す。 POST/campaign HTTP/1.1 Host:x.b-sha.co.jp Cookie:JSESSIONID=KCRQ88ERH2G8MGT319E50SMOAJFDIVEM csrftoken=3f4aee446f680df6e0842d7179fcefd00fe5b232 注記1リクエストヘッダ部分は,設問に必要なものだけを記載している。 注記2 JSESSIONIDについて,SameSite属性は指定されていない。 注記3 csrftokenの値は,サーバが発行する推測困難な値であり,ほかの利用者の利用時には 別の値が発行される。 注記4リクエストを送るとトークンが破棄される可能性があるので,リクエストの内容は, ツールで確認しただけであり,実際にはサイトXに届いていない。 図2リクエストの内容 リクエストの内容を確認後,csrftokenをCSRF対策用のパラメタと考え,リクエ スト中のcsrftokenの値を削除して送信した場合と1文字変更して送信した場合を 試したところ,どちらもエラーになった。 (2)利用者Aとは別の診断用利用者(以下,利用者Bという)の利用者IDでサイト Xにログインし,キャンペーン応募ページで送信されるリクエスト中のcsrftoken の値に,図2のcsrftokenの値を設定して送信したところ,利用者Bとして処理さ れた。 ーー一:5= この結果から,csrftokenと[|a]ヌは[|b|とをひも付けるという対 策ができていないことが分かった。 【サイトXのクリックジャッキング脆弱性 サイトXでは,クリックジャッキングによって,利用者が気付かずに利用者情報の 公開範囲を変更させられてしまう脆弱性が検出された。攻撃者が図3の画面を用いて クリックジャッキングを行う場合を仮定してみる。このとき,クリックイベントは, 利用者から見て手前にある画面上で発生するものとする。 画面@画面が 利用者情報の公開範囲設定 〇制限なしここをクリックして ©同一組織内 次にここをクリック 図3攻撃者が用いる画面 攻撃者は,画面|<|を利用者から見て[|a|に|e reece わな サイトに公開し,サイトXの画面|{|を利用者から見て|g|に [|』|状態で重ねて表示する。この状態のサイトにアクセスした利用者は,意 図せず利用者情報の公開範囲を変更させられてしまう可能性がある。 クリックジャッキング脆弱性の対策には,レスポンスヘッダに|i|を含め る方法と|」|を含める方法がある。後者は標準化されている。 [サイトYのSSRF脆弱性] サイトYでは,例えば,図4のリクエストを受け取ると,A社のニューストピック を取得し,表示するようになっている。 (省略) 注記topicパラメタにA社のニューストピックのURLを指定している。 図4 A社のニューストピックを取得するリクエスト =6 mt この処理にSSRF脆弱性があった。D社は,③図4のリクエスト中の値を変更して サイトYに送り,サイトYのDBサーバのメンテナンス用のWebインタフェースに アクセスできることを確認した。 〔サイトZのSSRF脆弱性〕 サイトZでは,最近,新機能が開発された。新機能の一つである,旅行会社P社の 宿泊サイト(以下,P社宿泊サイトという)との連携機能でSSRF脆弱性が検出され た。その機能は,駅名を入力すると,その駅近辺のホテルの割引クーポンなどの “お得情報"”を表示できるというものである。利用者が,P社宿泊サイトに登録され ている駅名の一つ,“東京"を入力したときの流れを図5に,登録されていない和架空 の駅名である“abc?を入力したときの流れを図6に,D社の専門技術者V氏がSSRF 脆弱性を検出した手順を表4に示す。 利用者社宿泊サイト (1) し= (4) Be (3) 送信されるデータ (1)“東京”駅近辺の“お得情報"を取得するリクエストリ! GET/statio%E6%9D%B1%E4%BA%AC HTTP/1.1 Host:z.b-sha.co.jp (2)“Hm”駅近辺の“お得情報"を取得するリクエストリ!9 GET/station/%E6%9D%B1%E4%BA%AC?returnURL=https://z.b-sha.co.jp/error HTTP/1.1 Authorization:Basic(省略) q“HR”駅近辺の“お得情報" “東京”駅近辺の“お得情報"を含むページ 注記送信されるデータのリクエストヘッタ部分は,一部省略している。 注”リクエストURIには,“/station/AAAAA”の形式で,AA4A44Aに駅名をURLエンコード した値を指定する。 注2?returnURLには,登録されていない駅名が入力されたときに利用されるURLを指定する。サ イト2Zは,①のHostヘッダの値を,returnURL中のホスト名として指定する。 図5登録されている駅名である“RR”を入力したときの流れ ra ey on 利用者P社宿泊サイト に (3) I| (4) (5) (1)“abc”駅近辺の“お得情報"を取得するリクエスト GET/station/abe HTTP/1.1 Host:z.b-sha.co.jp (2)“abc駅近辺の“お得情報"を取得するリクエスト GET/station/abc?returnURL=https://z.b-sha.co.jp/error HTTP/1.1 Authorization:Basic(省略) (3)“abo”駅が登録されていなかったことを知らせるレスポンス HTTP/1.1 301 MOVED PERMANENTLY (4)|サーバ上にあるエラーページのテンプレート情報 GET/error HTTP/1.1 登録されていない駅名が入力されたことを示すエラーページ 注記送信されるデータのリクエストヘッダ部分は,一部省略している。 図6登録されていない駅名である“abo”を入力したときの流れ 表4 SSRF脆弱性を検出した手順 1 P社宿泊サイトに登録されていない駅名,例えば,“abo?を入力し,Hostヘッダの値を, V氏が用意したサイトのFQDNに変更して,サイトZにリクエストを送る。 2サイトZは,P社宿泊サイトに,“/station/fabe”をリクエストURIに指定したリクエスト を送る。 3|P社宿泊サイトは,Locationヘッダに| k|のURLを含めたレスポンスをサイト2 に返す。 サイト2は,受け取ったレスポンスを基に,|k|にリクエストを送る。 表4の手順によって,V氏は,Authorizationヘッダの値を受け取ることができた。 P社の協力の下,この値を用いることで,本来許可なしではアクセスできないP社宿 泊サイトや同じAuthorizationヘッダの値を利用するP社保有のサーバへのアクセス が可能になることを確認した。 D社からは,P社宿泊サイトからのレスポンスに含まれるURLが想定されたもの ーー8ーー かを調べて想定外の値の場合はそのURLにはアクセスしないようにするという, SSRF脆弱性への対策が提案された。加えて,④別の対策も実施することが望ましい とのことであった。 Rさんは,D社の脆弱性診断で検出された脆弱性について,B社の開発部のE課長 に報告した。その後,B社の開発部によって対策が実施され,D社による再度の脆弱 性診断で問題が修正されたことが確認された。 [開発プロセスの見直し〕 B社のWebサイトのセキュリティ水準について,Rさんは,開発プロセスの観点か らも調査を進めた。 B社では,顧客に機能の追加要望や性能の改善要望をヒアリングしながら,開発部 内で目標を設定し,アジャイル開発を行っている。また,社外の研修などでセキュ アプログラミングの知識を習得し,その知識を生かしてWebサイトを開発している。 B社の開発プロセスの概要を図7に示す。 DE 、新規 試作版1 oes試作版N TKリリース休止期間 注記1ライブラリの活用などで2週間周期での改良リリースを実現しているが,およそ20回に1回 は大規模な改修があり,改良リリース間隔を1か月とすることがある。 注記2改良フェーズにおいて,半年に1回,1か月の休止期間を設けている。その間,開発部のメン バは,長期休暇の取得,長期研修の受講,Webサイトの点検などを実施している。 図7 B社の開発プロセスの概要 ーー9ーー Rさんは,B社のWebサイトのセキュリティ水準を十分なものにするためには,A 社のようなWebセキュリティ管理基準をB社に導入する必要があると考えた。次は, B社の開発プロセスについてのRさんとE課長の会話である。 Rさん:B社でも表1のとおりに実施できますか。 E課長:開発フェーズにおいてはできると思います。しかし,改良リリースの周期 は2週間程度です。専門技術者による脆弱性診断には,その周期の大半を費 やしてしまうので,省略できないでしょうか。 Rさん:⑥ソースコードレビューやツールによる脆層性診断では発見できないが, 専門技術者による脆弱性診断では発見できる脆弱性が多くあります。専門 技術者による脆弱性診断を改良リリースにおいて毎回実施できない場合で も,当該診断が長期間行われないことを避けるために,⑥時期を決めて実 施することや,⑦開発プロセスを見直すことを検討してみてください。 E課長:分かりました。そのほかに,アジャイル開発に合った脆弱性対策はないで しょうか。 Rさん:Webサイトの実装に必要となる一般的な機能や定型コードを,ライブラリと してあらかじめ用意したフレームワークには,⑧脆弱性対策が組み込まれ ていて,それがデフォルトで有効になっているものもあるので,利用を検 討してみてください。 その後,B社は,セキュリティを考慮したアジャイル開発を行うことになった。 ー10一