はじめに

2024年 5月、AWS builders.flash に 『セキュリティ関連の HTTP ヘッダーの意義とAmazon CloudFront での設定方法 ~ 後編 』という記事を寄稿しました。

この記事では、Amazon CloudFront におけるセキュリティヘッダ全般を解説しています。

2024年 10月、タリーズコーヒージャパンの EC サイトより、情報漏えいが発生し、その原因は Web サイト改ざんと解析されています。 (後述)

この被害は、上記記事内で『Web サイトが利用するリソースの提供元を制御』として解説した、『Content-Security-Policy (CSP)』 で被害を抑止できた可能性が高いものです。

これらの情報漏えいを防ぐため、CSP はとても効果が高いですが、その利用についての情報は多くありません。

この記事では、タリーズコーヒージャパンの EC サイトで発生したインシデントの概略とその対策について、セキュリティ目線で確認したいと思います。

インシデント概略

2024年 10月、タリーズコーヒージャパンは、 EC サイト「タリーズオンラインストア」における、92,685 件の個人情報および、52,958 件のクレジットカード情報漏洩の可能性を公表しました。
(出典 タリーズのECサイトに不正アクセス、約9万人の個人情報が漏洩の可能性 日経クロステック)

この原因としては、「同サイトを構築するプラットフォームシステムに第三者が不正アクセスし、同サイトのURLを改ざんした痕跡が確認されている」（広報）とのことです。

motikan2010 氏による解析では、Web アーカイブ内に悪意あるコードがあると解析されています。
(出典 クレカ情報の流出があったタリーズオンラインストアのWebアーカイブから原因を特定した猛者が現れる→集まった有識者たちにより巧妙な手口が明らかに togetter)


(筆者による攻撃に関する推測)

この被害により、タリーズコーヒージャパンはもとより、利用者に対してもカード情報不正利用等の被害が想定されています。

セキュリティ対策の検討

今回のサイト改ざんに於いては、いくつかの段階があったと考えられます。
この章では、AWS を活用したウェブサービスを仮定して、想定される攻撃と対策を検討してみたいと思います。

タリーズオンラインストアの実態についての記述ではないこと、ご認識ください。

なぜ、ソースコードの改ざんが可能だったのか？

slick は、広く利用されているスライダーライブラリです。

今回の攻撃では、「利用者が自社サイト内に保管した」 slick.min.js が改ざんのターゲットに悪用されました。

こういった静的データの保管には、S3 などのオブジェクトストレージが利用されています。
S3 などの脆弱性を悪用されて、コンテンツ改ざんが起きることはほとんどありません。

このようなデータの改ざんは、設定ミスや不適切な設計や侵入検知時の対応不備など、サービスの利用側の問題で多く発生しています。

改ざんを防ぐためのソリューションとしては、以下が考えられます。

  • Security Hub
    • Cloud Security Posture Management (CSPM) により設定ミスを抑止し、環境を堅牢化する。
  • GuardDuty
    • 侵入・改ざんなどのイベントを検知し、攻撃を認識、インシデントハンドリングする。
  • CloudTrail
    • Data Event の 書き込み を保存し、改ざんの記録を残す。

これらの機能を利用し、ソースコードの改ざんを防ぎ、検知し、記録を残すことが必要です。

なぜ、改ざんされたコードが利用されたのか？

改ざんされたコードが HTML ファイルから利用され、実行された理由はなぜでしょうか？

ブラウザには、スクリプトなどの完全性 (改ざんがないこと) を保証する機能があります。
しかし、この機能を利用しない場合は全てのコードが実行されます。

script タグの integrity 属性は、リソースが改ざんされたときにその実行を抑止します。
この機能は、 サブリソース完全性 と呼ばれます。

このように、サブリソース完全性を担保するソリューションとしては、以下が考えられます。

  • integrity 属性
    • サブリソースが改ざんされたときに、ブラウザでの実行を抑止する。
  • CodeGuru Reviewer
    • CodeGuru Reviewer では、コードの不備やリスクを検知する。
  • Amazon Inspector
    • コードの脆弱性やライブラリの脆弱性を検知する。

これらの機能を利用し、改ざんされたコードの利用を防ぎ、改ざんに対して堅牢化することが必要です。

なぜ、情報が漏洩したのか？

