問3 Webセキュリティ

テーマ：Webセキュリティ

左右2分割表示：左側の問題文をスクロールしながら右側の設問に解答できます

長文事例本文

図表クリックで拡大

D社は，従業員1,000名の小売業である。自社のホームページやECサイトなどのWebサイトについては，Webアプリケーションプログラム（以下，Webアプリという）に対する診断（以下，Webアプリ診断という）を専門会社のZ社に委託して実施している。Webアプリ診断は，Webサイトのリリース前だけではなく，リリース後も定期的に実施している。Z社のWebアプリ診断は，脆弱性診断ツールによるスキャンだけではなく，手動による高度な分析も行う。

〔新たなWebサイトの構築〕

D社では，新たにECサイトX（以下，サイトXという）と商品企画サイトY（以下，サイトYという）をW社が提供するクラウドサービス（以下，クラウドWという）上に構築することになった。
サイトXでは，D社が取り扱う商品をインターネットを介して会員に販売する予定である。取引は毎月10,000件ほどを見込んでいる。サイトYでは，サイトXで販売する新商品の企画・開発を顧客参加型で行う。サイトXとサイトYは，いずれもWebサーバとデータベースサーバ（以下，DBサーバという）で構成する。WebサーバについてはクラウドWの仮想Webサーバサービスを利用し，DBサーバについてはクラウドWのリレーショナルデータベースサービスを利用する。サイトXとサイトYはいずれも，コンテンツマネジメントシステム（以下，CMSという）を使って構築される。サイトXとサイトYにはいずれも，Webアプリ，HTMLによる静的コンテンツ，DBサーバに格納したデータを使った動的コンテンツなどを用意する。
 D社は，V大学と新商品開発の共同研究を行っている。新商品開発の共同研究では，V大学が運用する情報交換サイト（以下，サイトPという）を利用している。サイトYは，サイトPで取り扱っている情報などを表示する。
D社は，Webサイト構築に関連するデータやドキュメントの保存場所として，クラウドWのストレージサービス（以下，ストレージWという）を利用する。
D社は，サイトX及びサイトYの設計書を作成した。設計書のうち，サイトX，サイトY及びサイトPのネットワーク構成を図1に，サーバやサービスの説明を図2に示す。

 拡大
図1 サイトX，サイトY及びサイトPのネットワーク構成


 拡大
図2 サーバやサービスの説明


〔サイトX〕

サイトXには，会員用の利用者アカウントとD社管理者用の利用者アカウントがある。サイトXのログインセッション管理は，cookieパラメータのSESSIONIDで行う。SESSIONIDには，値とSecure属性だけがセットされる。なお，サーバ側のセッションの有効期間は24時間である。設計書のうち，サイトXの機能一覧を表1に示す。

 拡大
表1 サイトXの機能一覧（抜粋）


サイト管理機能は，D社の内部ネットワーク以外からも利用する可能性があり，サイトXでは，接続元の制限は行わない。
サイトXとサイトYの構築は順調に進み，D社はリリース前のWebアプリ診断をZ社に委託した。Z社は，サイトXとサイトYそれぞれに対してWebアプリ診断を実施した。

〔サイトXに対するWebアプリ診断〕

サイトXに対するWebアプリ診断では，次の三つの脆弱性が検出された。
・クロスサイトスクリプティング（以下，XSSという）
・クロスサイトリクエストフォージェリ（以下，CSRFという）
・認可制御の不備

〔XSSについて〕

Z社がXSSを検出した経緯は，次のとおりであった。
(1) 問合せ機能で，脆弱性診断ツールによるリクエストとレスポンスを確認した。このときのリクエストとレスポンスは，図3のとおりであった。

 拡大
図3 問合せ機能のリクエストとレスポンス


(2) 図3中のレスポンスボディには，問合せ機能で入力した値は出力されていない。しかし，Z社は，①設計書を調査した上で手動による分析を行い，図3中のリクエスト内のスクリプトが別の機能の画面に出力されることを確認した。
Z社は，②攻撃者がこのXSSを悪用してサイトX内の全会員の利用者情報を取得する可能性があると説明した。

