Webセキュリティ 2021.08.25

顧客情報を密かに狙う「Webスキミング」攻撃の最新動向と対策

近年、多くのベンダがWebスキミングに関する防御ソリューションを提供しはじめています。数年前までは、Webスキミングという攻撃を理解していても守ることが難しい状況でしたが、今はきちんと知っていればきちんと防御できる環境になってきています。そんな状況を踏まえて、技術的な防御の方法やWebスキミング攻撃に対してどんなアクションを取っていくべきか、解説します。

Webスキミング攻撃の現状

2020年9月から2021年5月までに公開された国内の不正アクセスによる個人情報漏洩事件を50件ほどランダムサンプリングしたところ、Webスキミング攻撃と推測される事件数が21件に上っています。また、21件のWebスキミング攻撃において、漏洩の疑いが発覚してから公表までの平均日数は131日です。これは、サイト停止から調査期間を考慮すると、ほぼオンラインショッピングの停止期間と近い数字と考えられ、ビジネスができずに調査などにかなりの費用が積み上がっていくことになります。さらに、Webスキミング攻撃における最大被害件数は最大4万件以上となっており、平均で見ても5000件ほどの情報が盗まれていることが読み解けることから、日本でもさまざまな場面でデータが窃取されている状況が見て取れます。

顧客情報1.png

Webスキミング攻撃が成功するまで

オンラインショッピングで商品を購入する際に名前や住所、クレジットカード番号などを入力することになりますが、不正なスクリプトが埋め込まれていると、その情報が攻撃者の用意したサーバに全て送られてしまうのがWebスキミングです。オンラインショッピングでは正常に購入処理が進んでおり、知らない間に自分のデータが盗まれてしまい、不正利用されてしまうのです。

※架空のECサイトにおけるWebスキミングイメージ

顧客情報2.png ただし、日本で個人情報が盗まれた場合の多くは「不正アクセス」という表現で公開されており、「Webスキミング」と表現されていないことから、Webスキミング自体の言葉や脅威の認知度が低いのが現状です。日本でWebスキミングが流行っていないわけではないということをしっかり押さえておく必要があります。また、Webスキミングの対策がさまざまなところで紹介されていますが、情報そのものが乱立している状況も見て取れるため、Webスキミングへの正しい理解とともに、どんな対策が必要なのか、そのなかでもどんな対策がベストなのかをご紹介します。

Webスキミングとは

Webスキミングとはそもそも何かという話をする前に、一般的な不正アクセス被害の流れについても触れておきます。通常の不正アクセスでは、Webサイトの利用者はWebサイトに個人情報などを入力し、それがWebサーバ側のDBに蓄積されていき、この蓄積された情報を攻撃者が狙っていくイメージです。最近では、カード情報の非保持化なども進んでおり、DB上にカード情報がそのまま残っているケースは通常ありませんが、さまざまな個人情報が登録されたDBを一気に盗んでいくのが不正アクセスの一般的な手口です。そこで、DBから情報が盗み出されないよう、WAFやIDS・IPSといったWebサイト側を保護するソリューションを利用してWebセキュリティ対策が行われています。

一方で、Webスキミング攻撃では、攻撃者はまず事前にWebサーバに不正なJavaScript(スキマー)を改ざん設置しておきます。その状態で一般ユーザがWebページにアクセスすると、スキマーも一緒にダウンロードされます。Webページ上で個人情報を入力する機会は様々あると思いますが、スキマーは入力された個人情報を攻撃者へ直接送ります。セキュリティコードも含めてごっそり盗まれてしまうため、カード情報の非保持化なども関係なく、クレジットカード情報が全て盗まれてしまいます。その結果、すぐに不正利用されてしまうことが、通常の不正アクセスに比べて厄介な部分です。

顧客情報3.png

Webスキミングは亜種も含めていくつかのパターンがありますが、よくあるのがサプライチェーンアタックと呼ばれるもの。一般に、サードパーティライブラリや外部広告など、様々なサードパーティリソースを活用して1つのWebページが構成されます。このサードパーティリソースが攻撃者によって改ざんされ、スキマーが設置されるケースもあります。この場合、狙われるのはサードパーティリソース側のため、自分たちのWebサイトを守るために導入したWAFやIDS／IPSでは改ざん攻撃から防御することはできず、つまり多くのWebサイトがサプライチェーンアタックに対して無防備な状況にあると言えます。

