アカウント名:
パスワード:
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つ目以降のリクエストにも同じレスポンスが返される仕様になっていました。このため、お客さまがWeb版メルカリに対してアクセスを行い、メルカリのサーバがレスポンスを構築している途中で、別のお客さまから同じURLに対してリクエストがあった場合、レスポンスがまとめられ、最初のお客さまの情報がふくまれたコンテンツが別のお客さまへ配信される事態に至りました。
と、キャッシュ有効期限を0秒としても、「サーバがレスポンスを構築している途中」に次のアクセスがあると0秒扱いになってキャッシュが使われてしまって、それで情報漏えいが起きたようです。
ほんの一瞬でキャッシュの有効期限が切れるので、負荷テストのような大量アクセスをするテストでないと問題が再現せず発覚しにくいです。
まともな議論になってないから、遅ればせながら指摘するけど、“CDNが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもCDNに対するディレクティブではない。「Cache-Control」フィールド自体、CDNが無い時代に作られた。「Cache-Control: private」はCDNが無断借用しているだけ。 CDNというのは、HTTP仕様としては違法や脱法的扱いのもの(違法改造)で、限定的に使われていたもの(動画配信やアップデート)が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。だから、 #4073928 の指摘は
質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの?
HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。
これは酷い。そもそも、ダイアルアップが主流の「インターネット」が高価だった時代は、キャッシュするプロキシの存在が一般的だったのじゃぞ。会社・学校などの組織がそれぞれプロキシを運用していたのじゃ。
例えば、児童・生徒・学生がパソコン室から20台で同じサイトを見たら帯域がもたないから、公開のプロキシサーバがキャッシュして1回ですむようにしていたのだ。
当時有名なのは Squid というプロキシで、1996年 (25年前)からあったのじゃぞ。
その後、利用可能な帯域幅が増えて、組織がプロキシサーバを持たなくなってきて、その後、常時SSL化(TLS化)の流れでキャッシュがしにくくなって廃れていったというのが歴史の流れ。
ということで、大昔から Cache-Control で共有キャッシュの制御は行われていたし、RFCにもそれを想定した記述が山ほどある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
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つ目以降のリクエストにも同じレスポンスが返される仕様になっていました。
このため、お客さまがWeb版メルカリに対してアクセスを行い、メルカリのサーバがレスポンスを構築している途中で、別のお客さまから同じURLに対してリクエストがあった場合、レスポンスがまとめられ、最初のお客さまの情報がふくまれたコンテンツが別のお客さまへ配信される事態に至りました。
と、キャッシュ有効期限を0秒としても、「サーバがレスポンスを構築している途中」に次のアクセスがあると0秒扱いになってキャッシュが使われてしまって、それで情報漏えいが起きたようです。
ほんの一瞬でキャッシュの有効期限が切れるので、負荷テストのような大量アクセスをするテストでないと問題が再現せず発覚しにくいです。
皆さん誤解してます (スコア:0)
まともな議論になってないから、遅ればせながら指摘するけど、“CDNが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもCDNに対するディレクティブではない。「Cache-Control」フィールド自体、CDNが無い時代に作られた。「Cache-Control: private」はCDNが無断借用しているだけ。
CDNというのは、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")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。
誤解しているのは「貴方」の方 (スコア:0)
これは酷い。
そもそも、ダイアルアップが主流の「インターネット」が高価だった時代は、キャッシュするプロキシの存在が一般的だったのじゃぞ。
会社・学校などの組織がそれぞれプロキシを運用していたのじゃ。
例えば、児童・生徒・学生がパソコン室から20台で同じサイトを見たら帯域がもたないから、公開のプロキシサーバがキャッシュして1回ですむようにしていたのだ。
当時有名なのは Squid というプロキシで、1996年 (25年前)からあったのじゃぞ。
その後、利用可能な帯域幅が増えて、組織がプロキシサーバを持たなくなってきて、その後、常時SSL化(TLS化)の流れでキャッシュがしにくくなって廃れていったというのが歴史の流れ。
ということで、大昔から Cache-Control で共有キャッシュの制御は行われていたし、RFCにもそれを想定した記述が山ほどある。