24
Webセキュリティと W3CIETFの仕様 Shibuya.XSS techtalk #9 @flano_yuki

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

  • Upload
    yuki-f

  • View
    1.251

  • Download
    0

Embed Size (px)

Citation preview

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

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

Shibuya.XSS techtalk #9

@flano_yuki

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

自己紹介

- ゆき ( @flano_yuki )- 趣味でW3CとIETFの仕様を読んでブログに書いてる

- IETFはオフラインミーティングに数回参加

- たまに脆弱性報告したり (CVE番号発行:1件)- 本業はインフラエンジニア

@flano_yuki

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

今日お話すること

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

- 仕様は策定中のものです、大いに変わる可能性があります

- 標準化に至らないものや、実装されないものもあるでしょう

(紹介しきれないものも沢山あります)

標準化というと敷居が高そうですが、少しでも楽しそうと思って頂ければ幸いです。

興味ある人、詳しい人いましたら、是非お声がけください><;

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

W3Cの仕様紹介

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

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で投げる

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

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で指定する

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

Clear Site Data (3つめ)サーバから、クライアントのCookieやキャッシュをクリアできるようにする仕様

不要なデータは消しておきたいが、覚えておくのは難しかった

Clear-Site-Data: domStorage cookies executionContexts cache; includeSubdomains

消せるもの

- domStorage- cookies - cache- executionContexts

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

Suborigins (4つめ) 同一オリジンで複数のアプリケーション提供される場合がある(google mapとか)一つの

オリジンでも、サブオリジンを指定し別オリジンとして扱えるようにする

HTTPヘッダでsuboriginを指定

HTTP/1.1 200 OK…suborigin: testing

Access-Control-Allow-Suborigin

CORS時の許可

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

HSTS Priming (5つめ)Mixed Contentsでブロックする前に、該当リソースへHEADリクエストしてHSTSヘッダ

がついていれば、httpsでアクセスする。

<script src="http://origin-b/widget.js"></script>

HEAD / HTTP/1.1Host: origin-b...

HTTP/1.1 200 OK...Strict-Transport-Security: max-age=10886400;

1. https://で非httpsのリソースを読み込もうとする

2. HEADリクエスを送る

3. HSTSのヘッダが付いてきたら、HTTPSでアクセスし直すので、Mixed Contentsによるブロックを回避できる

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

CORS and RFC1918 (6つめ)パブリックなネットワークから、ローカルネットワークへのCSRFをできないようにする。

CORSのpreflightのように、Access-Control-Allow-Externalをつけて明示的に許可す

る 。

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

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()

- 実行プロセスを分ける(実装次第)

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

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 )

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

IETFの仕様紹介

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

Cookie Prefixes (1つめ)- Cookieについてる属性を確かなものにする

- 共有されているCookieについてる属性はサーバ側から確認できない

- プレフィックスに対応する属性がついてることが保証される

Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com

- __Secure: Secure属性がついてること

- __Host: Domainが指定され、Pathが “/”

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

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 のとき

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

Deprecate modification of 'secure' cookies from non-secure origins (3つめ)

Secure属性のあるCookieを、非セキュアなページから上書きできないようにする

- https://example.com で、secure属性の付いたCookieを発行したあと

- http://example.comから、同名のCookieで上書きできないようにする

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

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”に変更する仕様

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

おわりに

それぞれ、最新仕様の追いかけ方

- 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

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

おわり

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

Token Binding over HTTP- CookieやOAuthトークンといった物を、本人しか使えないようにできる

- TLS Exported Keying Material より生成された鍵で署名することで、その鍵を持っ

てる人以外が使えないようになる

OAuthなどでの利用が議論されているが、単純にCookieなどでも利用できる

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

CSP Pinning (非アクティブ)- ページ毎に毎回 CSPヘッダを送信しなくて良くする仕様 (not active)

Content-Security-Policy-Pin: max-age: 10886400; includeSubDomains; default-src https:; referrer no-referrer; report-uri /csp-endpoint/pinned

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

CSP Cookie Controls (非アクティブ) - Cookieの属性をCSPで制限をかける (not active)

Content-Security-Policy: cookie-scope host secure

- host: “host only”- http: http only- none: すべてのcookieをブロック

- secure: secure属性