令和4年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1｜子会社のWebサービスから次々と脆弱性——情報処理安全確保支援士で学ぶアジャイル開発とWebアプリのセキュリティ事例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和4年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1
• 主なテーマ: XSS、CSRF、クリックジャッキング、SSRF、ライブラリ調達管理、アジャイル開発に脆弱性診断をどう組み込むか

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

会社を買収する。新しいサービスを高速で世に出す。事業のスピードを上げるための、ごく前向きな経営判断です。ところが、その買収した子会社のWebサービスを調べてみたら、サイトごとに種類の違うWebアプリの脆弱性が次々と見つかった——この情報処理安全確保支援士試験のセキュリティインシデント事例は、まさにその「速さの裏側に残されたリスク」を正面から扱っています。

登場するのは、コーポレートサイトと3つのSaaS。そして検出された脆弱性は、XSS（クロスサイトスクリプティング）、CSRF（クロスサイトリクエストフォージェリ）、クリックジャッキング、SSRF（サーバサイドリクエストフォージェリ）と、Webアプリのセキュリティでも代表的な顔ぶれが勢ぞろいしています。一つひとつは試験でも実務でも頻出のテーマですが、この事例の本当の見どころは、それらをなぜ事前に防げなかったのか、そしてアジャイル開発（短い周期で少しずつ作り直しを繰り返す開発手法）という速さを重んじる現場に、どうやってセキュリティ診断を組み込むのか、という点にあります。

この記事を読むと、4種類のWebアプリ脆弱性が「どういう仕組みで成立し」「何で防ぐのか」が一通り整理でき、さらに「速さとセキュリティをどう両立させるか」という、現場でも経営でも避けて通れない問いに対する考え方の軸が手に入ります。受験対策としては午後試験の頻出テーマを横断的に押さえられますし、システム開発を発注・運営する立場の方には、子会社管理やライブラリ調達のルール作りの教材になります。

インシデントの概要

舞台は、従業員1,500名の中堅システム開発会社A社です。A社はWebサイトを安全に開発するための社内の決まりとして「Webセキュリティ管理基準」を定め、運用していました。この基準には5つの管理策が並んでいます。設計段階のセキュリティ要件レビュー、ツールによるソースコードレビュー（プログラムの中身を機械的に点検すること）、プロジェクトメンバ自身によるソースコードレビュー、ツールによる脆弱性診断（実際にWebサイトへ通信を送って弱点を探すこと）、そして専門技術者による脆弱性診断です。

ここで一つ、後の伏線になる重要な点があります。前半の管理策——ツールやメンバによるレビュー、ツールによる脆弱性診断——では、セッション管理（ログイン状態を維持する仕組み）の脆弱性は一部しか対象にならず、認可・アクセス制御（その人が本当にその操作をしてよいかを確かめる仕組み）の脆弱性は対象外でした。これらをきちんと検査できるのは、最後の「専門技術者による脆弱性診断」だけだったのです。A社はこの専門技術者の診断を、外部のセキュリティ専門会社D社に委託していました。

そのA社が、新興のITサービス会社B社を子会社化します。従業員200名のB社はアジャイル開発を得意とし、各種のSaaS（インターネット越しに使うソフトウェアサービス）を提供していました。B社のクラウド環境には、自社の情報発信を行うコーポレートサイト「サイトB」と、3つのSaaSのWebサイト「サイトX」「サイトY」「サイトZ」が動いています。サイトXは会社や組織向けの情報共有・チャットサービス、サイトYは個人向けのブログサイト、サイトZはソフトウェア開発企業向けにスケジュールやソースコードを共有するサービスでした。

A社の品質管理部でセキュリティ技術を担当するRさんが、この子会社のWebサイトの安全性を確かめる役を引き受けます。RさんはサイトB・X・Y・Zの脆弱性診断をD社に依頼しました。そして返ってきた診断結果が、関係者の表情を曇らせることになります。

何が起きたのか

D社の診断結果には、サイトごとに異なる脆弱性が並んでいました。サイトBではXSS。サイトXではXSSに加えてCSRFとクリックジャッキング。サイトYではXSSとSSRF。サイトZでもXSSとSSRF。同じXSSが4サイトすべてで顔を出していることに、Rさんは引っかかりを覚えます。

