【視聴メモ】Securing Web Apps with Modern Platform Features (Google I/O ’19)

この記事は Google I/O '19 のセッションの視聴メモです。
想定読者は自分なので正確性や網羅率には問題があるかもしれません。

---

References

Speaker(s): Artur Janc, Lukas Weichselbaum

Abstract

Common vulnerabilities such as XSS, CSRF, and others have long plagued the web, accounting for most of the high-risk flaws reported under Google's Vulnerability Reward Program. Learn about the latest web platform security mechanisms to protect your apps from injections and isolate them from dangerous sites. You'll leave with a security checklist for defending your applications with new browser features based on Google Security Team's experience in protecting the web's most sensitive apps.

訳

XSSやCSRFなどのありがちな脆弱性は長きに渡ってWebを悩ませ、またGoogleのVulnerability Reward Programでも頻繁に報告されています。最新のWebプラットフォームにおけるセキュリティの仕組みを学んで、あなたのサービスをインジェクションからまもり危険なサイトから隔離しましょう。また、Webでもっともセンシティブなアプリを守っているGoogleのセキュリティチームの経験によって得られたブラウザの新機能によって、あなたのアプリケーションを守るためのチェックリストを知りましょう。

Contents

Common web secrurity flows

• Google Vulnerability Reward Program
• 発見された脆弱性の半分はWebに関するもの
• というかXSSとCSRFがほとんど

Web platform security features

injection対策

• つまりXSS対策
• CSP: Content Security Policy
  • XSSへの対策として、どのスクリプトが実行可能か、どのプラグインがロード可能かを指定する
  • HTTPリクエストのレスポンスヘッダーでContent-Scurity-Policyを設定する
  • Content-Security-Policy-Report-Onlyでレポートするだけで実行できるようにすることもできる
  • 今どきのサイトだとCSPの設定はとても難しく下図のようになってしまう
    • 読めないしメンテナンスできないしバイパスされてしまう（？）

• nonce-based CSP
  • CSPヘッダーにscript-src 'nonce-...' 'strict-dynamic'を指定する
  • nonceのついたscriptタグしか実行されなくなる
  • nonceをリクエストごとに変更すれば攻撃者は予測できない
  • だが動的にサードパーティーのスクリプトを読み込みたいときはどうする？
• CSP3ではstrict-dynamicキーワードが実装された
• nonceのついたスクリプトから生成されたスクリプトは実行可能になる
• 具体的にどうやってCSPを導入するか
  • STEP 1: onclickやhrefで指定されるインラインイベントハンドラーをなくす
  • STEP 2: サーバーサイドテンプレートにてnonceを指定する
  • STEP 3: レスポンスヘッダーでCSPを指定する
    • Googleではunsafe-evalを指定していることも多いがなくしたほうが良い
    • strict-dynamicも必要がなければなくす
• 詳細は csp.withgoogle.com
• Over 60 dangerous DOM APIs ↓

• Trusted Types
  • innerHTMLなどが Trusted* というオブジェクトしか受け付けなくなる
  • こちらもCSPで指定し、内容は trusted-types
    • レポートモードもある
  • element.innerHTML = location.hash.slice(1); が動かなくなる
  • TrustedTypes.createPolicyでポリシーオブジェクトを作成し、それが持つcreateHTMLなどのメソッドでTrustedオブジェクトを生成する
  • default ポリシーはstringが割り当てられたときのfallbackとして機能する
  • サニタイズの処理をポリシーオブジェクトに集約できるのが嬉しい
• 詳しくは bit.ly/trusted-types

isolation対策

• つまりCSRF対策
• まずは言葉の定義について
  • same-origin: 同じスキーマ、ホスト、ポートを持ったサイト同士のこと (https://www.google.com/foo, https://www.google.com/bar)
  • same-site: 同じスキーマとドメインを持ったサイト同士のこと (https://mail.google.com/, https://photos.google.com/)
  • cross-site: その他 (https://www.youtube.com/, https://www.google.com/)
• Sec-Fetch-Site と ｀Sec-Fetch-Mode` ヘッダー
  • fetchリクエストを送ったりするときにブラウザがつける
  • same-originかどうかやcorsモードかどうかがわかる
• ヘッダーがどういうときにリクエストを受け付ければいいか（下図）

• SameSite cookies
  • Set-Cookie ヘッダー
  • 他のサイトにcookieを送る必要がなければ指定する
• Cross-Origin Opener Policy
  • same-originでもsame-siteでもないサイトによってwindow.openされたページは参照を取れなくなる

発表全体のまとめ（下図）
わかりやすい

Memo

• Webセキュリティの基本的な話（XSSとはなにかみたいな）から始まるので退屈な気がするけど、後半はそれらに対する最新の対策方法についてわかりやすくまとめられていてためになった