APIの設定ミスから、会員情報が引き出された

本記事は、よく見られる被害の流れをもとに構成したモデルケースです。特定の企業・事件を指すものではありません。

何が起きたのか

1. 1年前：会員アプリを公開外部の開発会社に依頼して、会員証とクーポンを表示するアプリを作りました。アプリは、インターネット上のサーバーと「API」を通じて会員情報をやり取りする仕組みです。
2. 開発中：確認が抜けたまま公開会員情報を返すAPIは、本来ならログインした本人の情報だけを返すべきものでした。ところが実際には、会員番号を指定すれば、誰の情報でも返す作りになっていました。さらに、アプリの画面には表示しない住所や電話番号、生年月日まで一緒に返していました。
3. ある日：大量の問い合わせ攻撃者はアプリの通信を調べてこの仕組みに気づき、会員番号を1つずつ変えながら、自動で問い合わせを繰り返しました。問い合わせの回数に制限はありませんでした。
4. 発覚：数万件の情報が取得されていたサーバーの負荷が急に上がったことで異常に気づきましたが、その時点で数万件分の会員情報が取得されていました。会社は会員へのお知らせと関係機関への報告、アプリの一時停止を行いました。

入口になった“ほころび”

APIとは、ひと言でいえば「アプリとサーバーのあいだにある受付窓口」です。アプリが「この会員の情報をください」と頼み、窓口がそれに答えます。今回の窓口には、3つの見落としがありました。

• 相手が本人かを確かめていなかった：窓口で「会員番号○○の情報をください」と言われれば、誰が頼んでいるかを確かめずに渡していました。本来は「ログインしているのは誰か（認証）」と「その人に、この情報を見せてよいか（認可）」の両方を確かめる必要があります。
• 必要以上の情報を返していた：画面に出すのは名前と会員ランクだけなのに、窓口は住所や電話番号まで返していました。
• 回数の制限も、見張りもなかった：短時間に何千回も問い合わせが来ても止める仕組みがなく、異常を知らせる設定もありませんでした。

どれも、ひとつひとつは設定や確認の「抜け」にすぎません。しかし3つが重なったことで、外から誰でも、大量の会員情報を引き出せる状態になっていました。

なぜ、開発中に気づけなかったのか

この種の設定ミスは、普通にアプリを使っているだけでは、まったく気づけないのが厄介なところです。動作テストでは、自分の会員番号で自分の情報が表示されれば「正常」と判断されます。「他人の番号を指定したらどうなるか」という確認は、意識して行わない限り抜け落ちてしまいます。

また、「画面に表示していないから見えない」というのも誤解です。アプリとサーバーのあいだの通信は、技術的な知識があれば中身を調べることができます。画面に出ない項目も、窓口が返している限りは外から見えていると考える必要があります。

もう一つの落とし穴は、公開後の運用です。アプリは公開した時点で「完成」と見なされがちですが、機能の追加や外部サービスとの連携が重なるうちに、窓口の数は増えていきます。最初は正しく作られていた窓口も、改修のたびに確認が必要です。保守の契約に、こうした点検が含まれているかどうかも確かめておきたいところです。

発注する側に専門知識がなくても、こうした点を質問として投げかけることはできます。開発会社にとっても、確認のきっかけになります。

今日からできる確認

1. 外部とつながる窓口を一覧にしてもらう：開発会社に「アプリや外部サービスとつながっているAPIは、どれだけありますか」と聞き、一覧をもらいます。使わなくなった窓口が残っていないかも確認します。
2. 本人確認の仕組みを聞く：「ログインしていない人や、別の会員が、他人の情報を取得できないことを確認していますか」と質問します。
3. 返している項目を聞く：「APIが返している項目は、画面に必要なものだけになっていますか」と確認し、不要な項目は返さないよう依頼します。
4. 回数制限と監視を聞く：「短時間に大量の問い合わせがあったら、止める仕組みや通知はありますか」と聞きます。
5. 点検の機会をつくる：大きな機能追加の前後や年に一度など、第三者による点検を受けるタイミングを開発会社と決めておきます。

まもりスキャンの簡易診断は、公開されているWebサイトを外から確認するもので、ログインが必要なAPIの中身までは調べません。アプリやAPIを含めた確認が必要な場合は、詳細診断や開発会社による点検をあわせてご検討ください。