efclのブックマーク - はてなブックマーク

Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog

Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていくはじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限その他今回入らなかった機能はじめに Cookieの仕様は﹃RFC 6265: HTTP State Management Mechanism﹄として標準化されています。そのCookieの仕様の改訂版が﹃rfc6265bis﹄と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"

efcl 2024/05/11

Cookieの改訂版仕様 rfc6265bisについて

リンク

一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog

ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる﹁Dangerous Labels in DNS and E-mail﹂というdraftが提出されています。今回はそれを眺めていきます。︵あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。︶サブドメインここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

efcl 2022/07/04

DomainやDNSをユーザーに定義させるときに避けるもの一覧

domain
DNS

リンク

デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog

Blinkの開発者メーリングリストで﹁Intent to Prototype: Origin-Bound Cookies﹂という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。例オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht

efcl 2022/06/27

Cookieをoriginとデフォルトで紐付けるproposal。 Domainを指定した場合の挙動は、domainに紐づくので後方互換性を持っている。

リンク

CookieのPriority属性の仕様 - ASnoKaze blog

あまり知られていないがCookieにはPriority属性がある。 Chromeでは2013年に実装が入っている(該当コミット)、また提案仕様﹁A Retention Priority Attribute for HTTP Cookies﹂も2016年に提出されているが標準化には至ってない。ここらへんの議論は当時の"メーリングリスト"を参照してください。そんなPriority属性は、長年動きが無かったが、最近ChromeがデベロッパーツールでPriority属性を表示するようになった( Chrome Canary 81)。 (JavaScriptからPriority属性を指定して、Cookieを設定した例) 超簡単にだが仕様を紹介する。 Priority Attribute CookieのPriorityは保持優先度です。ブラウザが保存容量(ドメイン毎)の都合でCookieを消す場合は

efcl 2022/04/30

Cookieのpriority属性。消す順番を指定する

browser

リンク

新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog

新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等

efcl 2021/11/10

QUERYメソッド。パラメータに数値とか使う場合に便利そう

HTTP

リンク

ホスト名の最後が数字なURLの扱いについて - ASnoKaze blog

﹁WHATWG URL﹂の仕様で、ブラウザにおいて、ホスト名がIPv4でないが、数値で終わるURLは拒否されるように変更された。 github.com 例えば次のようなものです foo.0 bar.0.09 1.2.3.4.5 今まで、これらのホスト名は、その他のドメインと同じように、通常通り名前解決されます。Issueの起案者は、すでに具体的な攻撃があるわけではないとしつつも、紛らわしさや、eTLD+1 (same-site)の扱いの問題があるとのことです。なお、次のようなものはIPv4アドレスにマッピングされアクセスできます。 http://127.1 http://1.65793 Deprecate support for URLs with non-IPv4 hostnames ending in numbers 実際に、Chromeでは、そのような変更を入れる検討が始まっていま

efcl 2021/08/23

SSRFや`.`を含むパターンを弾く場合にXSSとかで使かわれるペイロード

リンク

FacebookのQUICを活用したライブ動画用プロトコルRUSHについて - ASnoKaze blog

