投稿日: 投稿者: 彦坂菜奈子

skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策

Share
skyticketで約1,464万件の情報流出アイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、顧客情報の流出に関する3件の不正アクセスを公表しました。さらに10月16日には、第2報として一部利用者のクレジットカード情報等の流出を発表しています。 発生した場所も、対象情報も一様ではありません。企業の対策に生かすには、個々の事案を分けて理解し、管理機能と利用者向け機能の双方で、アクセス制御が適切かを確認する必要があります。

※本記事は2026年10月16日時点までで確認できる公表資料に基づき作成しています。

約1,464万件の情報流出と3つの不正アクセス事案

10月16日の第2報では、サーバーへの不正アクセスにより、最大6,140名分のクレジットカード情報等が流出したことも判明しました。公式発表が整理した3つの経路と対象件数は下図の通りです。

図：skyticketの3つの不正アクセス経路と情報流出の概要

skyticketの3つの不正アクセス経路と情報流出の概要
出典：株式会社アドベンチャーの2026年10月9日および10月16日公表資料をもとに弊社作成
※約413万件は約1,464万件の内数です。第2報で判明したクレジットカード情報（最大6,140名分）はサーバー事案に関する追加情報です。3事案では件数の単位や調査状況が異なるため、合計を被害人数として扱うことはできません。

自社への教訓を考える際も、これらを一つの原因で説明しないことが重要です。管理機能からアクセスできる範囲と、利用者へ個人情報を返す機能のアクセス制御は、それぞれの担当者と仕様を確認する必要があります。

利用者が確認したい流出情報と注意点

同社は10月9日の発表でクレジットカード番号の流出を否定していましたが、10月16日の第2報で内容を訂正しました。2017年2月から2018年6月までに「skyticketプレミアム」の会費支払いに利用されたクレジットカード情報が、最大6,140名分流出したことが判明しています。対象にはカード番号、名義人名、有効期限が含まれますが、セキュリティコードは含まれていません。また、会員特典である「ベネフィット・ステーション」の会員ID、氏名、パスワードの流出も確認されています。同社は対象者にクレジットカードの利用明細の確認を求めるとともに、会員には公式サイト・アプリでのパスワード変更と、同じパスワードを使う他サービスでの変更を呼びかけています。

企業側の通知でも、どの情報が対象で、利用者に何をしてほしいのかを結び付けて伝える必要があります。氏名や連絡先、予約内容が対象であれば、単に「不審なメールに注意」とするだけでなく、問い合わせ先と確認方法を案内する方が、利用者は行動に移しやすくなります。

ハッシュ化されたパスワードも 流出後の対応が必要

パスワードのハッシュ化は、入力された文字列を一定の処理でハッシュ値に変換して保存し、元のパスワードをそのまま持たないための仕組みです。ただし、ハッシュ値が外部へ出た場合に、パスワードが絶対に判明しないことを意味するわけではありません。攻撃者がパスワードの候補からハッシュ値を計算して照合する攻撃に対し、解析を困難にする仕組みが重要です。

OWASPは、パスワード保存に適した方式や処理コストの設定、利用者ごとに異なるソルトの使用などを説明しています。ソルトとは、同じパスワードでも同じハッシュ値になりにくくするために加える値です。本件の発表では方式や具体的な設定までは示されていないため、解析の容易さを断定することはできません。企業が保管方法を点検する際は、「ハッシュ化しているか」という確認だけで終えないことが大切です。方式、設定値、ソルトの扱いを確認し、漏えい時に利用者へ変更を求める手順まで整えておきます。パスワードの安全な保存方法と、流出時の対応手順を併せて整備することが重要です。

認証と認可を分けて 予約情報へのアクセスを確認する

今回のバス予約ページの問題から、Webサービスの担当者が再確認したいのが認証と認可の違いです。認証は「誰であるか」を確認する処理、認可は「その情報や操作を許可してよいか」を判断する処理です。ログインできた利用者であっても、他人の予約情報を閲覧できていいわけではありません。

OWASPは、必要最小限の権限、原則としてアクセスを拒否する設計、リクエストごとの権限確認を推奨しています。URLが推測しにくいことや、画面にリンクが表示されないことだけを、アクセス制御の代わりにはできません。利用者と対象データの関係を、サーバー側で判断する設計が必要です。自社サービスの点検では、予約完了画面、マイページ、明細のダウンロード、APIなど、個人情報を返す機能を対象にします。未ログインの状態だけでなく、別の利用者として操作した場合や、権限を変更した後の状態も確認します。これは本件でAPIや別利用者の権限に問題があったと断定するものではなく、認可の確認を自社へ広げるための観点です。

管理機能の先にあるデータも 守る範囲に含める

今回の発表は、管理機能に使われた製品や具体的な操作方法を明らかにしていません。公表されていない製品や攻撃手法を、原因として推測することは適切ではありません。[1]企業側は、自社の管理機能からアクセスできるデータを確認するとよいでしょう。業務担当者に必要な操作、アプリケーションが必要とする接続権限、運用保守のための権限を区別し、それぞれが目的を超えて広がっていないかを点検します。必要最小限の権限は、画面の利用者にも、バックエンドの接続にも適用すべき考え方です。

第2報では、2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行した際、会費支払いに関する記録（ログ）が削除されずに残っていたことが明らかになりました。このログは今回の不正アクセスで取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されていたため、情報が読み取られるおそれがあるとされています。この事案は、システム変更時に不要となったデータの削除状況や、ログに含まれる機密情報の管理を確認する重要性も示しています。

弊社が2026年10月8日に公表した提言でも、公開Webサービスの脆弱性修正、設定の適正化、認証・権限管理の徹底に加え、対策の実効性を継続的に確認することの重要性を指摘しています。新機能のリリース前だけでなく、運用中の変更がアクセス範囲を広げていないかを確かめることが重要です。

ブロードバンドセキュリティ（BBSec）「国内で相次ぐ不正アクセスを受け、
BBSecが公開Webサービスの基本対策の再点検を提言」（2026年10月8日）（https://www.bbsec.co.jp/news/20261008.html）

Webアプリケーション・APIの脆弱性を診断で確認

自社でログインできることは確認していても、許可されない操作が拒否されることまで十分に検証できているでしょうか。BBSecの「Webアプリケーション脆弱性診断」は、外部から動的に検証し、攻撃の入口になり得る問題の検出を支援します。開発時の確認に加えて、運用中のシステムにも定期的に活用できます。診断を検討する際は、顧客向けの画面だけでなく、業務管理機能、個人情報を返すAPI、利用者の役割ごとのアクセス範囲を伝えることが大切です。どの機能と権限の組み合わせを検証するかは、個別の対象や業務要件に合わせて調整します。さらに設計段階から見直したい場合には、要件定義・設計のレビューや開発標準の整備を支援する「Shift Leftコンサルティング」もご活用いただけます。

個人情報の収集・管理・提供に関わる各機能を横断的に確認することが、セキュリティ対策の抜け漏れを防ぐ第一歩です。自社のWebサービスでどこまで点検できているかを整理し、重要な情報を扱う範囲から具体的な検証につなげていきましょう。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る