【メルマガ】クレカ情報を「保有しない」サイト管理者も要注意！(2023年02月21日)

先日、大きめのクレジットカード情報の漏洩がありました。
(112,132件)

「当サイトは関係ない」と勘違いされるサイト管理者もいらっしゃるかもしれません。
少し仕組みを見てみましょう。

事件の概要

システムの脆弱席が利用され、アプリケーションが改ざんされたたようです。
(改ざん後、)クレジットカードの入力した情報がそのまま流出しました。

2022年11月15日〜2023年1月17日で 112,132名。

決済時の情報となりますので、セキュリティコードなどを含むクレジットカード決済情報が流出しています。

※別途、個人情報の流出も記載されています。
子細は不明ですが、クレジットカード購入ではない方がこのケースに該当すると思われます。

「今までの」よくある流出例

システムの脆弱性が利用されるのは同じですが、そのサイトに保存されているクレジットカード情報(やその他個人情報)が流出することが多かったように思えます。

ただし、そういった場合はセキュリティコードを保存していなかったり、(取得方法によっては)暗号化された状態のため使えない、など、やや使い勝手の悪い情報だったかもしれません。

データベースをごそっと盗られますので、件数が多いことも一つの特徴かもしれません。

今回のような仕掛け

具体的な内容が開示されているわけではないので、以下はあくまで推測です。

ネット決済の仕組みも色々とありますが、以下のように処理するケースがあります。

1.利用者(の端末)
-> 2.ECサイト
-> 3.決済画面(クレジットコードを入力)
-> 4.決済完了、購入完了画面

このうち、3は「決済代行サービス」と呼ばれるサービスが提供するシステムに直接つながっています。

画面の見た目などはECサイトのように見えるかもしれませんが、
クレジットカード情報の送信先は直接決済代行サービスとなります。

つまり、ECサイト自体は(仕組み上)クレジットカード情報を知ることができず、ECサイト内にクレジットカード情報を蓄積することもできません。

なお、ECサイトのプログラムで、決済代行サービスの接続先などを設定しています。

ECサイトのプログラムが改竄･･･この決済代行サービスの接続先を、ダミーのフィッシングサイトに接続したらどうなるでしょうか。
(もちろん見た目は全く同じで)

入力したクレジットカード情報がフィッシングサイトに渡りますよね。

今回、発覚に時間を要したことから、注文自体も通っていたのではないかと思われます。
※注文が通らないとさすがに利用者側もおかしいと感じる

クレジットカード情報は盗みつつ、正規のルートの処理は正しく流していたのでしょうか。

このような流れだと、過去の決済情報を拾うことはできず、改竄したこの経路に流れてきたクレジットカード情報のみ流出する、というわけです。

このように、直接クレジットカードを扱わないようなECサイトでも、クレジットカードを流出する危険性はあるのです。

どうすればよい？

このようなケースは、サーバのプログラムが書き換えられるような権限までないとなかなか実現できません。

基本は、脆弱性対応をしっかりと行うことになります。
プログラムの改竄を検知するようなセキュリティ製品もありますので、ご検討いただいてもよいかもしれません。

ECサイトのセキュリティ強化の義務化の動きもあります。
避けては通れませんし、そもそもはやはり起こしてはいけないものですので、しっかりと対応していきたいですね。