【2024年11月版】slickのバージョンと脆弱性情報(タリーズ事件との関連性)

皆さんこんにちは。taneCREATIVEの「ちほうタイガー」です。
この記事は2024年11月25日に執筆しています。

今回はslickのバージョンと脆弱性への対応状況についてまとめてみたいと思います。

slickは、Webサイトにスライダーやカルーセルを簡単に実装できるjQueryベースのプラグインであり、Ken Wheeler氏によって開発されました。
公式リポジトリでは、バグ報告や機能追加の提案が受け付けられていますし、ユーザー同士の情報交換も活発に行われています。

一方で、公式の最新バージョンのリリースは2020年には確認されていた1.8.1を最後に停止しており、公式サポートチームも存在しないことから、セキュリティや保守性の面で注意が必要であることを示しています。

2024年10月3日に、タリーズコーヒーより「【重要】弊社が運営する「タリーズ オンラインストア」への不正アクセスによる個人情報漏洩の恐れに関するお詫びと調査結果のご報告」で、顧客の個人情報（92,685件）、とクレジットカード情報（52,958件）が漏洩した可能性があることが発表されました。

その原因がタリーズコーヒーのサーバーに設置されていたslick.min.js（slickの圧縮版）であったことで、Web業界には衝撃が走りました。

そこで、この記事では、企業のWeb担当の皆様に向けて、slick及び slick.min.jsの概要並びに、脆弱性情報と今回のタリーズコーヒーの問題を解説することで、slickを安心して使用していただけるようにしたいと思います。

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

前述の通り、slickは、Ken Wheeler氏によって開発・サポートが継続されている、オープンソースのjQueryプラグインです。

このプラグインを使用すると、Webサイトにスライダーやカルーセルを簡単に実装できることから、世界的にも人気のあるjQueryベースのプラグインとなっています。

しかしながら、実際のところ、当社のようなセキュリティ対策を強みとしているWeb制作会社の場合、slickを利用することはあまりありません。

理由としては、slickの公式リリースがバージョン1.8.1以降長らく停止していること、あくまでKen Wheeler氏個人による開発・サポートであることから、迅速なセキュリティパッチの配布などが期待しにくいことなどが挙げられます。

しかしながら、当社がこれまでに保守を引き受けたWebサイトには、slickが使用されていたことは数多くあります。

日本国内でも、一般的に使用されているプラグインの一つという印象です。

slick.min.jsは、オープンソースのスライダープラグイン「Slick」の圧縮版JavaScriptファイルです。

いわゆるフォークではなく、Slickの公式GitHubリポジトリからダウンロードできる、Slickのファイル一式に含まれている公式のJavaScriptファイルです。

ファイルサイズを小さくするためにコードが圧縮されていますが、Slickの全機能を有しており、軽量であるため、開発者がWebサイトに導入する際によく使用されています。

そのため、slick.min.jsのバージョンはslick本体と同様にカウントされており、最新バージョンは1.8.1です。

slick及びslick.min.js自体の脆弱性は当社では確認されておりません。

上記のように、slick及びslick.min.js自体の脆弱性については、当社が知る限り見つかっていませんが、一方で、2024年10月3日に、タリーズコーヒーより公表された「【重要】弊社が運営する「タリーズ オンラインストア」への不正アクセスによる個人情報漏洩の恐れに関するお詫びと調査結果のご報告」の原因が、slick.min.jsであったという情報が出たことから、Web制作業界（の一部）に激震が走りました。

slick.min.jsはそれくらいメジャーであり、多くのサイトで使用されているプラグインだからです（当社でも緊急にslick.min.jsを使用している保守対象のサイトで同様の攻撃を受けていないか確認しました）。

ただし、タリーズコーヒーによる説明と、それに基づく専門家の分析によれば、今回のインシデントは、ECサイトシステムの他の脆弱性をついて不正に侵入され、slick.min.jsを改ざんされたことが原因とのことですので、slick.min.js自体の脆弱性をついたものではないようです。

このslick.min.jsを改ざんにより、入力画面でECサイトのユーザーが入力した情報（クレジットカード情報を含む）が、そのまま外部サーバーにも送信された可能性があるとのことです。

