Upload
yuki-f
View
1.251
Download
0
Embed Size (px)
Citation preview
WebセキュリティとW3CとIETFの仕様
Shibuya.XSS techtalk #9
@flano_yuki
自己紹介
- ゆき ( @flano_yuki )- 趣味でW3CとIETFの仕様を読んでブログに書いてる
- IETFはオフラインミーティングに数回参加
- たまに脆弱性報告したり (CVE番号発行:1件)- 本業はインフラエンジニア
@flano_yuki
今日お話すること
- 個人的に気になってる、W3CやIETFで議論されてる仕様を紹介します
- 仕様は策定中のものです、大いに変わる可能性があります
- 標準化に至らないものや、実装されないものもあるでしょう
(紹介しきれないものも沢山あります)
標準化というと敷居が高そうですが、少しでも楽しそうと思って頂ければ幸いです。
興味ある人、詳しい人いましたら、是非お声がけください><;
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
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,,,
W3Cの仕様紹介
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で投げる
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で指定する
Clear Site Data (3つめ)サーバから、クライアントのCookieやキャッシュをクリアできるようにする仕様
不要なデータは消しておきたいが、覚えておくのは難しかった
Clear-Site-Data: domStorage cookies executionContexts cache; includeSubdomains
消せるもの
- domStorage- cookies - cache- executionContexts
Suborigins (4つめ) 同一オリジンで複数のアプリケーション提供される場合がある(google mapとか)一つの
オリジンでも、サブオリジンを指定し別オリジンとして扱えるようにする
HTTPヘッダでsuboriginを指定
HTTP/1.1 200 OK…suborigin: testing
Access-Control-Allow-Suborigin
CORS時の許可
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によるブロックを回避できる
CORS and RFC1918 (6つめ)パブリックなネットワークから、ローカルネットワークへのCSRFをできないようにする。
CORSのpreflightのように、Access-Control-Allow-Externalをつけて明示的に許可す
る 。
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()
- 実行プロセスを分ける(実装次第)
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 )
IETFの仕様紹介
Cookie Prefixes (1つめ)- Cookieについてる属性を確かなものにする
- 共有されているCookieについてる属性はサーバ側から確認できない
- プレフィックスに対応する属性がついてることが保証される
Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com
- __Secure: Secure属性がついてること
- __Host: Domainが指定され、Pathが “/”
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 のとき
Deprecate modification of 'secure' cookies from non-secure origins (3つめ)
Secure属性のあるCookieを、非セキュアなページから上書きできないようにする
- https://example.com で、secure属性の付いたCookieを発行したあと
- http://example.comから、同名のCookieで上書きできないようにする
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”に変更する仕様
おわりに
それぞれ、最新仕様の追いかけ方
- 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
おわり
Token Binding over HTTP- CookieやOAuthトークンといった物を、本人しか使えないようにできる
- TLS Exported Keying Material より生成された鍵で署名することで、その鍵を持っ
てる人以外が使えないようになる
OAuthなどでの利用が議論されているが、単純にCookieなどでも利用できる
CSP Pinning (非アクティブ)- ページ毎に毎回 CSPヘッダを送信しなくて良くする仕様 (not active)
Content-Security-Policy-Pin: max-age: 10886400; includeSubDomains; default-src https:; referrer no-referrer; report-uri /csp-endpoint/pinned
CSP Cookie Controls (非アクティブ) - Cookieの属性をCSPで制限をかける (not active)
Content-Security-Policy: cookie-scope host secure
- host: “host only”- http: http only- none: すべてのcookieをブロック
- secure: secure属性