〔CSRFについて〕

Z社がCSRFを検出した経緯は，次のとおりであった。
(1) 会員機能（編集）において，図4に示すリクエストを送ってその応答を確認した。リクエストは正常に処理された。

 拡大
図4 会員機能（編集）のリクエスト


(2) リクエスト内のメッセージボディの一部を変更して送り，その応答を確認した。リクエスト内のメッセージボディと応答は表2のとおりであった。

 拡大
表2 リクエスト内のメッセージボディと応答


(3) Z社は，手順1，2の応答が“エラー”であることから一定のCSRF対策ができているが，手順3の応答が“正常に処理”であることから③利用者に被害を与える可能性があると判断した。
Z社は，対策には二つの方法があることを説明した。
・csrf_tokenの処理の修正
・cookieへのSameSite属性の追加
サイトXの構成次第では，SameSite属性をcookieに付与することも有効な対策となり得る。SameSite属性は，Strict，Lax，Noneの三つの値のうちのいずれかを取る。サイトXにログインした利用者のWebブラウザにおいて，サイトX内で遷移する場合と外部WebサイトからサイトXに遷移する場合では，SameSite属性の値によってサイトXのcookie送信の有無が表3のように異なる。

 拡大
表3 SameSite 属性の値の違いによる cookie 送信の有無


〔認可制御の不備について〕

Z社が認可制御の不備を検出した経緯は，次のとおりであった。
(1) Z社は，利用者α，利用者βという二つの利用者アカウントを用いて，注文履歴を閲覧した際のリクエストを確認した。注文履歴を閲覧した際のリクエストを図5及び図6に示す。

 拡大
図5 利用者αで注文履歴を閲覧した際のリクエスト


 拡大
図6 利用者βで注文履歴を閲覧した際のリクエスト


(2) 図5のリクエストのパラメータorder-codeの値を図6中の値に改変してリクエストを送った。
(3) 利用者αが，本来は閲覧できないはずの利用者βの注文履歴を閲覧できるという攻撃が成功することを確認した。
(4) さらに，ある利用者がほかの利用者が注文した際のorder-codeを知らなくても，④ある攻撃手法を用いれば攻撃が成功することを確認した。
Z社は，⑤サイトXのWebアプリに追加すべき処理を説明した。

〔サイトYに対するWebアプリ診断〕

サイトYに対するWebアプリ診断では，次の脆弱性が検出された。
・サーバサイドリクエストフォージェリ（以下，SSRFという）

〔SSRFについて〕

Z社がSSRFを検出した経緯は，次のとおりであった。
(1) サイトPの新着情報を取得する際に，利用者のWebブラウザがWebサーバYに送るリクエストを確認したところ，図7のとおりであった。

 拡大
図7 利用者の Web ブラウザが Web サーバ Y に送るリクエスト


(2) ⑥図7のリクエストのパラメータの値をWebサーバYのCMSの管理ログイン画面のURLに変更することで，その画面にアクセスできるが，ログインはできないことを確認した。
(3) ⑦図7のリクエストのパラメータの値を別のURLに変更するという方法（以下，方法Fという）でSSRFを悪用して，クレデンシャル情報を取得し，ストレージWから情報を盗み出すことができることを確認した。
(4) IMDSにアクセスする方式を方式1から方式2に変更すると，方法Fではクレデンシャル情報を取得できないので，ストレージWから情報を盗み出すことができない。しかし，図7のリクエストのパラメータの値を変更することで，WebサーバYから送られるリクエストに任意のメソッドの指定及び任意のヘッダの追加ができる方法（以下，方法Gという）がある。方法Gを用いれば，方式2に変更しても，⑧クレデンシャル情報を取得し，ストレージWから情報を盗み出すことができることを確認した。
Z社は，クラウドW上のネットワークでのアクセス制御の設定，及び⑨サイトYのWebアプリに追加すべき処理を提案した。
リリース前の脆弱性診断で検出された脆弱性の対策が全て完了し，サイトXとサイトYは稼働を開始した。