はじめに
皆さん、決済していますか？（挨拶）
元々対面取引の後払い・信用払いの方法として登場したクレジットカードですが、インターネットの普及にともないウェブサービスや通販などのオンラインでも使われてきています。
今回は簡単にクレジットカードのオンラインでのセキュリティの歴史と、最近の不正利用と対策について紹介します。
昔のクレジットカード決済はザルだった
日本では2015年くらいまでは、インターネットでのクレジットカード決済は 「カード番号」 と 「有効期限」 があれば決済できていました。
Webフォームにカード番号と有効期限を打ち込めば他人のカードだろうと何だろうと使えてしまうわけです。所有者の確認がされていないのです。
クレジットカード番号は仕様があり、機械的に生成できます。
最初6桁がBINコードと呼ばれブランドや発行会社（イシュア）で、7桁目から最後から1桁前までが会員口座番号、最後の1桁がチェックデジット（MOD-10） です。（現在BINコードは8桁化が進んでいます）
ここに10年くらい未来の年月を有効期限として組み合わせれば、オンラインでも簡単に試せてしまうものでした。
また当時のオンライン決済はクレジットカード情報などは利便性のためにDBに蓄えられることもあり、SQLインジェクションやバックドアなどによって漏洩してしまう、といったこともありました。
こういったことを踏まえ、経産省が主導し様々なセキュリティ施策を事業者に講じるよう法整備を進めてきました。
近年のセキュリティ施策
主に経産省や日本クレジット協会の指針を取り上げています。より詳しく知りたい場合は下記をご覧ください。
非保持・非通過
2016年の割賦販売法（割販法）の改正で、クレジットカードを直接取り扱わないようにしました。
決済したければ、決済代行事業者（PSP）が用意する画面に遷移させるか、トークン決済をさせる必要があります。（PAY.JPさんではトークン決済のようです）
トークン決済というのは、 クレジットカードを入力するWebフォームから直接PSP宛に送信し、応答で得られたトークンをシステムに渡してPSPにオーソリをかけていく ものです。
これによりクレジットカード情報をDBに持たせたり、うっかりログに露呈してしまったりといったことが無くなりました。
セキュリティコード
クレジットカードにはカード番号とは別にCVV（CVC、CID）と呼ばれる 3～4桁の番号 がふられていると思います。
これはカード自体（磁気ストライプやIC）には持っていない情報であり、手元に本物のカードがあることを証明します。※CVV2以降
これもオンライン決済で求められるようになり、オンラインでの総当たり試行のパターン数を大幅に上げました。
3Dセキュア
本人認証サービスといった名称で呼ばれているものです。
これはオンラインで決済しようとしたとき、 カードの発行会社（イシュア）が本人認証をするためのURLを提供し、そのURLでワンタイムパスワード等により本人確認をする仕組み です。
リダイレクトやiframeなどで画面をいったりきたりする仕組みのため整合性には気を付けなければなりませんが、PAY.JPさんでは動画や実装サンプルが充実していますから、このベストプラクティスに沿って実装しましょう。
3Dセキュアの最大の恩恵は チャージバック への対策です。
クレジットカードは消費者保護の性質が非常に強く、消費者が不正利用だと言って認められれば支払いが拒否できます。
でもその前に商品の発送をしたりサービスを開始していたら……その費用はお店負担になってしまいます。これがチャージバックです。
3Dセキュアを導入することで、お店負担ではなくカード会社負担にさせることができます。（ライアビリティシフト）
なお3Dセキュア自体は昔からあります（3Dセキュア1.0）が、最近はEMV 3Dセキュア（3Dセキュア2.0）というものが登場しており、これが導入義務化になっています。
何が違うのかというと、今まで1.0では毎回本人認証画面が出てきたために 離脱率が高まるという問題がありました。これを2.0ではリスクベースによる出し分けをすることで、本人認証画面の頻度をおさえ、離脱率が高まるのを抑えています。
情報漏洩や不正利用のトレンド
これだけ法整備によりセキュリティのレベルを上げていますが、まだまだクレジットカードの漏洩や不正利用が絶えません。
手口は様々ですが代表的な例として3つ挙げます。
Eスキミング
Webスキミング、オンラインスキミング、フォームジャッキング、Magecart（メイジカート）とも呼ばれる手法です。
有名どころだと2024年に起きたタリーズオンラインストアでの ペイメントアプリケーションの改ざん です。
報告書にペイメントアプリケーションの改ざん書かれているケースの多くはこれだと個人的には考えています。
私自身、他社の報告を見て実際に改ざんを目撃したことがあります。
クレジットカード入力画面に 不正なスクリプトを仕掛け、フォームに入力されたクレジットカード番号などを外部に送信させてしまう ものです。
不正なスクリプトは自分のWebサイトのスクリプトに埋め込まれることもあれば、サードパーティのスクリプトが改ざんされて埋め込まれることもあります。（Magecartは後者を指します）
詳しい解説は徳丸先生の下記記事の4をご覧ください。
クレジットカード情報盗み出しの手口をまとめた
ほか他社の事例:
https://www.trendmicro.com/ja_jp/jp-security/24/k/expertview-20241108-01.html
この仕組みでID、パスワード、個人情報なども抜き取ることができますが、有効なクレジットカード情報は ダークウェブでの価値が高い （後述）ので、特に狙われやすいです。
（私が見た事例ではメールアドレス、パスワードなどもすべて抜き取る実装でした）
対策
スクリプトやコンテンツが改ざんされてしまうことが問題です。
自分のサイトに 脆弱性がある場合は解消しましょう。
また緩和策として 改ざんを検知する仕組み も入れましょう。
もし静的なスクリプトであればファイルハッシュ値を比較する方法が手軽です。
CSPやSRIでハッシュ値を指定してもいいですし、自分で定期的に突合してもいいと思います。
ただし動的なスクリプトやサードパーティスクリプトについてはハッシュ値はなかなか難しいところです。
CSPのドメイン制御を入れたり、WAFを入れたりと、複合的に対策を入れてリスクを下げていくしかありません。もちろん監視やアラートの設定はお忘れなく。
※動的スクリプトにはCSPのnonceを入れたらいいという話は聞きますが、あればXSSへの対策であり、改ざんへの対策にはならないと思います。
不正注文
希少性があったり、換金性が高かったりする商品を取り扱っているところでは非常に多いです。
よくあるケースが以下です。
- 不正入手したカードを使用する
- 空き家や転送業者宛に配送する
不正入手したカードというのはダークウェブで数千円くらいで売っています。
参考: INTERNET Watch 「日本のカード情報が世界最高額で売買」とNordVPNがダークウェブの調査結果を発表。その理由は？
こういったカードを利用し、空き家（古めの集合住宅など）や転送業者（倉庫など）に送り、そこで受け取った人が海外で売却して利益を得るといった手口です。
対策
こういったことに慣れたショップは自然とブラックリストを作り上げていると思いますが、新規のショップはなかなか大変です。
技術的にできる手立ては少なく、以下のような対策で緩和していきます。
- 3Dセキュアを導入する
- 不正検知サービスを導入する（チャージバック保証があるとよい）
なお、配送業者から不審な配送先であることを告げられることもあります。
クレジットマスター攻撃
昔のクレジットカード決済はザルだったで述べていますが、クレジットカード番号は仕様があるため自分で作ることができます。これを Botを使って大量に有効性チェックをしていく のがクレジットカードマスター攻撃です。
現在のセキュリティ施策を入れた状況でも、有効性チェックをすることだけであれば多くのサイトで実施できてしまいます。
例えば3Dセキュアの画面が表示されたら、クレジットカードとしては有効と考えられます。実際に決済する必要はありません。
Eスキミングもそうですが、この攻撃者は有効なクレジットカード情報だけが欲しいのです。不正注文で挙げたようにダークウェブで数千円で取引されていますから、そこで利益を上げます。
（こういった有効なカードを売る攻撃者と、前述の不正注文で利益を得る攻撃者はそれぞれ別の存在です）
対策
サイトへの被害は決済手数料の増加やリソースの枯渇が主になります。
Bot対策が基本になりますが、経験上かなり高度なBotを使ってくるため、一筋縄ではいきません。
-
CAPTCHAを使う
- 人間ですら嫌になるパズルなどを解かせる方法です。
変形文字はあまり効果が高くありませんが、パズル系はまだ効果があります。
デメリットとしては離脱率が高まってしまうところです。
- 人間ですら嫌になるパズルなどを解かせる方法です。
-
サイレントチャレンジを使う
- 人間的な行動をしているかどうかをスクリプトで評価する方法です。
人間の負担はほぼないのですが、Botもヘッドレスブラウザで人間を装った動きをしますから、効果が弱いことがあります。
- 人間的な行動をしているかどうかをスクリプトで評価する方法です。
-
レートリミットを入れる
- IPアドレスなど接続元の情報を利用し、決済の繰り返し試行を検知して止める方法です。
攻撃側は数百～数千の大量のIPアドレスを使用してきますので、単体のIPアドレスを1つずつ登録してくのは骨が折れます。IPが所属するネットワークレンジに特徴が無いか調べ、まとめて制限をかけましょう。 - ただしこのネットワークレンジが国内大手回線・VPS事業者の場合もあり、レンジでブロックしてしまうと一般消費者に影響が出る場合もあります。whoisやIP調査サービスでよく調べておきましょう。
- IPアドレス以外ではJA3/JA4 Fingerprintを使う方法もありますが、攻撃側も熟知しているのかパターンが一致せず、有用でないことがあります
- IPアドレスなど接続元の情報を利用し、決済の繰り返し試行を検知して止める方法です。
これらを組み合わせて攻撃されるリスクを減らしていくのがよいです。
余談ですが、既存ECサイトに手を加えず簡易的にクレジットマスター攻撃を検知する方法を記事にしたことがありますので、よければご覧ください。
まとめ
日本の決済セキュリティは2015年を境にトップダウンでの強化の道を進んでいるのですが、現在でも変わらず攻撃と防御の「いたちごっこ」が続いています。
決済実装は、機能要件と同じくらい「いかに攻撃のモチベーションを削ぐか」という防御のデザインが重要です。本記事で紹介した歴史や対策が、皆さんのサービスの「守り」を固める一助になれば幸いです。