令和2年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1｜合併で生まれた「他人のアカウント」——情報処理安全確保支援士で学ぶWebサイト統合とアカウント連携の落とし穴

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和2年度 10月 情報処理安全確保支援士試験 午後Ⅱ 問1
• 主なテーマ: 企業合併に伴うWebサイト統合、アカウント共通利用、LDAP認証、セキュアプログラミング（例外処理の不備）、パスワードリセットの悪用、個人情報保護法、SAMLによるシングルサインオン

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

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

企業の合併や買収（M&A）は、いまや珍しい出来事ではありません。ところが、二つの会社が一つになるとき、現場で最も苦労するのが「バラバラに育ってきたシステムをどうつなぐか」です。とりわけ、顧客の会員サイトを複数抱えている企業同士が合併すると、「同じ人が複数のサイトに別々のアカウントを持っている」という状態が生まれます。これを一つにまとめようとした瞬間、思いもよらないセキュリティの穴が口を開けます。

情報処理安全確保支援士試験の午後Ⅱで出題されたこの事例は、百貨店を運営する企業の合併を舞台に、複数のWebサイトを統合し、アカウントを相互に共通利用できるようにする——その設計と実装の過程で次々と顕在化するリスクを描いています。たった一つの例外処理の書き忘れが「他人のアカウントが勝手に紐付く」事態を招き、パスワードを思い出せない利用者への親切な機能が「アカウント乗っ取り」の入口になる。そして、それらが「アカウント共通利用」と組み合わさったとき、被害は一つのサイトに留まらず連鎖していきます。

この記事を読むと、ID連携やアカウント統合に潜む典型的なリスク、セキュアプログラミングで見落としがちな例外時の状態管理、パスワードリセット機能の設計の勘所、そしてSAMLを使ったシングルサインオンがなぜ「作り直し」の答えになったのかが見えてきます。受験対策としてはもちろん、システム統合プロジェクトを率いる立場の人にとっても、「便利さの裏で何が起きうるか」を確かめる教材になるはずです。

インシデントの概要

舞台は、半年ほど前に旧A社と旧B社が合併して誕生したC社です。旧B社が存続会社となり、旧A社の事業を引き継いだうえで「C社」に改称しました。C社は、旧A社が運営していた10店舗の百貨店（A百貨店）と、旧B社の5店舗の百貨店（B百貨店）を運営しています。

C社は、合併前から続く三つの会員向けWebサイトをそのまま抱えていました。旧A社のクレジットカード会員向けサイト（サイトP）、A百貨店の商品を販売するオンラインストア（サイトQ）、そして旧B社のポイントカード会員向けサイト（サイトR）です。サイトPとサイトQは利用者IDを英数字8〜16字で利用者自身が設定する方式、サイトRはポイントカードに記載された8桁の会員番号が割り当てられる方式という具合に、出自の違いがそのまま設計の違いとして残っていました。

合併後、C社は運用効率化のため、別々の場所にあった各サイトの機器を一か所のデータセンタに集約し、これらを管理するWeb管理課を新設します。集約後の構成では、サイトP・Q・Rがそれぞれ独立して運営され、アカウント情報はサイトごとに置かれたLDAPサーバ（利用者IDやパスワードなどのアカウント情報を、ツリー構造で一元管理するためのディレクトリサービス）のユーザエントリとして管理されていました。ログイン時の認証も、各LDAPサーバのユーザエントリにある利用者IDとパスワードを使って行われます。

ここで経営戦略が動きます。C社は、三つのサイトで集めた情報から顧客の購買傾向を分析することにしました。そのためには、各サイト間で「これは同じ顧客だ」と特定する必要があります。そこで打ち出されたのが、サイトP・Q・R相互でのアカウントの共通利用でした。技術的にはすべてが前向きな改善に見えた——そのはずでした。

何が起きたのか

アカウントの共通利用は、「親アカウント」と「子アカウント」という考え方で設計されました。たとえば旧A社の顧客向けには、サイトPのアカウントを親とし、サイトQ・Rのアカウントを子として親に紐付けます。顧客がいったん紐付けを設定すれば、子アカウントの代わりに親アカウントを使って各サイトにログインできるようになります。便利な仕組みです。

設計を任されたWeb管理課のJ主任は、サイトPのWebアプリケーションプログラム（以下、Webアプリ）に「アカウントの紐付け機能」を追加することにしました。サイトPにログイン済みの利用者が、サイトQの利用者IDとパスワードを画面に入力して「紐付け」ボタンを押すと、WebアプリがサイトQに問い合わせて認証を行い、成功すればLDAP上のユーザエントリに子アカウントの利用者IDを書き込んで完了する——そういう流れです。

J主任は、設計を終えてサイトPのWebアプリの改修に着手し、紐付け処理のJavaソースコードを書き上げました。そして、情報処理安全確保支援士（登録セキスペ）であるK主任とともにコードレビューを実施します。ここで、最初の落とし穴が見つかりました。