Facebookの方々から﹁RUSH - Reliable (unreliable) streaming protocol﹂というプロトコル仕様が、IETFに提出されています。簡単に眺めていきます。 Facebookとライブ動画このRUSHはRTMP代替として、クライアント(配信者)のアプリからライブ動画を取り込むためのプロトコルのようです。Facebookではすでに使っているようです。 2018年頃のFacebookのエンジニアブログを見ると、Facebook Liveではクライアント(配信者)からの動画の取り込みに RTMPSを使っていることが紹介されています。おそらく、ココの部分を代替するのでしょう。視聴者へはCDNを通してMPEG-DASHで配信されるようです。また、IETFの投稿をみると、Facebookではアプリ及びインフラでこのプロトコルを使用していると述べています (

efcl 2021/07/19

over QUICなRTMP的なライブ配信のprotocolについて。 VideoとAudioのフレームごとにQUICのストリームを作ってHead of Line Blockingを避けることが目的。ライブなので、届かなかったフレームは捨ててスキップする。オンデマンド的なの

リンク

トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog

3rd パーティクッキーの廃止計画が世間を賑わせています。一方で、3rdパーティクッキーには、トラッキング目的でないユースケースもあります。それらのために、3rdパーティクッキーの制限を緩和する﹁Cookies Having Independent Partitioned State (CHIPS)﹂という仕組みが検討されています。この仕組みに則っていれば、制限のもと3rdパーティクッキーを使えるようになります。もちろん、これはトラッキングが出来ないようになっています。仕様: https://github.com/WICG/CHIPS Chromeの実装計画: ﹁Intent to Prototype: Cookies Having Independent Partitioned State (CHIPS)﹂ユースケースについては、仕様の中で述べられていますのでそちらを参照ください

efcl 2021/07/06

https://github.com/WICG/CHIPS について常にdoubled keyなサードパーティクッキー

リンク

ChromeのPartition Network Stateについて (Network State Partitioning) - ASnoKaze blog

Chrome 89で「Partition Network State」という機能の導入が検討されています。 chromestatus.com 「Client-Side Storage Partitioning 」のいち部であり、w3cのPrivacy CGで議論されています。これは、DNSキャッシュやHTTP/2のセッションといったネットワーク状態を、クロスサイトで共有できなくする機能です。情報は多くないようですが、眺めていきます。背景ブラウザ内全体でキャッシュ情報を共有していると、サイトAで読み込んだキャッシュを、サイトBを表示する際にも使用できます。この時サイトBではそのリソースの読み込みスピードを計測することで、キャッシュしてたかそうでないかが分かってしまいます。（読み込み速度はonloadイベント等で取得）例えば、https://a.example/js/hoge.js

efcl 2021/01/21

Partition Network State、Double-keyed cache

リンク

Cookieの新しい属性、SameParty属性について - ASnoKaze blog

ChromeでCookieのSameParty属性の開発が進められている (コミット)。現在のところ﹁SameParty cookie attribute explainer﹂に説明が書かれている。今回は、CookieのSameParty属性について簡単にメモしていく。背景トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。もともとは、First-Party Setsを活用しSameSite属性にFi

efcl 2020/12/14

SameParty属性について

リンク

CDNのキャッシュを制御する CDN-Cache-Control ヘッダ - ASnoKaze blog

CDNのキャッシュを制御する「CDN-Cache-Control」を新しく定義する提案仕様「The CDN-Cache-Control HTTP Response Header Field」が出ているので、簡単に紹介する。 2021/10/16 追記: 最新仕様では「Targeted HTTP Response Header Fields for Cache Control」と呼ばれるはじめに HTTPではキャッシュを制御するのにCache-Controlヘッダを使用しますが、クライアントとは別にCDNに対して個別にキャッシュの制御を行いたい場合もあります。その用途のために使用する「CDN-Cache-Control」を新しく定義しようというのが「The CDN-Cache-Control HTTP Response Header Field」です。この仕様は、Akamai, Fas

efcl 2020/11/26

CDN向けCache-Control。CDN-Cache-Control。 Surrogate-Controlヘッダー

cdn
proposal

リンク

POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog

はじめに HTTPリクエストには冪等なものと非冪等なものがあります。仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする

efcl 2020/11/19

POSTの冪等性

HTTP

リンク

ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog

ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。︵クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます︶そうすることで、ページの表示を効率化出来ると考えられていました。しかし、様々な議論の中

efcl 2020/11/14

HTTP/2のServer Pushの廃止と103 Early Hints

HTTP2

リンク

Permissions PolicyとDocument Policyについて - ASnoKaze blog

Chromeに、Permissions PolicyとDocument Policyという仕様の実装が進められています。今回は、ブラウザがwebページを表示する際に制限を与えるこれらの機能について説明していきます。仕様は下記から参照できます Permissions Policy Document Policy あわせて、blink-devメーリングリストのintentやexplainerを読むと分かりやすいかと思います Intent to Ship: Permissions-Policy header Intent to Ship: Document-Policy header これらはiframe先へのdelegationについて違いがあります (追記予定) Permissions Policy Permissions-PolicyはHTTPレスポンスヘッダで、ブラウザのカメラや位置

efcl 2020/10/05

AMP → Sandbox Policy → Feature Policy → Permissions Policy/Document Policy

browser
HTTP

リンク

HTTPと硬直化 (ossification) の問題 - ASnoKaze blog

「硬直化(ossification)」はあまり聞き慣れない言葉だが、インターネットやWebの通信において問題となってきています。新しい機能の展開を阻害するこの問題は、HTTPにおけても問題になっておりましたが、HTTPの標準化を行うIETFで動きがありました。 IETFのHTTP WGではオープンレターとして「HTTP and Web Application Firewalls: Managing Ossification Risk」を公開し、WAFベンダと連携してこの問題に取り組んでいく意思が示されています。この事に関して簡単に説明していきます目次硬直化(ossification) とは HTTPにおける硬直化(ossification) グリス (GREASE)の例 HTTPにおけるGREASE 硬直化(ossification) とは「硬直化(ossification)」

efcl 2020/07/16

新しい機能の展開を阻害する問題、ブロッキングとなる問題について。 HTTPのおけるossificationへの対策としてグリス (GREASE)を仕様として入れて、WAFなどで未来の仕様を壊れにくくする取り組みなど。 Structure Headerの問題など

HTTP
spec

リンク

HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog

この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである﹁QPACK ﹂について説明します。︵執筆時 draft 07︶ 2020/06/01追記まるっと解説記事を書き直しました asnokaze.hatena blog.com HTTP/2の場合ハフマン符号静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリングその他 QPACKという名称について HTTP/2の場合簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである﹁RFC7541 HPACK﹂について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD

efcl 2019/04/10

QPACKについて

HTTP3

リンク

リバースプロキシのエラーを示す Proxy-Statusヘッダの提案仕様 - ASnoKaze blog

CDNやクラウドのロードバランサを使用するのは一般的です。これらのリバースプロキシは様々な理由により502 Bad Gatewayや504 Gateway Timeoutを返しますが、トラブルシュートするには情報が少ない場合があります。また、追加の情報を示す場合においても、各社によって異なっています。 Fastlyの場合 Cloudflareの場合 GCPの場合そこで、プロキシのエラー情報を示すProxy-Statusレスポンスヘッダを定義する﹁The Proxy-Status HTTP Header Field﹂という提案仕様がFastlyのmnot氏らより出されています。初版のdraftだが読む。例 Proxy-Statusヘッダはまずそのエラータイプが示され、Extra Parameters続きます(ない場合もあります)。 Proxy-Statusの例を示します。 HTTP/

efcl 2019/02/21

Proxyでのエラーヘッダ

リンク

QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog

[追記] QUIC, HTTP/3 関連記事まるっと解説記事を書き直しました asnokaze.hatena blog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP

efcl 2018/11/03

QUICの目的やコネクションの流れ

QUIC

リンク

JS Self-Profiling API とは - ASnoKaze blog

W3C Web Performance Workingの議事録に「JS Self-Profiling API」についての議論があったので簡単に眺めておく。ミーティングの「発表スライドはこちら」 JS Self-Profiling API いわゆるRUM(Real user monitoring)などと同様、実際のユーザ側でJavaScriptのプロファイルを取得可能にするというのが「JS Self-Profiling API」のようだ。ユーザにより端末やネットワーク環境が違うため、実際のユーザ側でJavaScriptのプロファイルを取りたい。timerを使うことで擬似的に測定はできるが、コード量やオーバヘッドが増える。この提案を行っている、Facebookの人らはJavaScriptとSharedArrayBuffersでサンプリングプロファイラを実装したが正確性とパフォーマンスの欠点

efcl 2018/10/06

JS Self-Profiling API について

リンク

Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog

20190424 追記IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から﹁Tightening HTTP State Management﹂というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて

efcl 2018/09/03

CookieとSec-HTTP-Stateヘッダについて。ブラウザがオリジンに対してセキュアなトークンのヘッダを送信する。見ているページのオリジンに対して送信されるので、クロスオリジンに対しては送信されない

リンク

はてなブックマーク

タグ

ブックマーク / asnokaze.hatenablog.com (54)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第1週）

月間はてなブックマーク数ランキング（2024年6月）

今週のはてなブックマーク数ランキング（2024年6月第5週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス