Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Webセキュリティと W3CとIETFの仕様

3,737 views

Published on

個人的に気になってる、W3CやIETFで議論されてる仕様を紹介

Published in: Technology
  • Be the first to comment

Webセキュリティと W3CとIETFの仕様

  1. 1. Webセキュリティと W3CとIETFの仕様 Shibuya.XSS techtalk #9 @flano_yuki
  2. 2. 自己紹介 - ゆき ( @flano_yuki ) - 趣味でW3CとIETFの仕様を読んでブログに書いてる - IETFはオフラインミーティングに数回参加 - たまに脆弱性報告したり (CVE番号発行:1件) - 本業はインフラエンジニア @flano_yuki
  3. 3. 今日お話すること - 個人的に気になってる、W3CやIETFで議論されてる仕様を紹介します - 仕様は策定中のものです、大いに変わる可能性があります - 標準化に至らないものや、実装されないものもあるでしょう (紹介しきれないものも沢山あります) 標準化というと敷居が高そうですが、少しでも楽しそうと思って頂ければ幸いです。 興味ある人、詳しい人いましたら、是非お声がけください><;
  4. 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. 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. 6. W3Cの仕様紹介
  7. 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. 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. 9. Clear Site Data (3つめ) サーバから、クライアントのCookieやキャッシュをクリアできるようにする仕様 不要なデータは消しておきたいが、覚えておくのは難しかった Clear-Site-Data: domStorage cookies executionContexts cache; includeSubdomains 消せるもの - domStorage - cookies - cache - executionContexts
  10. 10. Suborigins (4つめ) 同一オリジンで複数のアプリケーション提供される場合がある(google mapとか)一つの オリジンでも、サブオリジンを指定し別オリジンとして扱えるようにする HTTPヘッダでsuboriginを指定 HTTP/1.1 200 OK … suborigin: testing Access-Control-Allow-Suborigin CORS時の許可
  11. 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; 1. https://で非httpsのリソースを読み 込もうとする 2. HEADリクエスを送る 3. HSTSのヘッダが付いてきたら、 HTTPSでアクセスし直すので、 Mixed Contentsによるブロックを回避できる
  12. 12. CORS and RFC1918 (6つめ) パブリックなネットワークから、ローカルネットワークへのCSRFをできないようにする。 CORSのpreflightのように、Access-Control-Allow-Externalをつけて明示的に許可す る 。
  13. 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. 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. 15. IETFの仕様紹介
  16. 16. Cookie Prefixes (1つめ) - Cookieについてる属性を確かなものにする - 共有されているCookieについてる属性はサーバ側から確認できない - プレフィックスに対応する属性がついてることが保証される Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com - __Secure: Secure属性がついてること - __Host: Domainが指定され、Pathが “/”
  17. 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. 18. Deprecate modification of 'secure' cookies from non-secure origins (3つめ) Secure属性のあるCookieを、非セキュアなページから上書きできないようにする - https://example.com で、secure属性の付いたCookieを発行したあと - http://example.comから、同名のCookieで上書きできないようにする
  19. 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. 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. 21. おわり
  22. 22. Token Binding over HTTP - CookieやOAuthトークンといった物を、本人しか使えないようにできる - TLS Exported Keying Material より生成された鍵で署名することで、その鍵を持っ てる人以外が使えないようになる OAuthなどでの利用が議論されているが、単純にCookieなどでも利用できる
  23. 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. 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属性

×