Upcoming SlideShare
Webセキュリティと W3CとIETFの仕様
- 1. Webセキュリティと W3CとIETFの仕様 Shibuya.XSS techtalk #9 @flano_yuki
- 2. 自己紹介 - ゆき ( @flano_yuki ) - 趣味でW3CとIETFの仕様を読んでブログに書いてる - IETFはオフラインミーティングに数回参加 - たまに脆弱性報告したり (CVE番号発行:1件) - 本業はインフラエンジニア @flano_yuki
- 3. 今日お話すること - 個人的に気になってる、W3CやIETFで議論されてる仕様を紹介します - 仕様は策定中のものです、大いに変わる可能性があります - 標準化に至らないものや、実装されないものもあるでしょう （紹介しきれないものも沢山あります） 標準化というと敷居が高そうですが、少しでも楽しそうと思って頂ければ幸いです。 興味ある人、詳しい人いましたら、是非お声がけください＞＜；
- 4. Overview W3C - W3C - Web Apprication Security WG (WebAppSec) - CSP Level 3 - CSP Embedded Enforcement - Clear Site Data - Suborigins - Web Incubator CG (WICG) - HSTS Priming - CORS and RFC1918 - Isolated Origins - Origin Policy
- 5. Overview IETF - IETF - Httpbis WG - Cookie Prefixes - Same-Site Cookies - Deprecate modification of 'secure' cookies from non-secure origins - sunset4(?) - Let 'localhost' be localhost. - etc,,,
- 6. W3Cの仕様紹介
- 7. Content Security Policy Level 3 (1つめ) - CSPの最新仕様、幾つかの機能追加など (13項目の変更点) - http://example.com:80 表記が、https://example.com:443 にもマッチ - strict-dynamic - 指定：Content-Security-Policy: script-src 'nonce-DhcnhD3khTMePg...' 'strict-dynamic' - <script src="https://example.com/script.js" nonce="DhcnhD3khTMePg..." > - disown-opener - window.openerをnullにする。他のブラウジングコンテキストから制御さ れないようにする - navigation-to - ドキュメントがa, form, window.locationなどでナビゲーションできるURL を制限する - report-sample - CSPに違反したスクリプトの内容を、Report APIで投げる
- 8. CSP Embedded Enforcement (2つめ) 埋め込む側が、iframeの中のコンテンツにCSPをつけるように要請する a-example.comがiframeで b-example.comを埋め込んでいる 1. HTMLを取得する 2. HTMLのiframeにcsp attributeが ついてる 3. ブラウザは、そのポリシーを Embedding-CSPヘッダにつけて送 信する 4. Embedding-CSPで指定された、ポ リシーをCSPで指定する
- 9. Clear Site Data (3つめ) サーバから、クライアントのCookieやキャッシュをクリアできるようにする仕様 不要なデータは消しておきたいが、覚えておくのは難しかった Clear-Site-Data: domStorage cookies executionContexts cache; includeSubdomains 消せるもの - domStorage - cookies - cache - executionContexts
- 10. Suborigins (4つめ) 同一オリジンで複数のアプリケーション提供される場合がある(google mapとか)一つの オリジンでも、サブオリジンを指定し別オリジンとして扱えるようにする HTTPヘッダでsuboriginを指定 HTTP/1.1 200 OK … suborigin: testing Access-Control-Allow-Suborigin CORS時の許可
- 11. HSTS Priming (5つめ) Mixed Contentsでブロックする前に、該当リソースへHEADリクエストしてHSTSヘッダ がついていれば、httpsでアクセスする。 <script src="http://origin-b/widget.js"></script> HEAD / HTTP/1.1 Host: origin-b ... HTTP/1.1 200 OK ... Strict-Transport-Security: max-age=10886400; １. https://で非httpsのリソースを読み 込もうとする 2. HEADリクエスを送る 3. HSTSのヘッダが付いてきたら、 HTTPSでアクセスし直すので、 Mixed Contentsによるブロックを回避できる
- 12. CORS and RFC1918 (6つめ) パブリックなネットワークから、ローカルネットワークへのCSRFをできないようにする。 CORSのpreflightのように、Access-Control-Allow-Externalをつけて明示的に許可す る 。
- 13. Isolated Origins (7つめ) セキュリティ要件の高いサイトを、悪意あるページなど、他のオリジンから隔離する仕様 - HTTPヘッダで「Isoration = 1」を受け取ると、UAは以下のように動作する - Content-Security-Policy：frame-ancestors 'self'が各リソースで設定されてい るかのように動作する - window.topまたはwindow.parentへアクセスできない - 各リンクとopen()でnoopenerが指定されたかのように動作する - same-site cookies が指定されたかのように動作する - isolated originへのナビゲーションは通常失敗する allowIsolatedNavigation() - 実行プロセスを分ける（実装次第）
- 14. Origin Policy(8つめ) オリジン全体にポリシーを適応できるようにする仕様 HTTPヘッダでポリシー名を指定し、規定の場所にポリシーを置いておく HTTP/1.1 200 OK … Sec-Origin-Policy: "policy-1" { "headers": [ { "name": "Content-Security-Policy", "value": "script-src 'self' https://cdn.example.com", "type": "fallback" }, { "name": "Referrer-Policy", "value": "origin-when-cross-origin", "type": "fallback" } …. https://example.com/.well-known/origin-policy/policy-1HTTPレスポンス (サイト全体にヘッダを適用する汎用的な仕 様も Site-Wide HTTP Headers )
- 15. IETFの仕様紹介
- 16. Cookie Prefixes (1つめ) - Cookieについてる属性を確かなものにする - 共有されているCookieについてる属性はサーバ側から確認できない - プレフィックスに対応する属性がついてることが保証される Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com - __Secure: Secure属性がついてること - __Host: Domainが指定され、Pathが “/”
- 17. Same-Site Cookies (2つめ) - Same-Siteへのリクエスト時にのみ提出されるようにする、”Same-Site” 属性 <html> <title>csrf</title> <img src=”example.com” > </html> attacker.com このリクエストに Cookieが付かない example.com Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict - Strict、クロスサイトのリクエストをブロック - Lax、GET,HEAD,OPTIONSかつ top-level browsing context のとき
- 18. Deprecate modification of 'secure' cookies from non-secure origins (3つめ) Secure属性のあるCookieを、非セキュアなページから上書きできないようにする - https://example.com で、secure属性の付いたCookieを発行したあと - http://example.comから、同名のCookieで上書きできないようにする
- 19. Let 'localhost' be localhost. (4つめ) localhost をループバックアドレスにする仕様 - 現状、W3Cのsecure contextの仕様は、”127.0.0.1” or “::1/128” - secure contextで “localhost” をsecure contextにしたいというモチベーション - 一方、RFC6761の仕様は”localhost”に対して、ループバックアドレスを返すことは SHOULDとなってる（MUSTではない） - “localhost”がループバックアドレスを返す事を”MUST”に変更する仕様
- 20. おわりに それぞれ、最新仕様の追いかけ方 - W3C - Mailing List: https://lists.w3.org/Archives/Public/public-webappsec/ - リポジトリ - https://github.com/w3c - https://github.com/wicg - ブラウザのセキュリティ系Mailing Listもおすすめ - 今日紹介したものは、だいたい GoogleのMike West氏が書いてる。アクティビティ要チェック - IETF - Mailing List: https://lists.w3.org/Archives/Public/ietf-http-wg/ - リポジトリ: https://github.com/httpwg
- 21. おわり
- 22. Token Binding over HTTP - CookieやOAuthトークンといった物を、本人しか使えないようにできる - TLS Exported Keying Material より生成された鍵で署名することで、その鍵を持っ てる人以外が使えないようになる OAuthなどでの利用が議論されているが、単純にCookieなどでも利用できる
- 23. CSP Pinning (非アクティブ) - ページ毎に毎回 CSPヘッダを送信しなくて良くする仕様 (not active) Content-Security-Policy-Pin: max-age: 10886400; includeSubDomains; default-src https:; referrer no-referrer; report-uri /csp-endpoint/pinned
- 24. CSP Cookie Controls (非アクティブ) - Cookieの属性をCSPで制限をかける (not active) Content-Security-Policy: cookie-scope host secure - host: “host only” - http: http only - none: すべてのcookieをブロック - secure: secure属性
Login to see the comments