タリーズオンラインストアのケーススタディとして狙われた理由を考察すると、確かに次のような点で攻撃対象として選ばれやすかったのではないかと思います。

①slickがメジャーなプラグインであり利用者が多く、公式でのバージョンアップがほぼ停止しており、クレジットカードの入力画面にも読み込まれていたこと

利用者が少ない技術体系の攻略は費用対効果にすぐれない為、利用者が多いプラグインは狙われやすい傾向にあります。

また、頻繁にバージョンアップがされるプラグインは、新しいバージョンがリリースされれば攻撃コードが上書きされることで影響が短期間となる可能性があることから、バージョンアップが止まっているプラグインは狙われやすい傾向にあります。

slickの利用者数は正確にはわかりませんが、当社の感覚としては、他社が制作したサイトにはかなりの確度で使用されているという認識であり、超メジャープラグインであることは間違いありませんし、slickの更新が数年間とまっていたことは前述のとおりです。

なお、あくまで個人的な見解ですが、slick.min.js がクレジットカードの入力画面にも読み込まれていたことも要因として大きいと思います。
もし fancyapps.js が読み込まれていたら fancyapps.js が改ざんされていたのではないでしょうか。

今回はslick.min.js自体の脆弱性をつかれたわけではないようですが、マルウェアを埋め込む対象としても同様のことが言えます。

②タリーズオンラインストアにおけるセキュリティ意識が低く保守体制に不備があること

実はセキュリティ意識の低いサイトは、一定以上の知識を持つ攻撃者から見て一目瞭然です。
セキュリティ対策の初歩として、「狙われ難くする」ことが大切だと考えておりますが、サイトのセキュリティ対策が不十分であると宣伝していては、不要な攻撃を招き寄せてしまいます。

タリーズオンラインストアですが、5月に察知していて、2024年11月25日段階でいまだjQueryのバージョンが2.2.4（既知の脆弱性あり）のまま放置というのは…セキュリティ意識が低いと言われても仕方のない状況かもしれません。
※jQuryの脆弱性については、「jQueryのバージョン情報とサポート期限」をご覧ください。

これだけの情報でも、少なくとも「フロントエンド側の保守がされていないか不十分な意識・体制である」という情報が攻撃者に伝わってしまいます。

現場で対応が難しい事情があることは理解しますが、少なくとも今回はjQueryベースのプラグイン（slick）が改ざんされたのだから、jQueryについても既知の脆弱性が見つかっていないバージョン（3.5.0以上、最新は3.7.1）に更新しておく方が、保守体制を整えたことを示す意味でもよいと思います。

近年のサイバー攻撃はフロントエンドから攻略されるケースが増えており、タリーズコーヒーの一ファンとしては、今回の事件を教訓にして保守体制を整備してほしいと願うばかりです。

まず、上記のようにslick.min.js自体にも、狙われやすい理由があると考えておりますし、slick.min.jsをお使いの場合には、同様の手口で改ざんされていないかソースコードを一応確認された方がよいと思います。

同様の攻撃を受けていて気が付いていないだけという可能性もありますし、タリーズコーヒーの説明とは異なりますが、元々改ざんされたslick.min.jsが配布されていたという可能性もゼロとは言い切れません。

可能性は非常に低いと思いますが、それほど時間のかかることではありませんので、チェックだけはしておいてもよいかと思います。

狙われ難くするために、あるいは狙われても弾き返せるように保守をしっかりと行いましょう。

保守の基本はバージョンアップです。
脆弱性を見つけそれを潰すという地味な作業ですが、非常に重要です。

特に、フロントエンド側の保守については軽く見られる傾向がありますが、実際のサイバー攻撃はフロントエンドから攻略されるケースが増加していると感じています。
たまに企業のWeb担当の方に「当社ではサーバーには個人情報を置いていないので、そこまでする必要はないのでは…」と質問されますが、今回の事例はまさにサーバーに保存していないクレジットカード情報などが窃取されるというもので、教訓にすべき事例といえるでしょう。

また、前述のように、フロントエンド側も含めてしっかりとバージョンアップをしておくことは、攻撃対象になりにくくなるという点で予防策としても有効ですし、更新が頻繁になされれば、仮に改ざんをされても上書きによって影響時間を短くできる可能性があります。

