pwa_study - connpassに参加してきたのでメモ。

用語

• SW = Service Worker
• XSS = cross site scripting
• Fetch = Fetch API

ウェルカムLT

• クライアントサイドDDDが行われるようになってきた
• クライアントサイドにロジックが寄ってきてる
  • 難しい
• Service Workerもクライアントサイドにそういうロジックや仕組みがよってきたという現象の一つなのでは

Service Worker Lifecycle - laco

スライド: Service Worker Lifecycle by Suguru Inatomi

• SWのライフサイクル
• Service Worker のライフサイクル  |  Web  |  Google Developers これよめば大体分かる
• スライド -> 記事読むと良い
• register -> redundantで死ぬ
  • ライフサイクルであるけど一方向
• SWの目的
  • オフラインファースト
  • セーフマイグレーション
  • consitency(SWないとタブごとに異なる感じになってしまう。SWは1つのアプリケーションに対して1つ)
• Window-side API
  • Workerを使う側
  • SWを登録する register
  • SWを更新する update
  • SWを停止する unregister
• Install SW
  • registerが終わった段階ではSWはまだコントールできない
    • active ではある
  • リロードした後 コントロール できる状態になる
  • registerした段階ではfetchなどをhookすることができない
• なぜこのような仕様になっているか
  • SWのconsitency
  • タブ間での一貫性を保証する
  • あるタブだけSWがコントロールできてない状態を作らない
• 抜け道がある
  • clients.claim()
  • すぐにコントール状態にできる
  • Clients.claim() - Web API インターフェイス | MDN
  • claimsもある
  • 一貫性を求めるので
    • やらない or すべてやる(すべてのタブに対してやる)
• Update SW
  • 取ってきたsw.jsとdiffをとって、hash値が異なるなら新しいworkerとして作られる
  • ハッシュが異なるときは、waitingになる = コントールはできない状態
  • 全部のタブのSWが新しくなったらコントール状態になる = waiting解除
• これも抜け道がある
  • skipWaiting()
  • waiting時にskipWaiting()するとすぐにactivateになる
  • Warning: 裏で動いているWorkerがリロードなしにすり替わる
• ユースケース
  • clients.claim()
    • 最初からSWを有効化できる
  • clients.skipWaiting()
    • 壊れたsw.jsをデプロイしてしまって、そのバグを修正したバージョンを出す時
    • postMessageとかを使ってwindowからHot Updateみたいなことをやるとき
• active vs. controller
  • window-side
    • controllerがあるかどうか
  • worker
    • worker stateだけを見てる
  • controllerであるworker === activeであるworker
• まとめ
  • registerだけではSWはcontrollにならない
  • すべてのタブが閉じないとSWはcontrollにならない
  • claimですぐに取ることはできるけど
  • skipWaitingは気をつけて使いましょう
• FAQ
  • redundantしたときすぐregisterすると死んだと思ったworkerが復活する
  • active かつ un-controllerの場合でもmessageは受け取る
    • fetchなどはhandkingできない
  • clients.skipWaiting()
    • ページがコントールしてるSW、activeなSWが切り替わる

攻撃者視点で見る Service Worker - kinugawamasato

スライド: 攻撃者視点で見るService Worker / PWA Study SW // Speaker Deck

• SWを使うと攻撃者は何ができるのか
  • SWを登録して攻撃
  • アプリが使ってるSWを攻撃
• アプリ開発者の防御方法
• SWのスクリプトを次の条件を満たす必要がある
  • same origin
  • secure context
  • context-typeがJavaScript
• Secure Context
  • HTTPSとかlocalhostなどのコンテキストが限定される
  • Geo
  • WebUSB
  • カメラとか
• Application Cacheは
  • SWの前身のキャッシュ
  • Secure Contextの実行制限がない
  • 攻撃シナリオを使って解説するApplicationCacheのキャッシュポイズニング | HTML5Experts.jp
  • Dropboxで公開ページの問題
    • Same origin
    • クッキーを大量に埋め込むとApp CacheのFallbackが発動して全滅
• 攻撃SWをつかうには
  • HTTPSなページでXSSをみつける
  • SWのスクリプトになりうる場所をみつける
    • content-type: text/javascript