顧客情報4.png

解析されないように工夫されたWebスキミング攻撃が多くなってきており、難読化されたものや、一見正規のサードパーティライブラリに見えるように偽装されたものが多く存在します。また、自分たちのWebサイトではクレジットカード決済を実施していないために大丈夫だというサイトに対しても、偽の入力フォームをスキマーが生成するケースもあります。
他にも、受注情報を扱う管理者画面にて任意のスクリプトを実行することができる脆弱性を利用し、管理者から管理者画面ログイン情報などを窃取し、Webスキミング攻撃へつなげていく事案も観測されております。

顧客情報5.png いずれにせよ、クレジットカード情報を取り扱っていないから安全というわけではなく、ログインページや決済ページだけを注意すれば大丈夫だという話ではありません。「WAFや改ざん検知などの仕組みを導入すればいいという状況ではありません。どんな対策を選んでも、攻撃者はさまざまな手法を駆使して情報を窃取しようとします。万一スキマーが設置されたとしても、確実にスキマーを実行させないような手段を検討する必要があるのです」。（掛谷）

顧客情報6.png

Webスキミングからの守り方

では具体的にどんな対策で守っていくべきなのでしょうか。スキマーが設置されたとしても「読み込ませない・実行させない」「データを流出させない」「スキマーの設置事実に気づけるようにする」対策に焦点を当てて防御を考えていくことが、Webスキミング対策として重要になってきます。

さまざまなソリューションベンダがWebスキミング攻撃に対する防御ソリューションを提供していますが、技術的には大きくJavaScriptエージェントベースとWeb標準技術ベースの2つに集約できます。

顧客情報7.png

顧客情報8.png

JavaScript エージェントベース

他のJavaScript の挙動を監視するためのエージェントをJavaScriptで作成し、それをWebページに埋め込む方法です。よくある具体的な手法としては、スキマーが窃取した個人情報を外部へ送信する際に使用するWeb API(fetch, XMHttpRequest等)に検査機能を持たせ、実行される際にその宛先が不正でないかどうかをチェックするというものです。外部へのデータの送り方にはいくつも方法があるため、可能性のあるすべての方法に対して網羅的に検査機能を持たせることで、Webスキミングの防御ができます。

顧客情報9.png ここで懸念されるのは、パフォーマンスの部分です。JavaScript実行時に検査を行うといったアプローチの特性上、どうしても後述するWeb標準技術と比較してパフォーマンス影響が生じます。「JavaScriptに大きく依存しているWebサイトや、高いパフォーマンスを要求するようなWebサイトの場合、パフォーマンスの低下が大きく出てきてしまい、導入したものの課題となってしまったという話はよくあります。テクノロジーや注意点などを正しく理解しておかないと、無駄な投資になってしまうケースも少なくありません」。（掛谷）

顧客情報10.png 回避攻撃などにも注意が必要です。JavaScriptで動作するエージェントは、攻撃者によって分析されるリスクがあります。そのため、Webスキミングに関わらず、JavaScriptエージェント型セキュリティソリューションでは、自身が分析されないように難読化の工夫がなされているかというのが非常に重要になってきます。
また、JavaScriptエージェントの設置個所にも注意を払う必要があります。 JavaScriptエージェント型のセキュリティを導入する際は、Webページ読み込み時、一番初めにこのエージェントが評価されなければいけません。この順番を誤ってしまうと、エージェントが無力化さされてしまう可能性があります。「日本のとあるWebサイトではWebスキミング対策用のエージェントを導入していますが、設置個所に問題があり、防御できているように見えて全く防御できていないという最悪のパターンも実際あります。このことからも、テクノロジーに対する正しい理解と正しい設定が欠かせません」。（掛谷）

