nimoca：公開の利用履歴照会サービスへの不正アクセス

原因・対策の仮説

以下は編集者の仮説です。事故の確定原因や、公表された対応とは分けています。支持・反証の観測は、これから調べる項目であり、取得済みの証拠ではありません。

1. 原因仮説 1 未検証

   第三者が正規の入力・通知機能を悪用した可能性を、侵入経路の候補として検討します。

   一次資料から確認した出発点

   身に覚えのないメールは、所定の入力に応じてサービスが登録先へ自動送信したものでした。

   [s1]p.1 §2 概要

   成立条件・検証の観測・限界を読む

   成立に必要な条件

   • 攻撃者が正規フローに到達し、他人の登録情報に紐づく入力をサービスが受理した場合。

   仮説を支持する観測

   • 保全されたWeb・アプリログで、不正アクセスと同時刻の正規エンドポイント呼び出しや本人確認の不足が確認できる。

   仮説を見直す観測

   • 調査で別の侵入経路によるDB取得が確認され、メール送信はその後の別の動作だったと分かる。

   判断の限界

   • 通知メールは機能が動いた証拠であり、認可欠陥の証明ではありません。SQLインジェクションなど別経路も排除できません。

   関連する点検

   • SEC-009
   • SEC-014

2. 対策仮説 2 未検証

   照会と通知の前に利用者と対象データの権利関係を確かめ、取得量を制限すると、正規機能の悪用を抑えられる可能性があります。

   一次資料から確認した出発点

   公開照会サービスへの不正アクセスと、登録情報を含む自動メールが公表されています。

   [s1]p.1 §2 / p.2 §4

   成立条件・検証の観測・限界を読む

   成立に必要な条件

   • 照会・通知の経路で、利用者とデータの関係をサーバー側で検証できる場合。

   仮説を支持する観測

   • 自分の隔離テスト環境で架空の2利用者を使い、他人のデータ照会・通知が拒否され、取得量制限が働く。

   仮説を見直す観測

   • 未認証や別利用者の入力で対象データが返る、または大量の照会・通知が制限なく通る。

   判断の限界

   • 本人確認と制限が有効でも、サーバー侵害など別経路は残ります。事故当時の欠陥は未公表です。

   関連する点検

   • SEC-014

この事例のAI向け資料を読む ↗