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

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,,,

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.1
Host: origin-b
...
HTTP/1.1 200 OK
...
Strict-Transport-Security: max-age=10886400;
１. 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 )

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属性

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (20)

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

Similaire à Webセキュリティと W3CとIETFの仕様 (20)

Dernier

Dernier (9)

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