モニタスの「Qzoo」にSQLインジェクション攻撃、会員情報約40万件が漏えいした可能性
クイズ
Qzooが受けたSQLインジェクションは、入力内容などにデータベースへの不正な命令を紛れ込ませる攻撃です。次のうち、攻撃の入口になり得る入力欄はどれでしょうか?
正解と解説を見る
正解は4番目です。入力内容の処理に不備があれば、どの欄も攻撃の入口になり得ます。数字を入力してもらう想定の郵便番号欄も、例外ではありません。
画面上で数字しか入力できないようにしても、それだけでは防げません。攻撃者は画面を経由せず、サイトに直接データを送ることができるためです。
重要なのは、入力欄の見た目や用途ではなく、受け取ったデータの扱い方です。詳しい仕組みと防ぎ方は、本文の「SQLインジェクションとは」と「対策」で説明します。
| 項目 | 内容 |
|---|---|
| 発生・公表日 | 不正アクセスの開始:2026年10月17日8時30分/検知・遮断:同日18時44分/公表:10月21日 |
| 対象組織・業界 | 株式会社モニタス(東京都港区)/マーケティングリサーチ |
| 対象サービス | アンケートサイト「Qzoo」 |
| 攻撃手法 | SQLインジェクション(システムの脆弱性を悪用) |
| 漏えいの可能性がある件数 | 約40万件(10月17日時点でQzooが保有していた会員情報の全件。実際の漏えい範囲は調査中) |
| 対象情報 | 氏名・生年月日・住所・電話番号・メールアドレス/会員ID・パスワード/口座番号・支店名・口座名義/年収・職業などのアンケート回答 |
| 情報源 | モニタス「当社が運営するアンケートサイト「Qzoo」への不正アクセスによる個人情報漏えいの可能性に関するお詫びとお知らせ」(2026年10月21日) |
株式会社モニタスは2026年10月21日、同社が運営するアンケートサイト「Qzoo」が不正アクセスを受けたと公表しました。会員の個人情報約40万件が漏えいした可能性があります。
攻撃者はシステムの脆弱性を悪用し、SQLインジェクションによってデータベースを閲覧・更新しました。漏えいの可能性があるのは、10月17日時点でQzooが保有していた会員情報の全件です。約40万件という数字は漏えいが確定した件数ではなく、実際の範囲は調査中です。
対象の情報には、氏名・住所・電話番号などの基本情報が含まれます。会員IDとパスワード、口座番号・口座名義、年収・職業などのアンケート回答も対象です。一方、クレジットカード情報とマイナンバーは保有していないと説明しています。
同社によると、Qzoo以外の自社システムへの不正アクセスは確認されていません。
- 2026年10月17日(土)8時30分:第三者による不正アクセスが始まる
- 同日12時22分:SQLインジェクションによるデータベースの閲覧・更新が行われる
- 同日18時44分:事象を検知し、アクセスを遮断
- 同日19時02分:Qzooを緊急メンテナンスに移行
- 2026年10月20日18時07分:個人情報保護委員会へ速報
- 2026年10月21日:モニタスが公表
同社は外部の専門機関とともに、原因と影響範囲を調査しています。また、サービスの停止により、取引先の調査業務に遅れが生じる可能性があるとしています。
会員に対しては、Qzooや同社を装ったメール・SMS・郵便物に注意するよう呼びかけています。同じメールアドレスとパスワードの組み合わせを他のサービスでも使用している場合は、パスワードの変更を求めています。Qzooのパスワードについても、サービス再開時に再設定が必要です。
SQLインジェクションとは
Section titled “SQLインジェクションとは”本件では、システムの脆弱性を悪用したSQLインジェクションが確認されています。ただし、脆弱性があった機能や画面は公表されていません。ここでは、一般的な攻撃の仕組みを説明します。
会員情報を管理するWebサイトでは、利用者の入力内容をもとに、データベースへ「この会員の情報を取り出す」といった命令を送ります。この命令に使われる言語がSQLです。
SQLインジェクションは、入力内容などに不正なSQLの命令を紛れ込ませる攻撃です。サイト側の処理に不備があると、本来はデータとして扱うべき内容が命令として解釈され、実行されてしまいます。申込書の氏名欄に「ついでに名簿を全部渡すこと」と書いたところ、窓口がその指示に従ってしまうようなものです。
攻撃者が紛れ込ませる命令によっては、情報の読み出しだけでなく、書き換えや削除につながることもあります。公開されたWebサイトが、外部からデータベースを狙う入口になるのです。
本件では、データベースの閲覧に加えて更新も行われたと公表されています。そのため、情報が持ち出されたかどうかだけでなく、どのような変更が加えられたのかも調べる必要があります。
本件で不備があった機能は公表されていないため、ここではSQLインジェクション一般の対策をまとめます。
1. 命令とデータを分けて扱う
Section titled “1. 命令とデータを分けて扱う”根本的な対策は、入力された値をSQL文に直接つなぎ合わせないことです。プレースホルダを使って値を渡せば、入力内容は常にデータとして扱われ、命令としては解釈されません。
多くの開発フレームワークは、この仕組みを標準で備えています。ただし、複雑な検索などでSQL文を手書きする箇所では、保護が効かないことがあります。古い画面や外部のプラグインも含めて、すべての箇所を確認します。
2. 被害が広がらない作りにする
Section titled “2. 被害が広がらない作りにする”穴が残っていた場合に備え、被害を小さくする設定も重ねます。Webアプリがデータベースに接続するアカウントには、必要な操作の権限だけを与えます。閲覧しかしない画面に、更新や削除の権限は要りません。
データベースのエラーの内容は、画面にそのまま表示しないようにします。エラー文は、攻撃者がデータベースの構造を探る手がかりになるためです。パスワードは、元の文字列に戻せない形で保存しておきます。
3. 確認と時間稼ぎを続ける
Section titled “3. 確認と時間稼ぎを続ける”公開しているWebアプリは、新規公開時と改修のたびに脆弱性診断で確かめます。穴が見つかって修正が終わるまでの間は、WAFで攻撃を検知・遮断します。ただし、WAFだけに頼らず、脆弱性そのものを修正することが必要です。
今後の確認事項
Section titled “今後の確認事項”今後の公表では、次の点を確認する必要があります。
- 実際に漏えいした件数と情報項目
- パスワードの保存方式と、データベースで更新された内容
- 脆弱性があった機能と具体的な不備
- Qzooの再開時期と再発防止策
- 会員情報を悪用したなりすましや不正利用の有無
新たな情報が公表され次第、本記事に追記します。
| 日時 | 内容 |
|---|---|
| 2026-10-27 | 第一報を公開 |