JavaScript エージェントベースのメリットは、JavaScriptの挙動を様々な観点で監視することができることです。例えば不正なドメインにアクセスしていないかだけではなく、ボタンクリック時のイベントが書き換えられていないか見ることもできます。。ただし、高性能なJavaScriptエージェントを独自実装することは困難ですし、JavaScriptの不審な挙動を検知できるようになったとしても、それが本当に不正な動作なのかどうかを見極めるためには知識が求められます。ソリューションベンダをうまく活用して、こういったデメリットを解消していくことになります。

Web標準技術ベース

Web標準技術ベースでは、Webブラウザに対してネットワークアクセスやスクリプト読み込みの制限を強制させる方法を用います。
具体例を見ると、HTTPレスポンスのなかに「Content Security Policy(CSP)」と呼ばれるヘッダを入れ込み、スクリプトならどんなドメインからダウンロードしていいのか、画像であればどんなドメインからダウンロードしていいのかといったことが、すべて許可リスト型で書かれています。スキマーが窃取した個人情報を攻撃者へ送信する際、その宛先はContent Security Policyで許可されていないドメインであることから、通信は全部遮断されますので、結果としてWebスキミング攻撃から防御を行うことができます。ただし、Content Security Policyだけだと不十分な部分もあるため、Sub Resource Integrity(SRI)やNonceと呼ばれるものも含めて複合的に防御していく必要があります。

顧客情報11.png この手法でも、回避攻撃については気を付けていかなければなりません。有名な回避攻撃として、「CSPバイパス」と呼ばれる攻撃があります。
例えば、Google Tag Managerなどのタグ管理ソリューションを利用してWebページを作成するといったことは一般的によくあります。Google Tag Managerを利用するためには、Google Tag ManagerのFQDNをContent Security Policyで許可する必要があります。Google Tag Managerは誰のアカウントであってもFQDNは共通です。そのため、攻撃者が自身のGoogle Tag Managerでスキマー配信の設定を行い、そのリンクをWebサイトに改ざん設置した場合、Content Security Policyではその実行を防ぐことができません。

顧客情報12.png また、運用の部分でも課題があります。Content Security Policyはポジティブセキュリティのため、Webサイトは全体としてどういう構成になっていて、それがあるべき姿として正しいのかどうかを把握するところから始めなければなりません。またWebページは日々更新されるものでもあるため、ポリシーもそれに合わせて更新していかなければなりません。「誰が」「何をもって」あるべき姿であると判断するのか、ポリシーに責任を持つのかということが課題として挙げられます（これはJavaScriptエージェントベースでも課題になりますが）。
特に日本の場合、Webページの更新を行う部門と、セキュリティを担当する部門との連携がとれていないといった組織上の問題を含んでいるケースもあるため、なかなか解決が困難な課題です。ただし、本当にセキュリティを考えるのであれば、この課題は避けるべきものではなく、乗り越えていかなければならないものであるはずです。

Webの標準技術のためにコストはかからず、JavaScriptエージェントベースと比較してパフォーマンスを低下を最低限におさえることができることや、、SEO対策やWebスコアリングにもプラスに寄与することができるといったメリットがあります。ただし、運用の難しさや標準技術でカバーできない領域を補うために、知見を持ったソリューションベンダをうまく活用する必要があります。

Webスキミング対策としてやっておくべきこと

まず最初にしていただきたいことは、今使える機能をきちんと把握しておくことです。最近ではCDNベンダがWebスキミング対策に注力しており、多くのCDNベンダがWebスキミング領域に関するオプションソリューションを提供しています。今使っているCDNがあれば、そこを確認するだけでも始めておきたいところです。
ただし、今使っているCDNが仮にWebスキミング対策の機能を提供していたとしても、必ず、 JavaScript AgentベースとWeb標準技術ベース双方をきちんと比較検討し、後戻りや無駄なコストをかけないように気を付けてください。「ポリシーミスなどで全く意味のない対策にならないよう、技術やソリューションに対する正しい理解をもって、Webスキミング対策を行ってほしいと思います。。また、既存のWebサイトにおける運営体制を見直さなければいけない可能性が高いため、組織的な観点も視野に入れておくべきです。」（掛谷）。

顧客情報13.png
今回ご紹介したWebスキミングに関して、さらに詳しく知りたいという方は、以下の関連資料をご紹介しています。以下リンク先より、ぜひダウンロードください。