Service WorkerとXSS(Cross-site scripting)について
はじめに
こんにちは。株式会社SHIFT DAAE（ダーエ） Tグループの栗山です。
本稿のテーマはSerivce WorkerとXSSです。
Service Workerはとても便利な技術です。例えば、ブラウザ上で動作するアプリケーションを、スマートフォン上で動作するアプリケーションのようにオフラインでも利用可能にするといったことができます。
そんな便利なService Workerですが、便利な反面、セキュリティのリスクも大きくなります。Service Workerを利用しておらずとも、Service Workerを狙った攻撃を受ける恐れがあります。またService Workerが乗っ取られると、通常のXSS攻撃を受けた場合よりも深刻な状態になります。
また恐ろしいことに「Service WorkerはメインのWEBアプリケーションとは別スレッドで動作するためXSS攻撃を受けることがなく安全である」といった誤解もネット上で見られます。
ぜひ本稿をご一読いただき、Service Workerのリスクをご認識頂けたらと思います。
Service Workerとは
Service Worker はメインのWEBアプリケーションと別スレッドで動作し、そのWEBアプリケーションとAPIとの間のProxyとして動作します。キャッシュを保持したり、メインのWEBアプリケーションが閉じられている間も動作できたり、プッシュ通知ができたりします。
こういった機能により、ブラウザ上で動作するWEBアプリケーションを、スマートフォン上で動作するアプリケーションのようにオフラインでも利用可能にすることができます。
Service Workerに対するXSS攻撃
ではさっそくService Workerを狙ったXSS攻撃を紹介します。以下はHackTricksというWEBサイトに記載がある既知の攻撃パターンです。
Service Workerを新規にインストール、あるいは既存のService Workerを上書きすることで攻撃を行います。メインのWEBアプリケーションのXSS脆弱性を利用します。
Service Workerを使用しておらずともこの攻撃を受ける恐れがあります。
この攻撃を受ける条件として「攻撃者がファイルアップロードできること」「攻撃者が内容を設定できるJSONPエンドポイントがあること」があります。実装を誤るとこういった状況になります。
Abusing importScripts in a SW via DOM Clobbering
Service Worker から呼び出されるimportScriptsで悪意のあるプログラムを読み込ませる攻撃です。
この攻撃ではCSP設定が回避されてしまいます。
これらの攻撃はともにService Workerを乗っ取るものです。
Serivce Workerが乗っ取られると、通常のXSS攻撃を受けた場合よりも深刻な状態になります。Service Workerをインストールし直すか、ユーザーが意図的にService Workerを消さない限り、乗っ取られたService Worker上で悪意のあるコードが動き続けるからです。
そのほかにも「ネットワークトラフィックを中継する」ことや「プッシュ通知する」といったSerivce Workerが持つ機能が危険性を大きくします。
こういったことを詳しく知りたい方はSecurity Study of Service Worker Cross-Site Scripting の「4.1 Motivation」がおすすめです。
Service WorkerのXSS対策
ではService WorkerのXSS対策を記します。
メインのWEBアプリケーションでXSS対策を行うこと。
これは変わりません。Service Workerの登場により、XSS攻撃を受けた場合の被害がより深刻化したといえます。
Service Workerを使用しておらずとも、Service Workerを狙った攻撃を受ける恐れがあるため注意してください。
メインのWEBアプリケーションのXSS対策は、Reactなどの一般的なフレームワークを利用することで可能です。
Service WorkerでXSS対策を行うこと。
Service WorkerのXSS対策は、メインのWEBアプリケーションと異なり、フレームワークを使えば済むわけではありません。ちゃんと調べて対策しましょう。
navigator.serviceWorker.registerやimportScripts といった脆弱性のある関数を使用する際は、読み込む値をチェックし、正しいものしか読み込まれないようにする。
数年前まではSerivice Workerの脆弱性はほとんど知られていなかったようです。今後上記以外にも対策が必要になるかもしれません。Service Workerを使用する場合はその時点で必要なセキュリティ対策を調べ導入しましょう。
Service Workerを使用する場合は、Service Workerに関係する最新の脆弱性情報や対策方法を常にキャッチアップすること。
(上記と内容がかぶりますが)Service Workerは新しい技術であるため、新しい脆弱性が見つかる可能性が高いといえます。また今後Service Workerに対する機能追加により、新たな脆弱性が産まれる恐れもあります。そのためSerivce Workerを使用する場合は、脆弱性や対策について常にキャッチアップする必要があるでしょう。
適宜「新しい技術なので導入を見送る」といった判断をすること。
新しい技術はリスクも大きいです。状況によっては「導入を見送る」といった判断も必要でしょう。
「Service Workerは安全である」という誤り
怖いことに「メインのWEBアプリケーションと別のスレッドで動作するため、Service WorkerはXSS攻撃を受けない」といった記載がネット上には存在します。
本稿の内容の通り、これは誤りですので気を付けましょう。Serivce Workerを攻撃するための条件は厳しいですが、XSS攻撃を受けないわけではありません。
最後に
Service WorkerはWEBアプリケーションの可能性を広げます。セキュリティ対策が大変だからと言って、避けることはできないでしょう。枯れるまではまだ時間がかかるでしょうから当面は調査が大変そうです。
＼もっと身近にもっとリアルに！DAAE 公式 X／
執筆者プロフィール：Kuriyama Akira
眠らないのダメ、絶対。
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO：UnsplashのMarkus Spiske