ソースコードが改ざんされ、実行された際に、最後の砦として機能するのが Content-Security-Policy (CSP) です。

CSP では、ソースコードの実行だけでなく、その通信先まで管理し、ユーザー情報が漏洩することを防ぐことができます。

CSP を構成することで、悪意あるスクリプトの実行を防ぎ、悪意ある通信を防ぐことができるようになります。


具体的な Directive については、次の章で解説します。

このように、情報漏洩を防ぐソリューションとしては、以下のようなソリューションが考えられます。

  • CloudFront
    • セキュリティヘッダーにより、CSP を活用する。

Content Security Policy の活用

この章では、CSP のうち、悪意あるスクリプトから保護するために有用な機能を記載します。

CSP は多くの機能を有しています。
すべての機能を記載しきれませんので、mdn web docs の記述は是非ご確認ください。

この章では、個々の Directive について記載します。
デフォルト値を設定する default-src Directive も有用なため、合わせての利用を検討してください。

Script の提供元を制限

script-src Directive は、Script の src として利用されるソースを制限できます。

例えば、自分自身のサイトのみからに限定する場合 'self' を利用して同一オリジンに限定できます。

CDN からライブラリを利用する場合、 https://example.com など、CDN の URL を指定することにより、CDN ライブラリを利用することも可能となります。

また、重要な機能として、危険なソースコードが利用できなくなります。

XSS などの攻撃で多用される inline code や eval("...")、Function("...") などのコードは利用できなくなります。

これにより、悪意あるコードが実行されるリスクを最小化することが可能です。

通信先を制限

Script 内の送信を制限する

connect-src Directive は、スクリプトが接続する先を制限できます。

これは、fetch や XMLHttpRequest などの通信先を制限するものです。
例えば、攻撃者が用意した攻撃サーバー (C&C Server) と通信しようとした際も、適切な connect-src により制限することが可能です。

通常の利用用途であれば、自分自身を示す 'self' や、自身が作成した API Gateway を示す https://api-id.execute-api.region.amazonaws.com/stage/ などを記述します。

Form 内の送信先を制限する

form-action Directive は、Form タグの送信先を制限できます。

攻撃者が用意した C&C Server に Form の送信先を改ざんする場合などであっても、情報漏洩を防ぐことが可能となります。

こちらも、通常の利用用途であれば、自分自身を示す 'self' や、自身が作成した API Gateway を示す https://api-id.execute-api.region.amazonaws.com/stage/ などを記述します。

これにより、情報漏洩に対してリスクを最小化することが可能です。

フレーム内の悪意ある動作を制限

提供元を制限する

child-src Directive では、<frame> や <iframe> などのフレームコンテンツの提供元を制限できます。

Frame は、他者の提供するコンテンツを自社サイト内で利用するのに便利ですが、他者がコンテンツを管理しているため、悪意あるコードが入り込むリスクがあります。

この Directive を利用することにより、自身のサイトが必要とする提供元に限り、Frame の src に指定することが可能となります。

この Directive はインライン指定に対して脆弱なため、後述する sandbox と合わせて利用することが重要となります。

Frame 内の動作を制限する

sandbox Directive は、Frame 内での動作を制限します。

たとえば、frame 内の Script 実行や、ファイルダウンロード、フレーム外の Link など、悪意ある行動を抑止できます。

この指定は若干特殊で、URL を記述するわけでなく、許可する動作を allow-scripts のように指定します。

そのため、sandbox 単体で記述すると、全ての危険な動作が禁止されるため、最も堅牢な状態になります。

これらを組み合わせて、Frame 内での不正な動作を抑止します。

まとめ

旧来の Web アプリケーションの保護には、脆弱性診断などの対策が取られてきました。
脆弱性診断では、SQL Injection などの攻撃に対して堅牢であることを確認できます。

徳丸 浩 氏いわく 、2018年以降のカード情報漏洩で、蓄積されたカード情報が漏洩したケースは無い とのことです。

今の情報漏洩の多くは、サーバー側ではなく、クライアント側で起きています。

CSP を含めたブラウザ側の堅牢化を行うことで、クライアント側でのリスクを最小化することが可能です。

従来のような脆弱性診断や WAF のような手段だけでなく、クライアント側の堅牢化についても検討を行ってください。