• 都合のいい場所1: JSONP
  • JSONのsw.jsの内容を書いて
  • それをregisterで登録する
• 登録できるとどうなるか
  • XSSの永続化
    • XSSが修正されても継続する
  • リクエスト/レスポンス内容の盗聴・変更
• XSSの永続化
• SWのスコープ
  • SWはscopeがディレクトリ以下のcontrollできるかを設定できる
  • Service-Worker-Allowedで設定もできる
  • サーバの設定によっては %2F のようにエンコードしたパスを登録できないようになってる(仕様で%2fなどは禁止されている)
  • Service Workers 1
• 登録後のスコープ
  • /..%2fout%2fと/out/は同一されて、SWは禁止されてない
  • 登録時はかなり厳しくなってる
• SWは前回取得してから24時以上経ってると、SW起動時にHTTPキャッシュを無視して再取得する仕様がある
• 検証
  • Firefox/Chromeは24時間以上で再取得が起きる
  • 404などで取得できなければ元のSWを使い付ける
  • 不正なSWを登録されることを防ぐ目的であって、永続化を防ぐものにはなってなかった
• XSS x SW x Flash
  • swfのページに直接アクセス + SWで不正なSWFを返す
  • Flashは crossdomain.xml でクロスドメイン管理されてる
  • SWで作ったFlashからもcrossdomain.xmlにリストされたサイトの読み取りができる
  • => embed仕様では制限すぐべきと書いてあってある
    • embedとかobjectは制限されてる
    • URLに http://example.com/attack.swf
• Foreign Fetch
  • 外部サイトでXSSができる
  • 夢が広がる危ない仕様だった
    • SWの登録しやすさいに比べて危険
  • しかし、Foreign Fetchは廃止予定
  • Remove foreign fetch · Issue #1188 · w3c/ServiceWorker
• SWのキャッシュ
  • SWのキャッシュ != HTTPキャッシュ
  • 正規に登録されていたSWを悪用する
  • fetchされたURLのキャッシュがあれば、キャッシュを常に返すSWがある時
  • XSSがあれば、キャッシュを汚染して攻撃コードのキャッシュを返すことができる
  • localStorageのXSSに似てる
• SWを削除する
  • unregister
  • Clear-Site-Dataで消せる
    • w3c/webappsec-clear-site-data: WebAppSec Clear Site Data
  • けど、これも一度登録されたそこまで届かない
• SWは登録された負け
  • SWは前回取得してから24時以上経ったときに、404であるならunregisterする仕様になっていれば永続化は避けられて良さそうな気がする

Foreign Fetch - jxck

• Foreign Fetch
  • オフライン対応をサイト全体をやろうという話なったらサードパーティも全部オフライン対応しないといけない
  • それはつらい
  • なので、各サービスがそれぞれオフライン対応のSWを公開してくれて
  • ファーストパーティは自分のサイトだけ、サードパーティはサードパーティの対応するだけで良くなるという仕様
  • => 駄目だった
  • Remove foreign fetch · Issue #1188 · w3c/ServiceWorker
• 理由: SafariのIntelligent Tracking Prevention | WebKit
  • 今までクッキー
    • ドメインに紐付いている
  • この変更
    • 今見てるページとサードパーティのドメインの2つをキーにする
    • host+3rdparty
    • つまり見てるページが異なれば、サードパーティが同じでも異なるキーとなる
• SWの責務分離
  • パスでしか責務を分けれない
• Foreign Fetchは代案がないと死ぬ

Asking for SW Motivation - @constellation

• Service Workerに懐疑的
  • ウェブページのライフサイクルを壊す可能性がある
  • バッテリーを食う可能性がある
• モチベーション
  • ネイティブアプリでは駄目なの?
    • App Storeのディストリビューションの問題?
  • Electronみたいなアプリを作る方向ではないの?
  • アプリケーションでできないことブラウザでできるようになるの?
• 議論 色々
  • 「ウェブは二回目のエンゲージメントを得るのが難しい。」
  • 「だからPush通知が欲しい」
  • 続きは #pwa_study - Twitter Search で