アカウント名:
パスワード:
登録されている個人情報はそれぞれ別扱いってことでしょうか。
単にサーバーサイドの作りの問題でしょ？
クライアントがPCとアプリで結果が違ったのは、今回の場合は結果論でしかないですよね？（アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです）
PCとスマフォアプリのどちらが安全かに関係する話でもなければ、たかだか1サービスの構造の問題で一般化するような話でもないと思います。
＞ アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです
起きるんじゃないですかね暗号通信をキャッシュ出来てしまう現状では
気を付けなければやらかしてしまうことなら再発は不可避でしょう
現場に阿呆がいるか阿呆な鶴の一声があれば簡単に起きてしまえる程度のことなのですから
# こういう開発環境が一般的じゃないといいなぁ
だから外形監視を導入するじゃん？
だから外形監視ってのが皮肉なジョークなのでは？発覚イコール流出の瞬間を観測なわけで
通信だけでなくキャッシュもクライアントごとに暗号化されていれば他人のキャッシュが流れてきても解読できんのでそうしますとかならまだマシなんだが
何のためのキャッシュかパフォーマンス的に微妙過ぎるけど流出するよりはマシみたいな
# 何を得るために何を代償にするかって大事よね
#3233248補足：常時SSL化の観点
既存の個人情報や決済部分のみの暗号通信ではHTTPSならキャッシュしないという定型処理ができたが常時SSL化により区別は気を付けて開発しないとできなくなった
キャッシュ効率の共通部分とキャッシュしてはいけない良い個人情報や決済が共にHTTPSでの通信となるためです
ならばいっそキャッシュしないかキャッシュ自体を暗号化してそのセッションでのみの効率化に留めるというパフォーマンス的には消極的だがセキュア的には正しい解もありなのでは？というちょっとした思考実験です
>キャッシュしないか>キャッシュ自体を暗号化してそのセッションでのみの効率化に留める消極的とかじゃなくてこれらのアプローチの方がよいと思う。個人情報をキャッシュの可能性がある経路で流していたことに驚いているくらい。
というかCDNっていつの間にか使われ方が変わっていたのか…静的コンテンツ配信の分散化がCDNの役割と思っていた…
静的コンテンツ配信の分散化がCDNの役割と思っていた…
いや…動的コンテンツはCDNに載る種類のものじゃないよねやっぱ。
サーバーサイドでレンダリングされたユーザー固有のコンテンツがCDNから静的htmlに見えてキャッシュされたという事かと思ってるんだけど、なんかCDNはそういう自動的にいいようにやってくれるようなもんじゃなくて、予めCDN用のコンテンツとして特定の領域に置いてあるファイルを展開するものだと思ってた。
静的コンテンツ配信の分散化がCDNの役割と思っていた…いや…動的コンテンツはCDNに載る種類のものじゃないよねやっぱ。
スラドですら DDoS 攻撃を食らう時代 [security.srad.jp] ですので、ウェブ事業者、特にメルカリのように DDoS によりアクセスできない状態になるのが致命的な直接お金が絡むサービスにおいては、DDoS 対策は必須です。今時は、CDN 利用の主目的が DDoS 対策です。
あと、昔は、htmlファイルを配信するサービスサイト example.jp には CDN を使用せず、別FQDNの imgX.cdn.example.net から 画像・JavaScript・CSS などを配信するといった方式が採用されることが多かったですが、こういっ
ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。今でも、静的コンテンツの別FQDN化は一般的ですよ。Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュしますし。TLSのハンドシェイクは言うほどのロスは無いでしょう？HTTP/2の速度向上がの恩恵が減るとか自分で計測や計算してから言ってます？FQDNが1つから、2つになっても1,2%しか変わりませんよ。Cookie送信の影響の方が遥かに大きいです。
# この人は全部間違いじゃなくて、中途半端に正しい事に、良く知らない部分を妄想で補完して挟み込んでくるから質が悪い
ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。 今でも、静的コンテンツの別FQDN化は一般的ですよ。
確かに、Yahoo! Japan も画像などは別 FQDNの s.yimg.jp 配信していますし、全コンテンツを同一のCDNから配信するのが主流 というのは言い過ぎでした。
Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュ
HPACKとCookieフリードメインについて理解できてないのは分かりました。HPACKはヘッダーを圧縮するだけで、Cookieの送信を抑制する訳ではありません。またCookieの主要な使われ方のIDはハッシュを通している事が多いので、ランダム性が高く圧縮率は高くありません。加えて、HPACKは1文字単位のシンプルな静的ハフマン圧縮なので、そもそもの圧縮率も高くありません。ハフマン圧縮なので1バイトでも節約しようと、記号を含んだエンコードを使っていたりすると(最近は殆ど見ませんが)返って増える場合もあります。(次のHTTPでこの問題は解決予定ですが)また
HTTP/2 入門 [slideshare.net]読むといいよ
> 22. ヘッダー圧縮 HTTP 1.xでは、UserAgentやCookieといったHTTPヘッダーが何度も同じ内容で送信されており、オーバーヘッドが生じていることが分かっています。> SPDYではHTTPヘッダーをgzip圧縮することで、これに対処しました。> しかし、CRIMEと呼ばれる攻撃手法が見つかったため、圧縮率を下げざ るをえなくなってしまいました。> そこで、HTTP/2では、ヘッダーの差分だけを送るアルゴリズムを使っ たHPACKと呼ばれるヘッダー圧縮機構を採用しています。
従来は画像100個あったら100回Cookieヘッダーが送信されてたけど、HTTP/2だとヘッダーは差分しか送られないので1回分+αの通信量で済む最初のhtml取得時にCookieヘッダを送信しているので、画像などのリクエスト時にCookie内容が送信されないというのは正しい
せいぜい数ミリ秒にしかならないCookieの処理速度で大騒ぎして、100ミリ秒かかるTLSのハンドシェイクを「言うほどのロスは無い」というのはどうかと思うよ
スライド pp.22-25
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
webとアプリで (スコア:1)
登録されている個人情報はそれぞれ別扱いってことでしょうか。
webとアプリで (スコア:0)
Re: (スコア:2)
単にサーバーサイドの作りの問題でしょ？
クライアントがPCとアプリで結果が違ったのは、今回の場合は結果論でしかないですよね？
（アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです）
PCとスマフォアプリのどちらが安全かに関係する話でもなければ、たかだか1サービスの構造の問題で一般化するような話でもないと思います。
Re: (スコア:1)
＞ アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです
起きるんじゃないですかね
暗号通信をキャッシュ出来てしまう現状では
気を付けなければやらかしてしまうことなら
再発は不可避でしょう
現場に阿呆がいるか阿呆な鶴の一声があれば
簡単に起きてしまえる程度のことなのですから
# こういう開発環境が一般的じゃないといいなぁ
Re: (スコア:1)
だから外形監視を導入するじゃん？
-- 風は東京に吹いているか
Re: (スコア:0)
だから外形監視ってのが皮肉なジョークなのでは？
発覚イコール流出の瞬間を観測なわけで
通信だけでなくキャッシュもクライアントごとに暗号化されていれば
他人のキャッシュが流れてきても解読できんのでそうします
とかならまだマシなんだが
何のためのキャッシュかパフォーマンス的に微妙過ぎるけど
流出するよりはマシみたいな
# 何を得るために何を代償にするかって大事よね
Re: (スコア:0)
#3233248補足：常時SSL化の観点
既存の個人情報や決済部分のみの暗号通信では
HTTPSならキャッシュしないという定型処理ができたが
常時SSL化により区別は気を付けて開発しないとできなくなった
キャッシュ効率の共通部分と
キャッシュしてはいけない良い個人情報や決済が
共にHTTPSでの通信となるためです
ならばいっそ
キャッシュしないか
キャッシュ自体を暗号化してそのセッションでのみの効率化に留める
という
パフォーマンス的には消極的だがセキュア的には正しい解もありなのでは？
というちょっとした思考実験です
Re: (スコア:0)
>キャッシュしないか
>キャッシュ自体を暗号化してそのセッションでのみの効率化に留める
消極的とかじゃなくてこれらのアプローチの方がよいと思う。
個人情報をキャッシュの可能性がある経路で流していたことに驚いているくらい。
というかCDNっていつの間にか使われ方が変わっていたのか…
静的コンテンツ配信の分散化がCDNの役割と思っていた…
Re: (スコア:0)
静的コンテンツ配信の分散化がCDNの役割と思っていた…
いや…動的コンテンツはCDNに載る種類のものじゃないよねやっぱ。
サーバーサイドでレンダリングされたユーザー固有のコンテンツがCDNから静的htmlに見えてキャッシュされたという事かと思ってるんだけど、
なんかCDNはそういう自動的にいいようにやってくれるようなもんじゃなくて、
予めCDN用のコンテンツとして特定の領域に置いてあるファイルを展開するものだと思ってた。
今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識 (スコア:5, 参考になる)
スラドですら DDoS 攻撃を食らう時代 [security.srad.jp] ですので、ウェブ事業者、特にメルカリのように DDoS によりアクセスできない状態になるのが致命的な直接お金が絡むサービスにおいては、DDoS 対策は必須です。今時は、CDN 利用の主目的が DDoS 対策です。
あと、昔は、htmlファイルを配信するサービスサイト example.jp には CDN を使用せず、別FQDNの imgX.cdn.example.net から 画像・JavaScript・CSS などを配信するといった方式が採用されることが多かったですが、こういっ
Re: (スコア:1)
ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。
今でも、静的コンテンツの別FQDN化は一般的ですよ。Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュしますし。TLSのハンドシェイクは言うほどのロスは無いでしょう？HTTP/2の速度向上がの恩恵が減るとか自分で計測や計算してから言ってます？FQDNが1つから、2つになっても1,2%しか変わりませんよ。Cookie送信の影響の方が遥かに大きいです。
# この人は全部間違いじゃなくて、中途半端に正しい事に、良く知らない部分を妄想で補完して挟み込んでくるから質が悪い
Re: (スコア:2)
確かに、Yahoo! Japan も画像などは別 FQDNの s.yimg.jp 配信していますし、全コンテンツを同一のCDNから配信するのが主流 というのは言い過ぎでした。
Re: (スコア:0)
HPACKとCookieフリードメインについて理解できてないのは分かりました。
HPACKはヘッダーを圧縮するだけで、Cookieの送信を抑制する訳ではありません。またCookieの主要な使われ方のIDはハッシュを通している事が多いので、ランダム性が高く圧縮率は高くありません。加えて、HPACKは1文字単位のシンプルな静的ハフマン圧縮なので、そもそもの圧縮率も高くありません。ハフマン圧縮なので1バイトでも節約しようと、記号を含んだエンコードを使っていたりすると(最近は殆ど見ませんが)返って増える場合もあります。(次のHTTPでこの問題は解決予定ですが)
また
Re:今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識 (スコア:1)
HTTP/2 入門 [slideshare.net]読むといいよ
> 22. ヘッダー圧縮 HTTP 1.xでは、UserAgentやCookieといったHTTPヘッダーが何度も同じ内容で送信されており、オーバーヘッドが生じていることが分かっています。
> SPDYではHTTPヘッダーをgzip圧縮することで、これに対処しました。
> しかし、CRIMEと呼ばれる攻撃手法が見つかったため、圧縮率を下げざ るをえなくなってしまいました。
> そこで、HTTP/2では、ヘッダーの差分だけを送るアルゴリズムを使っ たHPACKと呼ばれるヘッダー圧縮機構を採用しています。
従来は画像100個あったら100回Cookieヘッダーが送信されてたけど、HTTP/2だとヘッダーは差分しか送られないので1回分+αの通信量で済む
最初のhtml取得時にCookieヘッダを送信しているので、画像などのリクエスト時にCookie内容が送信されないというのは正しい
せいぜい数ミリ秒にしかならないCookieの処理速度で大騒ぎして、100ミリ秒かかるTLSのハンドシェイクを「言うほどのロスは無い」というのはどうかと思うよ
Re: (スコア:0)
スライド pp.22-25