アカウント名:
パスワード:
登録されている個人情報はそれぞれ別扱いってことでしょうか。
単にサーバーサイドの作りの問題でしょ？
クライアントが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の結果結構長い時キャッシュしますし。TLSのハンドシェイクは言うほどのロスは無いでしょう？HTTP/2の速度向上がの恩恵が減るとか自分で計測や計算してから言ってます？FQDNが1つから、2つになっても1,2%しか変わりませんよ。Cookie送信の影響の方が遥かに大きいです。
HTTP/2 では HTTPヘッダーに HPACK が採用されており、画像・CSS・JavaScriptなどをリクエストする度に Cookie データが無駄に送信されるのを防ぐことができます。
無職の妄言ゆえ、致し方なしこのあたり [srad.jp]とかこのあたり [srad.jp]みると、大体専門家の意見にたてついてアホさらしてるんだけど、なぜかプラスモデされることが多いんだよねぇ(棒)ホントやめて欲しい、勘違いする人が出るから
HPACKとCookieフリードメインについて理解できてないのは分かりました。HPACKはヘッダーを圧縮するだけで、Cookieの送信を抑制する訳ではありません。またCookieの主要な使われ方のIDはハッシュを通している事が多いので、ランダム性が高く圧縮率は高くありません。加えて、HPACKは1文字単位のシンプルな静的ハフマン圧縮なので、そもそもの圧縮率も高くありません。ハフマン圧縮なので1バイトでも節約しようと、記号を含んだエンコードを使っていたりすると(最近は殆ど見ませんが)返って増える場合もあります。(次のHTTPでこの問題は解決予定ですが)また
httpsのハンドシェイクってping35で100ミリ秒ぐらいはかかるよそれが1～2%しか影響ないって、Cookieの送信に5秒～10秒もかかるってことになるが
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のハンドシェイクを「言うほどのロスは無い」というのはどうかと思うよ
HTTP/2は一度送信したヘッダー名/値ペアはStatic Tableとして保持されるから2回目以降はID番号のみ送信されるだけそれ以前にindex.htmlのリクエストが来た時点でstyle.cssやlogo.pngをサーバプッシュできるからHTTP/2ではCookieフリードメインの必要性は皆無
スライド pp.22-25
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
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:今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識 (スコア:1)
ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。
今でも、静的コンテンツの別FQDN化は一般的ですよ。Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュしますし。TLSのハンドシェイクは言うほどのロスは無いでしょう？HTTP/2の速度向上がの恩恵が減るとか自分で計測や計算してから言ってます？FQDNが1つから、2つになっても1,2%しか変わりませんよ。Cookie送信の影響の方が遥かに大きいです。
# この人は全部間違いじゃなくて、中途半端に正しい事に、良く知らない部分を妄想で補完して挟み込んでくるから質が悪い
Re:今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識 (スコア:2)
確かに、Yahoo! Japan も画像などは別 FQDNの s.yimg.jp 配信していますし、全コンテンツを同一のCDNから配信するのが主流 というのは言い過ぎでした。
HTTP/2 では HTTPヘッダーに HPACK が採用されており、画像・CSS・JavaScriptなどをリクエストする度に Cookie データが無駄に送信されるのを防ぐことができます。
Re: (スコア:0)
無職の妄言ゆえ、致し方なし
このあたり [srad.jp]とかこのあたり [srad.jp]みると、大体専門家の意見にたてついてアホさらしてるんだけど、なぜかプラスモデされることが多いんだよねぇ(棒)
ホントやめて欲しい、勘違いする人が出るから
Re: (スコア:0)
HPACKとCookieフリードメインについて理解できてないのは分かりました。
HPACKはヘッダーを圧縮するだけで、Cookieの送信を抑制する訳ではありません。またCookieの主要な使われ方のIDはハッシュを通している事が多いので、ランダム性が高く圧縮率は高くありません。加えて、HPACKは1文字単位のシンプルな静的ハフマン圧縮なので、そもそもの圧縮率も高くありません。ハフマン圧縮なので1バイトでも節約しようと、記号を含んだエンコードを使っていたりすると(最近は殆ど見ませんが)返って増える場合もあります。(次のHTTPでこの問題は解決予定ですが)
また
Re: (スコア:0)
httpsのハンドシェイクってping35で100ミリ秒ぐらいはかかるよ
それが1～2%しか影響ないって、Cookieの送信に5秒～10秒もかかるってことになるが
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:今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識 (スコア:1)
HTTP/2は一度送信したヘッダー名/値ペアはStatic Tableとして保持されるから2回目以降はID番号のみ送信されるだけ
それ以前にindex.htmlのリクエストが来た時点でstyle.cssやlogo.pngをサーバプッシュできるから
HTTP/2ではCookieフリードメインの必要性は皆無
Re: (スコア:0)
スライド pp.22-25