最初に解き明かされたのは、そのXSS（クロスサイトスクリプティング。Webページに攻撃者の用意したスクリプトを埋め込み、閲覧者のブラウザ上で実行させる攻撃）の正体でした。D社は診断用に細工したリクエストをサイトBへ送り、XSSが成立することを確認します。このリクエストは、検索エンジン対策に使うSEO用のライブラリ「ライブラリM」が処理していました。ライブラリMは、アクセスされたURLのホスト名・パス名・クエリ文字列を受け取り、`<meta property="og:url" content="https://（ホスト名）/（パス名）?（クエリ文字列）">`というHTMLのタグを出力します。ここでクエリ文字列の部分は、URLデコード（URL用に変換された文字を元の文字に戻す処理）された生の値が、そのまま属性値の中に差し込まれていました。

つまり、攻撃者がクエリ文字列に`">`という文字を含めれば、content属性とmetaタグを途中で閉じてしまえる。その後ろに`<img src=1 onerror=alert(1)>`のような不正なタグを続ければ、ブラウザはそれを正規のHTMLとして解釈し、スクリプトを実行してしまう。出力の際に文字をエスケープ（特別な意味を持つ記号を無害な表記に変換すること）していなかったことが、XSSの根本原因でした。

しかし、本当に深刻だったのは「なぜ4サイトすべてに同じ穴が空いていたのか」という点です。ライブラリMは、開発部のメンバが各自で、安全性が確認できているライブラリを公開しているWebサイトからファイルサーバにダウンロードして使う運用になっていました。マルウェアが含まれていないこと、既知の脆弱性が修正されていることを各自が確認する建前です。ところが今回使われたMは、既知のXSS脆弱性への対策がされていない古いバージョンでした。その対策漏れのMを複数のメンバが使ったために、M を組み込んだサイトB・X・Y・Zのすべてで、まったく同じXSSが顔を出していたのです。一人ひとりの「確認したつもり」が、組織全体に同じ弱点をばらまいていました。

XSSの謎が解けても、診断結果には別の脆弱性が残っています。Rさんは、サイトXのCSRF（クロスサイトリクエストフォージェリ。ログイン中の利用者を騙して、本人の意図しない操作を勝手に実行させる攻撃)に目を移しました。サイトXはセッションIDをcookieの「JSESSIONID」に格納していますが、SameSite属性（cookieを別サイトからのリクエストに付けるかどうかを制御する設定)は指定されていません。一方で、キャンペーン応募ページのリクエストには「csrftoken」という、サーバが発行する推測困難なパラメータが付いていました。利用者ごとに別の値が発行される、いわゆるCSRF対策用トークンです。

一見、対策は施されているように見えました。D社が検証してみると、たしかにトークンを削除して送ってもエラー、1文字だけ書き換えて送ってもエラーになります。値そのものの正当性はチェックされている。ところが——別の利用者Bでログインした状態で、リクエスト中のcsrftokenに「利用者Aに発行された値」を設定して送ったところ、サーバはそれを利用者Bの操作として正常に受け付けてしまったのです。トークンは「正しい値かどうか」は見ていても、「それが誰のものか」を確かめていなかった。これがサイトXのCSRF脆弱性の核心でした。

さらにサイトXには、クリックジャッキング（利用者に見えている画面の上または下に、別の透明な画面を重ねて、気づかないうちに意図しないボタンを押させる攻撃)の脆弱性もありました。攻撃者は、利用者情報の公開範囲を変更する本物の操作画面を透明にして、罠サイトの「ここをクリック」という誘導画面の上に重ねます。利用者は見えているボタンを押したつもりでも、実際には透明になった本物の「更新」ボタンを押し、知らないうちに自分の情報の公開範囲を変えさせられてしまう、という仕掛けです。

そして最後に残ったのが、サイトYとサイトZの両方で検出されたSSRF（サーバサイドリクエストフォージェリ。攻撃者が用意したURLを、サーバ自身に代わりにアクセスさせ、本来は外部から触れない内部システムへ到達させる攻撃)でした。サイトYは、URLを指定するとA社のニューストピックを取得して表示する機能を持っています。攻撃者がそのURLに「内部のDBサーバの管理画面」を指定したら——本来インターネット側からは触れないはずの管理画面に、サーバ経由で手が届いてしまう。サイトZのSSRFはさらに巧妙で、外部の宿泊予約サイトとの連携機能を悪用し、リダイレクトの仕組みを利用して認証情報そのものを攻撃者のサーバへ送らせるものでした。

買収したばかりの子会社のWebサービスから、Webアプリの代表的な脆弱性がほぼ勢ぞろいで見つかった。Rさんの仕事は、これらを一つずつ塞ぎ、さらに「なぜ事前に防げる仕組みがなかったのか」という根の問題に向き合うことへと移っていきます。