サイバー攻撃の現状
クレジットカード情報流出事件が増えてます
ネット上で、「クレカ カード 流出」などといったワードで検索すると、クレジットカード情報の流出事件が数多くヒットします。近年、クレジットカードの流出が増えており、少し調べただけでも下記のような情報がヒットしました。
・ヤマダウエブコム 最大37,832名のカード情報が流出 （2019年3月18日～2019年4月26日）
https://www.yamada-denki.jp/information/190529/
・子供服サーカス 2,200件のカード情報が流出 （2018年10月1日～2019年1月18日）
https://scan.netsecurity.ne.jp/article/2019/04/04/42178.html
・エコレオンラインショップ 247件以上のカード情報が流出 （2018年5月16日～2018年12月11日）
https://cybersecurity-jp.com/news/30912
・Ski&Winter Sports Shop 最大650件のカード情報が流出 （2018年9月10日～2019年3月20日）
http://www.ici-sports.com/company/img/201907skionline.pdf
・叶匠寿庵オンラインショップ 偽の決済画面を設置する攻撃手法 1,767名のカード情報が流出 （2018年9月17日～2019年3月13日）
https://www.kanou.com/release2019072201.html
・金剛堂オンラインストア 最大30,830件のカード情報が流出（2014年12月31日～2019年2月21日）
https://kongodo.co.jp/creditcard_info.php
大きな問題として、カード情報の流出件数が多い、不正の行われていた期間が長いことが挙げられます。つまり、不正されていたことに気づかずにサイトが運営されており、被害件数がかなりの数になってしまっていることがわかると思います。上記のようなサイトの中には、クレジットカードの非保持化をしていたにも関わらず、起きていた事例もあります。非保持化とは、ショップ内にカード情報を持たずに、外部の決済サービスで決済をさせる仕組みのことを指します。ではなぜ起きたのでしょうか。
年々増加するサイバー攻撃
コロナ禍でEC需要が増えておりますが、その一方で、サイバー攻撃も増えており、中でもWebスキミングと言われる手法が増加しています。
国内のサイバー攻撃被害状況については、年々増加傾向になっています。
日本クレジット協会のクレジットカード不正利用被害額調査によると、国内ブランドカード番号盗用被害額は、2019年222.9億円になっています。前年と比較すると、22%増えており、年々右肩上がりです。2019年に報告された被害は、41件になっており、平均すると1ヶ月で3.4件起きている計算になります。41件の内訳を確認したところ、
・趣味生活雑貨通販 18件
・食品通販 9件
・ファッション通販 5件
・美容品通販 5件
・その他 4件
になっていました。ただ、公表されている被害になっていますので、実際に不正されている数は、これ以上になります。ある調査によると、１ヶ月あたり、攻撃されているウェブサイト数は、4,800という予測も出ていました。
流出したカード情報はどうなるか
流出したカード情報は、いわゆる闇サイトと言われるサイトで売買されています。カード情報は、1件あたり、100ドルで売買されると言われています。
また、流出することによって、制裁金を受けた事例もあります。
https://www.itmedia.co.jp/news/articles/1907/09/news057.html
こちらの記事を見ると、詳しく書かれているのですが、British Airways社のサイトで予約したユーザの個人情報と決済情報が盗まれていた事件で、GDPRでは、250億円の制裁金を出したと発表されていました。
このように、ウェブ上での買い物が便利になっていく一方で、こういったサイバー攻撃も年々増加しており、サイトを開発している会社側も徹底した対策が求められています。
webスキミングを理解する
webスキミングとは
webスキミング（Web skimming）とは、名前の通りではありますが、web版のスキミング（情報の抜き出し）を指しています。後ほど、詳細を説明していきますが、提供しているサービスの中に、不正なスクリプトを仕込み、ユーザが入力したクレジットカードを盗む攻撃手法のことです。フォームジャックとも呼ばれることがありますが、先ほど事例にあげた、British Airways社がこのwebスキミングの攻撃を受けて、GDPRから制裁金を受けたことで有名になり、知られるようになりました。
webスキミングの仕組み
webスキミングの仕組みについて、説明をしていきます。
通常の決済処理だと、
・＜購入画面＞クレジットカード決済処理に進む
↓ (外部決済サイトに遷移)
・＜決済代行事業者サイト＞カード情報の入力して、決済をする
上記のようなフローで決済を行ないます。
ただ、webスキミングされたサイトの場合だと、下記のように変わります。
・＜購入画面＞クレジットカード決済処理に進む
↓ (改ざんにより、同じ偽サイトに誘導)
・＜偽の決済代行事業者サイト＞カード情報の入力して、決済をする
↓
カード情報が抜き取られる
このような流れでカード情報が抜き取られています。ではなぜこんなにも流出事件が起きているのでしょうか。webスキミングの手法について、詳しく説明をしていきます。
webスキミングの手法
webスキミングの手法について、説明をしていきます。大きく分けて、2つの手法が存在しています。
1. スキマー挿入型
webスキミングのスキマー挿入型は、多くの事例であがっている手法です。ターゲットにされたwebサイトの決済画面で使用されているjavascriptを改ざんして、直接スキミングするためのプログラムコードを埋め込み、サイトの利用者がフォームに入力したクレジットカード情報を取得する方法です。攻撃の流れは、下記のような手順で行なわれます。
- ターゲットにされたサーバに不正アクセスし、javascriptファイルを改ざんします。
- サイトの利用者が、購入ページで決済情報を入力します。
- 入力した決済情報が、改ざんされたプログラムによって、送信されます。
このようにして行なわれています。先ほど事例にあげた、British Airwaysも、この手法で攻撃されました。手法はほとんど同じですが、少しだけ異なっているので、説明します。
- サーバに不正アクセスし、既存javascriptファイルの末尾にプログラムを追記します。
- サイトの利用者が、購入ページで決済情報を入力します。
- フォームデータが暗号化通信で送信されます。
上記のようにして、盗まれる被害が発生しました。
2. サプライチェーン攻撃
サプライチェーン攻撃という手法についても解説します。普段、webサイトを構築する際に、サードパーティ製のjavascriptライブラリを使うことが多いと思います。アクセス解析系のサービス、広告系のサービスなど、必ずと言っていいほど、1つ以上使っているサイトがほとんどだと思います。サプライチェーン攻撃は、このサードパーティ製のjavascriptライブラリを狙う手法になっています。
外部の会社が提供しているjavascriptライブラリを改ざんして、スキミングするためのコードを埋め込み、その改ざんしたjavascriptライブラリを使用したサイトでスキミング攻撃を行なう手法です。簡単に、攻撃の流れを記載します。
- 外部会社のサーバに不正アクセスし、javascriptライブラリを改ざんします。
- 改ざんされたjavascriptライブラリが、webサイトの運営者によって、サイトに埋め込まれます。
- 入力した決済情報が、改ざんされたプログラムによって、送信されます。
このようにして行なわれています。この問題は、非常に解決が難しく、サードパーティ製ライブラリの定期的な棚卸しが必要になってきます。外部の誰でも知っているようなサイトでサードパーティ製ライブラリの使われている割合を調査したところ、全スクリプト中、68%がサードパーティ製のスクリプトになっておりました。利用用途は様々ですが、クレジットカードの決済やアクセス解析、SNSとの連携など、webサイトの機能を強化するものや、UI/UXを充実させるためなどに利用しているケースが多いようです。
なので、このようなサードパーティ製のjavascriptライブラリが起因して、攻撃を受ける可能性もあるということを理解しておきましょう。下記に、Request Map Generator というサービスで、作成したマップを記載しました。これは、サイトに埋め込まれたjavascriptライブラリを可視化していて、javascriptライブラリが、さらに別のjavascriptライブラリを呼んでいて、3rd……4th,5th…と増えていることが理解できるかと思います。このような点からも、どのjavascriptライブラリを使うか、というのは非常に重要なポイントだったりします。
どうやって、webスキミングから守るか
webスキミングからどうやって守るべきか、手段をまとめたいと思います。下記に記載をしていきますが、1つやれば大丈夫というわけではなく、複数の対策を行なう必要があると考えています。例えば、Content-Security-Policy対応については、意図しない攻撃をブロックすることができますが、今時点で大丈夫なスクリプトだったとしても、明日攻撃がされてしまったら、防ぐことができなくなってしまいます。そのため、Content-Security-Policy対応だけを入れておけばいいということにはならず、定期的な見直しを行なうか複数の対策を打っておく必要があります。
・Content-Security-Policy対応を行なう
（サーバーサイドからブラウザにコンテンツの使用ポリシーを伝えXSSなどの攻撃を回避）
・Subresource Integrity対応を行なう
（外部(CDNなど)/サードパーティリソースのJavaScriptファイルの改ざん検査の仕組み）
・セキュリティ対策がなされた決済システムを使用する
・管理者アカウントの認証を強化する（パスワード・二要素認証など）
・ログ監視を入れておく
いくつか対策をまとめました。最初だけではなく、javascriptの更新ごとに継続運用体制ができているかを確認することがポイントになりますので、実装上の対策、監視、認証強化など、様々な視点で準備しておきましょう。もちろん、この辺をうまくやってくれるツールもありますので、調べてみてもいいかもですね。