※解答はIPAのサイトを引用しておりますが、解説は独自ですので参考程度にご覧ください
(1) 表1中の下線①における診断用リクエストの構成要素を記号で答えよ
答: ア
XSS(クロスサイトスクリプティング)とは利用者からの入力内容やHTTPヘッダの情報を処理し、Webページとして出力する処理に問題がある場合、攻撃者がその問題を利用してスクリプト等を埋め込み、不正な動作をさせる攻撃です。
このXSSのうちWebブラウザ上で動作するJavaScriptのコードを利用した手法を「DOM Based XSS」と呼びます。
まず、選択肢についてリクエストラインとリクエストボディがありますが、HTTPリクエストはリクエストライン、リクエストヘッダ、リクエストボディの3つの要素で構成されています。
リクエストラインは「GET https://www.b-sha.co.jp/ HTTP/1.1」のように「メソッド名 URI(URLまたはパス) プロトコルバージョン」の3要素で構成されています。
リクエストヘッダはWebサイトへアクセスする際の情報が記述されます。
例えば「Referer」、「User-Agent」、「Cookie」、「Authorization」などがあります。
リクエストボディは主にPOST通信時のパラメータが記述されます。
上記のようにリクエストヘッダは、スクリプトを実行することができません。
リクエストボディはPOST通信時のパラメータとなるためWebフォームを使用した場合に限られますのでサイトBへの脆弱性を診断するにはリクエストラインを利用することになります。
次に、選択肢に記載されているconfirmとは、Webページ上に確認ダイアログボックスを表示させるJavaScriptのメソッドです。
?マークの後ろはそのパラメータとなる文字列(確認メッセージの内容)になります。
これを利用し、GET confirm?”><img src=1 onerror=alert(1)><”のようなURLをWebブラウザで開いた場合、タグで囲われた部分がHTML内に展開され、対策がとられていない場合は画面にアラートメッセージが表示されます。
つまり攻撃者の用意したJavaScriptがユーザーのブラウザ上で動いてしまいます。
ちなみにこのコードの意味はimgタグのsrcが存在しないパスの場合、onerrorを実行し、画面にアラートを表示するという動作です。
「”>」と「<”」処理の前後のタグを無効化するためです。はイについては”が1つ足りません。よって解答はアになります。
「DOM Based XSS」の詳しい説明は下記をご参照ください。
IPA「DOM Based XSS」の脆弱性に関するレポート
(2) 下線②について再発防止対策を述べよ
答: 使用しているJavaScriptライブラリを新しいバージョンに更新する
「DOM Based XSS」の原因の一つに古いバージョンのJavaScriptライブラリに含まれる脆弱性が原因となるため、設問1(1)で脆弱性が診断された場合は「使用しているJavaScriptライブラリを新しいバージョンに更新する」という対策をとる必要があります。
答: [a]利用者
[b]セッションID
5ページの(2)の説明より、本来は利用者Aのcsrftokenの値を利用者Bでログインしてcsrftokenの値を設定して送信すると利用者Bとして処理されてしまったため、csrftokenの値と利用者を一意に識別できる情報を紐付ける対策をとる必要があります。
利用者を一意に識別できる情報が解答となります。
1つめは「利用者ID」です。文字通り利用者ごとに一意に割り当てられるIDです。
2つめは「セッションID」です。Webサイトにアクセスしたユーザーのセッションを一意に識別するために、WebサーバやWebアプリケーションによって付与される情報です。
(1) [c]～[h]に入れる字句を記号で答えよ
答: [c]イ.画面β [d]ア.手前 [e]ア.不可視 [f]ア.画面α
[g]イ.奥 [h]イ.可視
クリックジャッキングとは、Webサイト上に見えないあるいは偽装したリンクやボタンを設置し、利用者を視覚的にだましてクリックさせ意図しない操作をする方法です。
本来あるページの手前に利用者には見えないように施された透明なページ(サランラップのようなイメージ)を重ね、そこに設置されているボタンやURLを押させる方法になります。
解答ですが①画面αがもとのページ、画面βが攻撃者が用意したページです。
頭の中で画面αの上に画面βを重ね合わせてみましょう。
制限なしの○の位置と更新ボタンの位置に”ここ”がちょうど重なります。
利用者は、これらのボタンを押したつもりが実際は”ここ”という攻撃者が用意したページのボタンを押したことになり攻撃が成功します。
「[c]画面β」を利用者から見て「[d]手前」に「[e]不可視」状態で罠サイトに公開し、サイトXの「[f]画面α」を利用者から見て「[g]奥」に「[h]可視」状態で重ねて表示する。ということになります。
(2) [i]、[j]に入れる字句を記号で答えよ
答: [i] エ.X-Frame-Options
[j] イ.Content-Security-Policy
Content-Disposition…ブラウザの表示上でのファイルの扱いを指定するHTTPヘッダに付与する属性です。
ファイルをブラウザで表示する「Content-Disposition:inline」と、ダイアログを表示して別ファイルとしてダウンロードをさせる「Content-Disposition:attachment」があります。
ブラウザ表示ではなく、ダウンロードさせたい場合、Content-Disposition を活用します。
Content-Security-Policy…信頼できるコンテンツだけを参照するように制限をかけることができるHTTPレスポンスヘッダに付与する属性で、「W3C（Webの標準化団体）」よって標準化されています。
意図しないコンテンツを読ませることを防ぐ設定や、混在コンテンツ (HTTPSのページの中に、HTTPでリロードする部分があるコンテンツ) を除いて表示することが可能です。
これを使用することによって”クリックジャッキング”やXSSを防ぐことができます。
X-Content-Type-Options…送信するデータの種類や形式を強制指定するHTTPレスポンスヘッダに付与する属性です。
コンテンツにレスポンスヘッダとして「X-Content-Type-Options: nosniff」をつけることで、リクエストラインに含まれる文字を意図せずにHTMLとして解釈することがなくなります。
これにより<script src>などが指定された場合にJavaScriptとして扱わなくなるため”XSS”を防ぐことができます。
X-Frame-Options…”クリックジャッキング”から防御するためのレスポンスヘッダに付与する属性です。HTTPのレスポンスヘッダに「X-Frame-Options: DENY」と指定することで、ブラウザにおいて、frame要素やiframe要素(外部サイトを参照するコンテンツ表示)によるページ読み込みの制限ができます。
問題文に後者(=[j])は標準化されているとありますので解答[i]はエ.X-Frame-Options、[j]はイ.Content-Security-Policyとなります。
答: URL部分をhttps://db-y.b-sha.co.jp/に変更した
SSRF攻撃とは、外部から直接到達できないサーバ(非公開のサーバ)にアクセスしたり操作する攻撃手法です。
この手法の1つとして図4の「メソッド名 URL プロトコルバージョン」の順で構成されているリクエストラインのURL部分を変更して送信する手口があります。
具体的には”GET /news?topic=https://www.s-sha.co.jp/news/20220417.html HTTP/1.1″の場合は「/news?topic=https://www…」の部分を攻撃者の用意したサイトのURLへ書き換えて攻撃対象のサイトZに送信します。
このURL部分を書き換えることで直接アクセスできないサーバの領域内の情報にアクセスしたり不正操作を試みます。この問題では7ページの3行目に「サイトYのDBサーバのメンテナンス用のWebインターフェースにアクセスできることを確認した。」とあるので、解答はURL部分をhttps://db-y.b-sha.co.jp/(=サイトYのDBサーバのURL)に変更した、となります。
(1) 表4中の [k]に入れる適切な字句を答えよ
答: [k]V氏が用意したサイト
図6の番号(1)で利用者がサイトZに送信するリクエストデータのHostヘッダ値はz.b-sha.co.jpとなっています。
続いてサイトZからP社宿泊サイトに送信するリクエストデータは(2)”GET /station/abc?returnURL=https://z.b-sha.co.jp/news/error”となっています。図5の注2)に記載がありますが、登録されていない架空の駅名が指定されたときに返されるreturnURLのホスト名は(1)のHostに指定されたホスト名になりますので、表4の順序1でHostヘッダの値に使用されたV氏が用意したサイトのURLを含めたレスポンスがサイトZへ返されることになります。
よって[k]にはV氏が用意したサイトが入ります。
(2) 本文中の下線④について、別の対策とは何か。B社で実施することが望ましい対策を述べよ
答: returnURLのURL指定先をサイトZの固定ページにする。
SSRF攻撃の対策のポイントはWebサーバに攻撃者の用意したパラメータを含むリクエストを送信することができないようにすることです。8ページの最終行から書かれているとおり、1つの対処としてURLを含めた全てのパラメータをチェックして想定外の場合はアクセスしないようにする対策があります。
また別の対策として、架空の駅名が指定されたときに返されるreturnURLのURL指定先をサイトZの固定ページする対策があります。
(1) 下線⑤について該当する脆弱性を二つ挙げそれぞれ答えよ
答: セッション管理の脆弱性 と 認可・アクセス制御の脆弱性
表1の順番5の専門技術者による脆弱性診断の概要で「セッション管理の脆弱性および認可・アクセス制御の脆弱性は対象である」と記載されていますのでこの2つが解答となります。
(2) 下線⑥について、専門技術者による脆弱性診断が長期間行われないことを避けるにはどのような時期に実施すればよいか。
答: 改良フェーズの1か月の休止期間の時期
図7の注記2に記載のとおり、半年に1度、1ヶ月の休止期間があります。この期間は開発部メンバが休み、Webサイトの点検などが実施されています。
この期間に専門家技術者による脆弱性診断を行えば開発フェーズに影響をせず、かつ脆弱性診断が半年以上あくことがなくなります。よって解答は1ヶ月の休止期間になります。
(3) 下線⑦について、専門技術者による脆弱性診断が長期間行われないことを避けるには開発プロセスをどのように見直せばよいか
答: 大規模な改修テストの前に専門技術者による脆弱性診断の実施を行う
専門技術者による診断は表1の項番5より期間は10日間ほどかかると記載されており、2週間程度の改良リリース周期の日程のうち大半を費やすことになります。
そのため脆弱性診断の結果によっては対応が間に合わない可能性があります。
定期的に改良リリースの時間を長くすることで脆弱性の対処の日程を十分に確保でき、脆弱性診断が長期間行われないことを避けることが可能です。
また、弱性の対処を改良リリース自体を次回に持ち越す方法でも対処可能です。
(4) 本文中の下線⑧についてCSRF脆弱性の場合ではどのような処理を行う機能が考えられるか。その処理を具体的に述べよ
答: CSRF対策用トークンの発行、HTMLへの埋め込み、必要な紐付け及びこれを検証する
CSRF攻撃とは、Webサーバに本来拒否すべき他サイトからのリクエストを受信させ意図しない処理をさせる攻撃手法です。
対策に必要なのは、Webサイトを管理するWebサーバへ正規のWebページからのアクセスだけを許可することです。
そのためにはCSRF対策用トークンを利用します。CSRF対策用トークンとは、正規のWebページからアクセスが行われていることを証明するための値のことです。
Webサイトを管理するWebサーバは、アクセス要求があった場合は事前にCSRF対策用トークンを発行し、HTML形式のWebページのにこのCSRF対策用トークンを埋め込んだWebページを応答します。
そして、Webサイトへの通信時のリクエストにWebページに埋め込まれたCSRF対策用トークンを一緒に送出することで、Webサイト側でCSRF対策用トークンが正しい値かを検証し、Webサイトが発行した正しい値であった場合にだけアクセスを許可することが可能です。
このように「CSRF対策用トークンの発行、HTMLへの埋め込み、必要な紐付け及びこれを検証する」ことで、CSRF攻撃を防ぐことができます。
(1) 本文中の[a]に入れる適切な字句を答えよ
答: [a] キャッシュ
[a]にはキャッシュが入ります。P14のF氏の会話の中に「動画を配信要求されたとき、要求された動画を保持していれば代理応答し」とあります。X社動画サーバが配信しているコンテンツ(動画)の複製を保存し、利用者から要求があった場合に、X社動画サーバに代わってコンテンツ(動画)を配信するサーバをキャッシュサーバといいます。キャッシュ(cache)は本来、英語の名詞で「貯蔵物」という意味があります。
(2) 本文中の[b]に入れる適切な字句を英字で答えよ
答: [b] DDoS
[b]にはDDoSがはいります。悪意を持ってサーバに大量のデータを送りつけるDos攻撃を、複数のIPアドレスから大量に行うことをDDoS攻撃といいます。文中にもあるようにキャッシュサーバを設けたことによりキャッシュサーバとX社動画サーバでアクセスによる負荷が分散されますのでDDoS攻撃への耐性も向上します。
(3) 図4中、図5中及び本文中の[c]に入れる適切な字句を英字で答えよ
答: [c] Host
Hostヘッダとは端末からサーバへ送信されるHTTPリクエストヘッダに含まれる情報の1つで、アクセス先のFQDNが格納されます。図4の(1)のとおり、会員は端末から動画配信サーバに動画を要求するHTTPリクエストを送信しますので、このHTTPリクエストのHostヘッダには、動画配信サーバのFQDN(X-FQDN)が指定されます。
ちなみに図4の(4)の内容は、端末に最も近いキャッシュサーバが要求された動画のキャッシュを保持していなかったので、端末はおおもとの動画配信サーバにHTTPリクエストを送信するという動作になります。
※FQDNとはホストとドメインを省略せずにつなげた記述形式のことです。https://www.dxnote.net:443/pre/index.htmlの場合、FQDNはwww.dxnote.net(ホストはwww、ドメインはdxnote.net)になります。
(4) 下線①について、Y-CDN-U-FQDNを名前解決したIPアドレスを宛先とする通信をFWで拒否した場合に閲覧できなくなるWebサイトの範囲を具体的に述べよ
答: Y-CDN-U-FQDNを名前解決したIPアドレスと同じIPアドレスをもつWebサイト
図5の(1)で、「あるCDN(CDN-U)がX社内から頻繁にアクセスする他社のWebサイトの複数で利用されている。それらのWebサイトのうちの1つがY社のWebサイト(Y-CDN-U-FQDN)である。」という説明が記載されています。
DNSサーバでは複数のホスト名に同一のIPアドレスを対応させることが可能です。(1つのホスト名に複数のIPアドレスを対応させることも可能)
Y社のWebサイト以外にも複数のWebサイトが同一のIPアドレスに対応づけられている場合、Y-CDN-U-FQDNを名前解決したIPアドレスを宛先とする通信をFWで拒否すると同じIPアドレスをもつWebサイトについても通信が拒否されることになってしまいます。
(5) [d]に入れる字句を答えよ
答: [d]TLSの接続先サーバ名
[d]には”TLSの接続先サーバ名”が入ります。
このときのX-CDN-M-FQDNで名前解決したIPアドレスのサーバになりますので問題となっている部分では、下線①のとおりFWで宛先IPアドレスをみて通信を拒否した場合だと同じIPアドレスを持つ意図しないWebサイト宛の通信も遮断されてしまうことになります。同じIPアドレスになり、どちらのサイトに接続すべきか分かりませんので、HTTP/1.1 というバージョンでひとつのサーバ上で複数のサイトを識別できるようにHostヘッダが登場しました。
GET /top.html HTTP1.1
Host https://dxnote2.net
このような形式で、HostヘッダはHTTPリクエストを送信する宛先のFQDNがセットされ宛先のWEBサイトを一意に特定できます。
続いて、図4の(3)の文中で「HTTPS通信を行うためTLSの接続を確立する」とあるように、X-CDN-M-FQDNで名前解決したIPアドレスのサーバとTLSの接続を確立するため、Hostヘッダの値と「TLS接続先サーバ」が一致していれば、接続したいWebを特定できますので、[d]には”TLSの接続先サーバ名”が入ります。通信を遮断する図3の(1)によりX社動画サーバ用に割り当てられたサーバになります。
(1) 本文中の下線②について認証サーバ側では検知することができない理由を述べよ
答: STは認証サーバに送られないから
TGTはチケットの発行を認可するためのチケットです。TGTは図7の処理2に記載されているように認証サーバ側で「TGTを復号して検証し、問題なければSTを発行する」とありますので、もし偽装されていた場合は検証に失敗します。一方でST(Service Ticket)は、認証サーバがアクセスを許可する対象のサーバごとに発行するチケットのことで、今回は認証サーバがXPCに発行します。そのためSTは認証サーバ自体に送られないため認証サーバで検証せず、偽装されていた場合に検知することができません。
(2) 下線③について対策にならない理由を述べよ
答: 総当たり攻撃はオフラインで行われ、ログインに失敗しないから
STはXPCに発行するチケットで、図7の「STを保存」とあるようにアクセスを許可する対象の端末やサーバに自体保存されます。
攻撃者は、奪取したSTを用意した端末やサーバに保存し、ローカル環境下(オフライン)でSTに対してログイン試行しますので、失敗回数などによるアカウントロックなどの制御ができず、総当たり攻撃で無制限にログイン試行が可能となってしまいます。
(1) 表2中の[e]に入れる適切な字句を記号で答えよ
答: [e] ウ.クエリ文字列
図8(1)でXPCからサービス要求を受けたSaaSは、SMAL Requestを生成します。SSO(Single Sign-On)による認証では、SMAL RequestメッセージをHTTP GETリクエストのURLクエリ文字列として直接渡します。
(2) 表2中の[f]に入れる適切な字句を記号で答えよ
答: [f] ア.IDaaS
IDaaSとは「Identity as a Service」の略であり、クラウド経由でID認証ならびIDパスワード管理、SSO、アクセス制御などを提供する管理サービスのことです。
表2の処理3の説明にあるとおり、IDaaSはデジタル署名を含めたSMAL Responseを生成しますので、SaaSではSMAL Responseに含まれたデジタル署名が「IDaaS」のものであることを検証します。
(3) 表2中の[g]に入れる適切な字句を答えよ
答: [g] 偽造
[g]には「偽造」が入ります。デジタル署名の検証は、実際に受け取ったハッシュ値と受け取ったデータから計算したハッシュ値を比較する作業のことです。
もし2つのハッシュ値が一致しない場合は署名したときとデータが異なる、つまり「偽造」されていると判断でき、一致していればデータが偽造(改ざん)されていないことになります。
(4) 本文中の[h]～[j]に入れる適切な字句を答えよ
答: [h] 1 [i] 3 [j] 4
[h]には1が入ります。SSOではURLに設定されたパラメータで認証を行いますので、処理1で生成するリダイレクト先のURLを事前にSaaS(認証要求する側)とIDaaS(認証する側)で共有しておく必要があります。
また、デジタル証明書も共有する必要があり、1つ目は処理3で、IDaaS(認証する側)がSaaS(認証要求する側)を検証するための証明書、2つ目は処理4でSaaS(認証要求する側)がIDaaS(認証する側)を検証する証明書になります。よって[i]には3が入り[j]には4が入ります(順不同)。
(1) 本文中の[k]～[m]に入れる適切な字句を記号で答えよ
答: [k] ウ.Sサービス [l] イ.IDaaS-D [m] ア.GrW-G
図9については、図8の流れをベースに考えます。利用者の端末はSaaSに接続します。表3よりSaaSはSサービスを指すので、[k]はウ.Sサービスになります。
続いて、サービス要求を受けたSaaS(Sサービス)は利用者端末がGrW-G(グループウェアサーバ)へのアクセスの認可を要求します。
認証する側はIDaaSになりますので、[l]はイ.IDaaS-Dになります。
IDaaSによる認証が成功した場合がIDaaSが認可トークンを発行し、そのトークンを持つことでGrW-Gへ利用者の端末はアクセスが可能となります。よって[m]はア.GrW-Gになります。
(2) 図9中の[n]に入れる適切な流れを記号で答えよ
答: [n] エ
利用者は端末を操作し、スマホアプリやWebブラウザを開いてSサービスに接続するため、実際にGrW-G(グループウェアサーバ)からの情報を取得するのは、全てSaaS(Sサービス)が起点となります。よって、SサービスからGrW-G(グループウェアサーバ)へスケジュール情報を要求し、スケジュール情報を受け取るので、解答はエになります。
(3) 本文中の[o]、[p]に入れる適切な字句を図9中の(1)～(10)から選び番号で答えよ
答: [o] (2) [p] (6)
OAuth2.0におけるCSRF攻撃とは、攻撃者がGrW-Gに不正アクセスするための認可コードを利用者に送付し、利用者に攻撃者の権限で処理をさせる攻撃となります。
このCSRF攻撃の対策ですが、Sサービスは利用者の端末へ、認可コードとあわせてstateパラメタ(セッションに紐づくランダムな文字列)も送付します。
そして、認可同意をしたあとに利用者の端末からSサービスへ送り返えすときに認可コードとstateパラメタが送付時と一致していれば、Sサービスが利用者端末へ発行したと判断できます。
解答[o]は、stateパラメタを付与して送付するタイミングは、Sサービスが利用者の端末からサービス要求を受けてリダイレクトURIを返却するタイミングである(2)になります。
[p]は、利用者端末がSサービスへ認可コードをリダイレクトした際タイミングになりますので、(6)になります。
(4) [q]に入れる適切な字句を記号で答えよ
答: [q] ウ.PKCE
ア.ASLR(Address space layoutrandomization)とは、メモリ領域に格納するデータのアドレスをランダム化することです。主にバッファーオーバーフロー攻撃の対策に利用します。
イ.EIAM(Enterprise Identity AccessManagement)とは、ユーザIDの一元的な管理や認証を行う顧客向けに特化したサービスのことです。
ウ.PKCE(Proof Key for Code Exchange)とは、認可コードの搾取の対策を目的とし、RFC7636で定義されているOAuth2.0拡張仕様です。トークン要求時で認可コードと「code_challenge」というハッシュ値をパラメータに付加して送り、認可サーバ側で値の検証を行うことで、認可コードを搾取して攻撃者のアカウントで処理させるようなCSRF攻撃を防ぎます。
エ.SCIM(System for Cross-domain IdentityManagement)とは、複数のドメイン間でユーザIDのやり取りを自動化するなどID管理を簡易に実現するための標準規格です。
上記より解答はウ.PKCEとなります。
(1) 図10中の[r]～[t]に入れる字句を記号で答えよ
答: [r] オ.X社動画サーバ [s] エ.T社投稿サイトの認証サーバ [t] ウ.T社投稿サイトの投稿サーバ
まず[s]についてです、22ページの[企画チームからの要望]の文中で、「T社投稿サイトとX社動画サーバを連携させ、T社投稿サイトの認証サーバを用いた認証機能、T社投稿サイトの投稿サーバへの自動投稿機能を追加したい」とあります。図10で利用者端末から(3)認証要求を行っている先である[s]は認証機能を持つサーバのため[s]には「エ.T社投稿サイトの認証サーバ」が入ります。
次に [r]と[t]についてです。22ページの[企画チームからの要望]の文中で、「T社投稿サイトにログインした場合、X社動画サーバ似動画を投稿すると”動画の概要”がT社投稿サイトに自動で投稿される」とあります。そのため図10でAPIを使った”動画の概要”の投稿はX社動画サーバからT社投稿サイトの投稿サーバになりますので、[r]には「オ.X社動画サーバ」、[t]には「ウ.T社投稿サイトの投稿サーバ」が入ります。
(2) [u]に入れる適切な通信を図10中の(1)～(8)から選び番号で答えよ
答: [u] (8)
OAuth 2.0 はアクセストークンを発行するための処理フローを定めていますが、それを流用しIDトークンを発行できるようにしたのが OpenID Connectになります。
そのため、OAuth 2.0のアクセストークンを発行するタイミングであるトークン応答のときにIDトークンも発行します。解答は(8)になります。
(3) [v]に入れる適切な字句を解答群から選び記号で答えよ
答: [v] イ.base64url
JSON Web Token (JWT)形式ではヘッダ、ペイロード、署名はすべて Base64 URL でエンコードされています。
(4) 本文中の[w]、[x]に入れる適切な字句をそれぞれ答えよ
答: [w] 認証要求 [x] IDトークン
T社投稿サイトの認証サーバでX社動画サーバが(2)のリダイレクト時にクエリパラメーターとしてnonce値(一時的なランダムな値)を付与します。そして、(3)認証要求で利用者の端末から、T社投稿サイトの認証サーバに、IDトークンの中にnonce値を含めて要求します、(3)認証要求でIDトークンを受け取ったT社投稿サイトの認証サーバは、IDトークンの中に含まれているnonceの値とのに自身で保存されているnonceの値とを比較し、一致した場合にこのIDトークンを受け入れます。よって [w]には認証要求、[x]にはIDトークンが入ります。