はじめに

国内のECサイトを含め、世界中で「ペイメントアプリケーションの改ざん（以下、Webスキミング）」による情報漏えいが多発しています。

皆さんもおそらく下記のような情報漏えいのお詫びを目にしたことがあるかと思います。

当サイトへの不正アクセスによる個人情報漏えいに関するお詫びとお知らせ

このたび、当サイトにおきまして、第三者による不正アクセスを受け、お客様の個人情報xxx,xxx件が漏えいした可能性があることが判明いたしました。
お客様をはじめ、関係者の皆様に多大なるご迷惑およびご心配をおかけする事態となりましたこと、深くお詫び申し上げます。

Webスキミングは、Webサイトが保有するデータベースの侵害等による情報漏えいではなく、何かしらの理由でWebサイトに不正なJavaScript（以下、スキマー）が設置されることによって引き起こされる情報漏えいです。

そのため、Webスキミングは次のような性質を持っています。

• クレジットカード番号だけではなく、有効期限やセキュリティコードまで漏えい対象となる
• クレジットカード情報の非保持化を実施しているECサイトであっても漏えいする
• クレジットカード決済を取り扱っていないECサイトであっても漏えいする
  （偽のクレジットカード入力フォームを表示させ、ユーザに入力を促すことができるため）
• 「クレジットカード決済を実行」したタイミングではなく、ユーザが「クレジットカード情報を入力」したタイミングで漏えいする
  （「クレジットカード情報は入力したが購入しなかった」ケースにおいても漏えいする）

本記事では、最近発生した10万件を超える国内被害事例をもとに、Webスキミング攻撃の概説と対策手法について解説したいと思います。

Webスキミング概説

まず、Webスキミングの大まかな流れは以下の通りです。

1. 攻撃者は、スキマーと呼ばれる不正なJavaScriptを攻撃対象Webサイトに設置します。
   （設置手法は、Webサイトの脆弱性攻撃によるものや、Webサイトが利用しているサードパーティを経由して設置する方法など様々）
2. ユーザはWebサイトへアクセスし、WebサーバはWebページとスキマーを返します。
3. ユーザは自身の個人情報をフォームへ入力します。
4. スキマーはフォームに入力された個人情報を窃取し、攻撃者のサーバへ送信します。

図1. Webスキミング概要図

今回使用されたスキマーは、このWebサイトがもともと使用していたJavaScriptファイルの中に改ざん設置されていました。

図2. スキマーが設置されていたJavaScriptファイル

このスキマーのコードは約500行程度となり、難読化が施されています。

例えば、スキマーが入力フォームの情報にアクセスするためには、JavaScriptの「document.getElementById」「value」といったメソッドやプロパティを使用する必要があります。

このような攻撃に必要なメソッド名やプロパティ名をコードに直接的に記述するのではなく、何かしらの方法で難読化した上で配列やオブジェクトに格納しておき、必要になったら難読化を解いて取り出すといった手法がスキマーではよく用いられます。

図3, 図4. 配列やオブジェクトに格納された難読状態のメソッド名やプロパティ名

今回も同様の手法がとられていましたが、非常に複雑な関係性となっており（詳細は割愛しますが、用意された関数を正しい順番で実行しないと、配列から正しいメソッド名を取り出せないなど）、リバースエンジニアリングの妨害や、「特定の文字列があればスキマーの可能性がある」といったようなスタティックな方法での検出の妨害の観点で、高度な難読化が行われています。

図5. メソッド名を取り出す操作（上：失敗時の出力、下：成功時の出力）

Content Security Policyの有効性

Webスキミング攻撃への対策として重要となるのは、以下についてです。

• スキマーをユーザにダウンロードさせない（あるいは実行させない）
• スキマーが実行されたとしても、個人情報をユーザから攻撃者へ送信させない

※「脆弱性管理を徹底する」「WAFや改ざん検知の仕組みを導入する」といったことを行い、「スキマーを設置させない」ことも大切です。
ただし、これらの対策を回避する攻撃手法もあるため、Webスキミング対策としては不十分です（国内でも被害事例があります）。

これらの対策を実現させるための技術はいくつかありますが、最も代表的な技術として「Content Security Policy（以下、CSP）」が挙げられます。
Webサイトからブラウザに対して「このWebページを表示させるために、どのリソースに対してアクセスをしてもよいか」を通知し、ブラウザにそれを強制させる技術です。

図6. Content Security Policy概要図

今回の事例において、「もし、CSPを導入していたら」を考えてみたいと思います。

「スキマーをユーザにダウンロードさせない」

今回の事例の場合、CSPではこれを実現することはできません。

「外部からスキマーをダウンロードする（＝Webサイトにはスキマーのローダが設置される）」ケースにおいては、CSPによってスキマーのダウンロードを制御することが可能です。

しかし、今回はWebサイトが使用しているJavaScriptファイルの中に改ざん設置されていたため、スキマーのダウンロードを制限することはできません。

「スキマーが実行されたとしても、個人情報をユーザから攻撃者へ送信させない」

今回の事例の場合、CSPでこれを実現することは可能でした。

今回のスキマーは、収集したデータをwww[.]javascriptworld[.]xyz/isSafe[.]phpへ外部送信する仕組みになっています（下記図、コメントは筆者追記）。

この外部送信はWebサイト管理者によって想定されない通信であり、CSPによって許可が与えられる宛先ではないため、ブラウザはこの通信を拒否します。

図7. スキマーのデータ送信箇所

結論として、今回の事例では、CSPでスキマーの実行を防ぐことはできないが、実行されてもデータの外部送信を防ぐことができるため、CSPを導入していればWebスキミング攻撃による情報漏えいは防ぐことができていたことが分かります。

なお、「CSPは改ざん検知の機能を持っていないため、Webスキミング攻撃を防ぐことは難しい」と考えている人が時々います。改ざん検知できないのは正しいですが、CSPの強みは「改ざんの如何に関わらず、ユーザに対して、Webサイト管理者が想定していない宛先との通信をさせない」ことができる点にあります。

最後に

特にここ数年の間、国内でのWebスキミング被害が急速に拡大しています。一方で、何かしらのWebスキミング攻撃対策を実施している国内ECサイトは非常に少なく、ほぼ無防備な状態となっています。

CSPは万能ではなく、導入に際して課題がいくつか存在し）、またバイパス手法もいくつか存在します。ですが、CSPを導入しておけば防げたであろう情報漏えい事件が多く存在するのも確かなことです。

これを機に、各ECサイト側でのWebスキミング対策の導入が広がり、一件でも顧客情報漏えい事件が減る事を切に願っています。