K主任は、ある特定の状況では「サイトPのある利用者のアカウントに、サイトQの他人のアカウントが紐付いてしまう」と指摘したのです。問題のコードは、紐付け処理を最大3回まで再試行するループになっていました。子アカウントの認証を行う`checkChild`というメソッドは、最初にサイトの識別文字列が正しいかを判定する際、`childChecked`というフラグに「サイトの識別が正当ならtrue」を代入していました。ところが、その後に呼び出す認証処理が「認証そのものを実行できなかった」場合——たとえば通信エラーなどで例外（プログラム実行中に発生する想定外の事象を知らせる仕組み。ここでは`NamingException`）が投げられると、フラグを`false`に戻さないまま例外を投げ直していたのです。

つまり、こういう連鎖が起きます。利用者がサイトQの利用者ID欄に誤ったIDを入力する。認証処理を呼ぶ手前で、`childChecked`は識別文字列が正当なので`true`のまま。認証処理の途中で何らかの理由により例外が発生し、`childChecked`を`false`に戻さずに例外が投げ直される。これが3回繰り返され、すべて同じ例外で終わると、呼び出し側のコードは「`childChecked`が`true`なら紐付け成功」と判断して、紐付けを行う行へ進んでしまう。本来は認証できていないのに、フラグだけが「正当」を指していたために、誤った利用者IDのまま紐付けが成立してしまうのです。

K主任が提示した修正案は明快でした。「`NamingException`を投げる前に、`childChecked`を`false`にする」。たった一行の追加です。しかし、この一行がなければ、認証に失敗したアカウントが「成功扱い」で紐付けられ、見知らぬ他人のアカウントが自分のアカウントにぶら下がる事態を許してしまう。例外が起きたときに「状態を安全側に戻す」ことの大切さを、この事例は静かに突きつけています。

緊張が走るのはここからです。リリースに向けた準備を進めていたまさにそのとき、サイトRでインシデント発生の報告が入ります。発端は、ある顧客からの指摘でした。「サイトRのキャンペーン応募履歴を見たら、3月のキャンペーンに応募したことになっているが、身に覚えがない。3月にはサイトRに一度もアクセスしていないはずだ」——。

J主任がサイトRのアクセスログを確認すると、不穏な事実が次々と浮かび上がりました。3月30日に、当該顧客のアカウントでキャンペーンに応募されていた。応募の直前に、パスワード失念時の処理が実行され、パスワードを電子メールで「未登録のメールアドレス」に送信した記録があった。そして3月25日から31日にかけて、サイトRへの通信量が増加傾向にあった——。

サイトRには、パスワードを忘れた利用者のための救済機能がありました。会員番号と誕生日（月日）を入力すれば、登録済みのメールアドレスに現在のパスワードをメールで送る。そして「登録済みのメールアドレスでメールが受信できない場合」には、新たなメールアドレスを入力すれば、そこへ現在のパスワードを送る——そういう設計でした。

攻撃者は、この親切すぎる設計を突きました。会員番号は8桁の数字、誕生日は月日。組み合わせの数は限られています。攻撃者は会員番号と誕生日を総当たりで入力し、たまたま合致した顧客のアカウントを乗っ取ったのです。決定的だったのは「新たなメールアドレス」を指定できる仕様でした。本人確認が会員番号と誕生日という推測可能な情報だけで完結し、しかもパスワードを「本人以外のメールアドレス」に送れてしまう。攻撃者は自分のメールアドレスを指定し、まんまと現在のパスワードを手に入れ、堂々と本人としてログインしたのです。

J主任からこの報告を受けたWeb管理課のL課長は、旧A社出身で、サイトRのパスワード失念時の操作を初めて知りました。L課長は三つの問題を指摘します。一つ目は、本人確認のための情報が少なすぎること。二つ目は、パスワードそのものをメールで送るという設計。三つ目は、パスワードを本人以外のメールアドレスに送れてしまうこと。二つ目と三つ目の解決には「パスワードリセットのURLを、登録済みメールアドレスだけに送る」ように改修すべきだ、とL課長は方針を示しました。

そしてL課長は、もう一つ重大な指摘をします。「サイトRでは、攻撃者がアカウントを乗っ取っても、あまり経済的利益を得られないので、今回のような被害で済んだと考えられる。だが、もしこれらの問題に気付かずにアカウントの共通利用を提供していたら、利用者にさらに大きな被害が発生するところだった」。サイトRの乗っ取りが、親アカウントを通じてサイトPやサイトQに波及していたら——サイトPでポイントが不正に利用され、サイトQでA百貨店の商品が不正に購入される。一つのサイトの弱点が、共通利用という「便利な橋」を通って、被害を全サイトに拡大させていたかもしれないのです。