なお、タリーズコーヒーの説明通り、サーバーへの侵入によってslick.min.jsの改ざんがされたのであれば、その侵入自体を防ぐことが第一ですので、それを防ぐ保守は重要であると言えます。
むしろ、サーバーへの侵入を許した時点で、その後の被害を防ぐことは非常に困難になりますので、通常のWebサイトの場合、サーバーへの侵入を防ぐことが最終防衛ラインのケースが多いと思います。

そのため、脆弱性を見つけて潰すだけでなく、アプリケーションへの攻撃を検出して止めるWAF(Web Application Firewall)を導入するもことは、昨今ほぼ必須と言ってよい状況です。

保守契約にフロントエンド側のバージョンアップまで含まれているか、WAFが導入されているか保守対象に含まれていないソフトウェアがないかを確認するとよいでしょう。

SRIは、ウェブページが外部リソース（JavaScriptやCSSファイルなど）を読み込む際に、ハッシュ値を突合することで、そのリソースが改ざんされていないことをブラウザ側で検証するためのセキュリティ機能であり、インシデント発生後、ネット上では、SRIを実装していれば、ブラウザがリソースの改ざんを検出し、実行を防ぐことができた可能性があるという意見もあります。

当社の見解としても、SRIを導入していれば、防げていた可能性はあると思います。

しかしながら、今回のタリーズコーヒーオンラインストアの件では、サーバー内に既に侵入されていますので、ハッシュ値の改ざんも可能だったのではないかと思います。
攻撃側の技術力と手順から見るに、今回のタリーズコーヒーオンラインストアの件では防げなかった確率の方が高いのではないかと考えております（あくまで当社の見解です）。

また、CSPはWebページが読み込むリソースのソースや実行方法を制御するためのセキュリティポリシーであり、主にクロスサイトスクリプティング（XSS）攻撃を防ぐために使用されます。

しかしながら、CSPの一般的な設定であるscript-src 'self'を設定している場合、同じオリジン（自社サーバー）から配信されるスクリプトは許可されますので、今回のように自社サーバー上にあるslick.min.jsはブロックできなかった確率が高いのではないかと考えております（あくまで当社の見解です）。

なお、CSPに関しては、connect-src で指定すればajaxの通信先ドメインを、form-actionで指定すればformのaction先のドメインを制御できるので、このような設定を適切に行えば外部にデータを送信（流出）することを防げた可能性はあります。
今回eval() 関数というセキュリティ的に注意が必要な関数の処理が使われていたようですが、これもCSPで防げた可能性がある部分になります(というよりデフォルトでは使用できないので、今回は攻撃側がeval() 関数を埋め込み、攻撃側がCSPの許可設定をしたのかもしれません。そうするとサーバーへの侵入はrootアカウントだったということになるかと思います。その場合はやはり流出を防ぐことはできなかったのかもしれません)。

専門家の皆さんの意見が一致しないのも仕方のない状況だったのかなと思います。

いずれにせよ、一般的なWebサイトの運用体制で、今回のように既にサーバーに侵入されてしまった場合に被害を食い止めるのが非常に困難であると思います。

ファイル改ざん検知システムは、Webサイトやサーバーのセキュリティを強化する重要な手段であり、同様にハッシュ値で改ざんを検知しますが、ファイル改ざん検知システムの場合、ハッシュ値を別サーバーに保管していることが通常ですので、今回のインシデントでも機能していたものと思われます。

ただし、一般的なファイル改ざん検知ツールだけでは、インシデントの検知と対策の初動を早くすることはできますが、被害をゼロにするのは難しいと思われますので、まずはサーバーへの侵入を許さないことが最も重要であると考えます。

前述のように、Slickは人気のあるプラグインであり、日本国内でも利用者は多数いるものと推察されます。

そして、今回のタリーズコーヒーオンラインストアのインシデントで原因がslick.min.jsにあったからといって、お使いのslick.min.jsがセキュリティ上の問題をかかえているということにはなりません。

しかしながら、前述のようにslick.min.js のソースコードは確認された方がよいと思いますし、更新が止まっているslickを使う以上、しっかりとした保守体制の構築やファイル改ざん検知ツールの導入などを検討された方がよいとも思います。