「メルカリ、Web版で54,180名の個人情報が流出」記事へのコメント

webとアプリで

[nemui4 (20313)]

登録されている個人情報はそれぞれ別扱いってことでしょうか。

webとアプリで

[mo_premera (47826)]

別扱いなんでしょうかね。 それ前提だと、いまやPCよりスマホのほうが何も対策してない状態ではセキュリティ高いってことですか？

Re:

[Suzuno (48093)]

単にサーバーサイドの作りの問題でしょ？

クライアントがPCとアプリで結果が違ったのは、今回の場合は結果論でしかないですよね？
（アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです）

PCとスマフォアプリのどちらが安全かに関係する話でもなければ、たかだか1サービスの構造の問題で一般化するような話でもないと思います。

Re:

[Anonymous Coward]

＞ アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです

起きるんじゃないですかね
暗号通信をキャッシュ出来てしまう現状では

気を付けなければやらかしてしまうことなら
再発は不可避でしょう

現場に阿呆がいるか阿呆な鶴の一声があれば
簡単に起きてしまえる程度のことなのですから

# こういう開発環境が一般的じゃないといいなぁ

Re:

[kentok (41940)]

だから外形監視を導入するじゃん？

--
-- 風は東京に吹いているか

Re:

[Anonymous Coward]

だから外形監視ってのが皮肉なジョークなのでは？
発覚イコール流出の瞬間を観測なわけで

通信だけでなくキャッシュもクライアントごとに暗号化されていれば
他人のキャッシュが流れてきても解読できんのでそうします
とかならまだマシなんだが

何のためのキャッシュかパフォーマンス的に微妙過ぎるけど
流出するよりはマシみたいな

# 何を得るために何を代償にするかって大事よね

Re:

[Anonymous Coward]

#3233248補足：常時SSL化の観点

既存の個人情報や決済部分のみの暗号通信では
HTTPSならキャッシュしないという定型処理ができたが
常時SSL化により区別は気を付けて開発しないとできなくなった

キャッシュ効率の共通部分と
キャッシュしてはいけない良い個人情報や決済が
共にHTTPSでの通信となるためです

ならばいっそ
キャッシュしないか
キャッシュ自体を暗号化してそのセッションでのみの効率化に留める
という
パフォーマンス的には消極的だがセキュア的には正しい解もありなのでは？
というちょっとした思考実験です

Re:

[Anonymous Coward]

>キャッシュしないか
>キャッシュ自体を暗号化してそのセッションでのみの効率化に留める
消極的とかじゃなくてこれらのアプローチの方がよいと思う。
個人情報をキャッシュの可能性がある経路で流していたことに驚いているくらい。

というかCDNっていつの間にか使われ方が変わっていたのか…
静的コンテンツ配信の分散化がCDNの役割と思っていた…

Re:

[Anonymous Coward]

静的コンテンツ配信の分散化がCDNの役割と思っていた…

いや…動的コンテンツはCDNに載る種類のものじゃないよねやっぱ。

サーバーサイドでレンダリングされたユーザー固有のコンテンツがCDNから静的htmlに見えてキャッシュされたという事かと思ってるんだけど、
なんかCDNはそういう自動的にいいようにやってくれるようなもんじゃなくて、
予めCDN用のコンテンツとして特定の領域に置いてあるファイルを展開するものだと思ってた。

今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識

[Printable is bad. (38668)]

静的コンテンツ配信の分散化がCDNの役割と思っていた…

いや…動的コンテンツはCDNに載る種類のものじゃないよねやっぱ。

スラドですら DDoS 攻撃を食らう時代 [security.srad.jp] ですので、ウェブ事業者、特にメルカリのように DDoS によりアクセスできない状態になるのが致命的な直接お金が絡むサービスにおいては、DDoS 対策は必須です。今時は、CDN 利用の主目的が DDoS 対策です。

あと、昔は、htmlファイルを配信するサービスサイト example.jp には CDN を使用せず、別FQDNの imgX.cdn.example.net から 画像・JavaScript・CSS などを配信するといった方式が採用されることが多かったですが、こういっ

Re:

[Anonymous Coward]

ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。
今でも、静的コンテンツの別FQDN化は一般的ですよ。Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュしますし。TLSのハンドシェイクは言うほどのロスは無いでしょう？HTTP/2の速度向上がの恩恵が減るとか自分で計測や計算してから言ってます？FQDNが1つから、2つになっても1,2%しか変わりませんよ。Cookie送信の影響の方が遥かに大きいです。

# この人は全部間違いじゃなくて、中途半端に正しい事に、良く知らない部分を妄想で補完して挟み込んでくるから質が悪い

Re:

[Printable is bad. (38668)]

ま～た、この人は自分の狭い認識を世間の常識みたいに一般化してる。
今でも、静的コンテンツの別FQDN化は一般的ですよ。

確かに、Yahoo! Japan も画像などは別 FQDNの s.yimg.jp 配信していますし、全コンテンツを同一のCDNから配信するのが主流 というのは言い過ぎでした。

Cookieフリーのためなので目的は少し違いますが。少なくともGoogleのガイドラインでは推奨になっていますし、ページスピードチェックとかすると警告されます。勿論、そっちもCDNは通しますが。DNSの問題はdns-prefetchである程度軽減できますし、そもそも、クライアントOSはDNSの結果結構長い時キャッシュ

Re:

[Anonymous Coward]

HPACKとCookieフリードメインについて理解できてないのは分かりました。
HPACKはヘッダーを圧縮するだけで、Cookieの送信を抑制する訳ではありません。またCookieの主要な使われ方のIDはハッシュを通している事が多いので、ランダム性が高く圧縮率は高くありません。加えて、HPACKは1文字単位のシンプルな静的ハフマン圧縮なので、そもそもの圧縮率も高くありません。ハフマン圧縮なので1バイトでも節約しようと、記号を含んだエンコードを使っていたりすると(最近は殆ど見ませんが)返って増える場合もあります。(次のHTTPでこの問題は解決予定ですが)
また

Re:今時、CDN利用の主目的はDDoSだし、動的コンテンツもCDNでキャッシュするのが常識

[Anonymous Coward]

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:

[Anonymous Coward]

スライド pp.22-25