アカウント名:
パスワード:
Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org]
にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として Cache-Control: no-store を挙げていて、 プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0 を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。
今回の件が、このせいかどうかは分かりませんが、MDNを信じて情報漏えいが起
「no-store」でキャッシュするような CDN を使った時点で負けなんじゃないか？
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして https://engineering.mercari.com/blog/entry/2017-06-22-204500/ [mercari.com]
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは Cache-Control: private が含まれている場合のみとわかりました。
「場合のみ」とあるので、「no-store」じゃ駄目で「private」の必要があるとあります。CDN業者の名前は書かれていませんが、有名アプリのメルカリが使うような大規模なCDNでも、「no-store」無視の仕様だったりするのです。
また、
Expiresヘッダは、Cache-Controlヘッダにmax-ageまたはs-maxageがない場合採用されます。ただし、過去の日付である場合、0秒として扱われます。キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様に
まともな議論になってないから、遅ればせながら指摘するけど、“ＣＤＮが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもＣＤＮに対するディレクティブではない。「Cache-Control」フィールド自体、ＣＤＮが無い時代に作られた。「Cache-Control: private」はＣＤＮが無断借用しているだけ。 ＣＤＮというのは、HTTP仕様としては違法や脱法的扱いのもの（違法改造）で、限定的に使われていたもの（動画配信やアップデート）が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。だから、 #4073928 の指摘は
質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの？
HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
MDN を信じずに「Cache-Control」には「private」を含めよう (スコア:1)
Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org]
にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として
Cache-Control: no-store を挙げていて、
プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。
今回の件が、このせいかどうかは分かりませんが、MDNを信じて情報漏えいが起
Re: (スコア:0)
「no-store」でキャッシュするような CDN を使った時点で負けなんじゃないか？
メルカリの情報漏えいも「private」なら防げた (スコア:3, 興味深い)
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
https://engineering.mercari.com/blog/entry/2017-06-22-204500/ [mercari.com]
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは
Cache-Control: private
が含まれている場合のみとわかりました。
「場合のみ」とあるので、「no-store」じゃ駄目で「private」の必要があるとあります。
CDN業者の名前は書かれていませんが、有名アプリのメルカリが使うような大規模なCDNでも、「no-store」無視の仕様だったりするのです。
また、
Expiresヘッダは、Cache-Controlヘッダにmax-ageまたはs-maxageがない場合採用されます。ただし、過去の日付である場合、0秒として扱われます。キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様に
皆さん誤解してます (スコア:0)
まともな議論になってないから、遅ればせながら指摘するけど、“ＣＤＮが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもＣＤＮに対するディレクティブではない。「Cache-Control」フィールド自体、ＣＤＮが無い時代に作られた。「Cache-Control: private」はＣＤＮが無断借用しているだけ。
ＣＤＮというのは、HTTP仕様としては違法や脱法的扱いのもの（違法改造）で、限定的に使われていたもの（動画配信やアップデート）が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。
だから、 #4073928 の指摘は
Re:皆さん誤解してます (スコア:0)
質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの？
HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。