メルカリ、Webブラウザ向けサービスで54,180名の個人情報を流出 62
ストーリー by hylom
笑えないキャッシュ問題 部門より
笑えないキャッシュ問題 部門より
ymasa 曰く、
メルカリのWebブラウザ向けサービスで、CDN（コンテンツデリバリネットワーク）サービス切り替えの際の設定不備によって54,180名の個人情報が流出したことをメルカリが発表した（INTERNET Watch）。
iOS/Androidアプリ版のメルカリは対象外という。流出したのは名前・住所・メールアドレス・電話番号、銀行口座、クレジットカードの下4桁や履歴・設定情報など。6月22日9時14分にWeb版メルカリのパフォーマンス改善のためキャッシュサーバーに切り替えを行ったとき、個人情報が他者から閲覧できる状態になっていたという。
時系列としては14時41分の発覚後15時5分に従来の設定に変更、15時16分メンテナンス状態にして15時36分キャッシュサーバーへのアクセスを遮断・問題解消。15時47分にメンテナンスモード終了、となっている。現在は対応を完了しているという。
また、問題の技術的な詳細も公開されている。これによると、メルカリでは個人情報などを扱うページについても、キャッシュを保持しない設定でCDN経由でのアクセスを行う仕様にしていたという。しかし、CDNの切り替えの際、切り替え前のCDNと切り替え後のCDNの仕様が異なっていたため、「キャッシュを保持しない設定」が無効になり、個人情報に関するページがキャッシュされ、本来表示されるべきではない人に対しそれが表示されてしまったという。
webとアプリで (スコア:1)
登録されている個人情報はそれぞれ別扱いってことでしょうか。
Re:webとアプリで (スコア:2, すばらしい洞察)
Webページのキャッシュが混信したみたいなものだから、多分専用APIで通信してるアプリには影響無かったんでしょう。
他人が見てたページのキャッシュが見えちゃった、それがアカウント情報ページだった、ということだと思う。
昔、Asciiか何かの編集記で、社内キャッシュサーバ(Proxyかな？)が壊れて、真面目なサイトの画像がアダルト画像にすり替わって大騒ぎ、ってのがあった気がする。
それとまぁ似たようなことかと。
Re:webとアプリで (スコア:2)
それは同じだけど
WEBからアクセスした分の個人情報が無防備なキャッシュに載ってしまったことが原因なんでしょう。
なのでその時間にWebアプリにアクセスした人限定なのだと思います。
Re:webとアプリで (スコア:1)
なるほど、そういうことですね。
重複してない限りアプリ利用者の情報は関係なかった。
#ちゃんと読んでなかった脊椎反射的人生 orz.
webとアプリで (スコア:0)
Re:webとアプリで (スコア:2)
単にサーバーサイドの作りの問題でしょ？
クライアントがPCとアプリで結果が違ったのは、今回の場合は結果論でしかないですよね？
（アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです）
PCとスマフォアプリのどちらが安全かに関係する話でもなければ、たかだか1サービスの構造の問題で一般化するような話でもないと思います。
Re:webとアプリで (スコア:1)
＞ アプリ側が通信するサーバーの更新で同じことが起きた可能性もあるはずです
起きるんじゃないですかね
暗号通信をキャッシュ出来てしまう現状では
気を付けなければやらかしてしまうことなら
再発は不可避でしょう
現場に阿呆がいるか阿呆な鶴の一声があれば
簡単に起きてしまえる程度のことなのですから
# こういう開発環境が一般的じゃないといいなぁ
Re:webとアプリで (スコア: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 などを配信するといった方式が採用されることが多かったですが、こういったやり方は時代遅れになり、全コンテンツを同一のCDNから配信するのが主流 になりました。
理由としては、昔は同一接続先に対する HTTP の同時接続数の関係でドメイン名を分散して画像等を配信した方が高速なことが多かったのですが、下記の理由により、全コンテンツを同一の FQDN から配信した方が表示が高速になる場合が多くなったからです。
あと、CDN からバックエンドWebサーバーへのアクセスの回数を減らした方が表示が高速化できますので、動的コンテンツもCDNでキャッシュするのが今の常識です。例えば、ブログのコメント欄に投稿時に「コメントの反映には数分程度かかります」などの表示されるサービスの場合、当該の動的ページも CDN でキャッシュ（有効期間1分間など）していて、最大で1分間コメントが反映されない状態になっていたりします。
ユーザーごとに違うページを表示している場合も同様で、ANA のトップページ（ログイン状態） [ana.co.jp] だと、〇〇〇〇様 いつもご利用いただきありがとうございます」と本名が表示されており、マイル残高も表示されていますが、良く見るとマイル残高のところに「2017年06月24日 16:15現在」とあり、7分前のマイル残高になっています。マイル消費直後にリロードしても最新のマイル残高が反映されていません。こういうユーザーの個人情報を含む動的ページも CDN やリバースプロキシによってキャッシュする実装になっている可能性があります。こういった、CDN のキャッシュは、CDN からバックエンドWebサーバーへのアクセスの回数を減らす通常時のサービス不可削減効果だけでなく、動的ページに HTTP リクエストを大量に投げる方式の DDoS 対策の効果があります。
CDN におけるキャッシュ条件・期間については細かくチューニングするのが一般的ですので、CDNのキャッシュ制御の仕様を全く確認・試験していないことによる情報漏えい [mercari.com] というのは珍しい事例だと思います。
Re: (スコア:0)
そ、そうなのか…DDoS対策と言われると腑に落ちざるをえない。なるほどなあ…
Re: (スコア:0)
なるほどなるほど
リアルタイム性が最重要なネトゲあたりとは全く違うコンセプトなんですね
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
Re:大きな疑問 (スコア:1)
HaHaHa
人気者になるのは悪い感じじゃないねッ
-- 風は東京に吹いているか
Re: (スコア:0)
元記事どころか、タレコミすら読んで無いだとっ！？ これがスラドというものかっ！！
Re: (スコア:0)
残念ながらスラドに限った話でもないんですよねぇ…。
タイトルだけしか読んでない人とか、ちゃんと読んでも誤訳による矛盾に気付かない人とか…。
Re: (スコア:0)
いるんですよね、したり顔で尻馬に乗って叩くだけで
コメント中身は何も書かない人
Re: (スコア:0)
CDNとキャッシュの意味を正確に理解できてなければ、本文読んでもそんな風に誤解する事もあるのでは？スラドとは言え全員がITの基礎知識がある訳ではありませんから。
お詫び (スコア:1)
流出が確認されたお客様に限り、五千円札（通常価格5,500円）を特価5,000円にて何度でもお求めいただけます。
期間限定ですのでお早めに！
Re: (スコア:0)
流出が確認されたお客様に限り、五千円札（通常価格5,500円）を特価5,000円にて何度でもお求めいただけます。
期間限定ですのでお早めに！
ネットにデマを書いてはいけない。
とか
ネタはネタらしく。
とか言っている昨今で平気でこういうこと書くヤツいるんだね。
ていうかいつの間にかWeb版ができてたんだ (スコア:0)
インタビューか何かでアプリ専用であることが売りであるという話をしていた記憶があるんだが
CDN詳しく知らねんだけど (スコア:0)
大量に個人情報晒されまくった客がごく少数ってのが実態？
まれにみる優良企業 (スコア:0)
クレジットカード番号と有効期限を保存していない。
Re:まれにみる優良企業 (スコア:1)
http://tech.mercari.com/entry/2017/06/22/204500 [mercari.com]
影響
本来お客さまごとに異なる内容が表示されるはずが、CDNにてキャッシュされたことにより同一の内容が表示されました。 これによりお客さまの個人情報(配送先住所、メールアドレス)などが、本人以外に表示されました。
意図せずお客さま本人以外に表示された可能性がある情報と影響をうけたお客さまは以下の通りです。*2
影響範囲 アクセス数
名前・住所・メールアドレス・電話番号（※登録しているお客さまのみ） 459名
銀行口座情報、クレジットカードの下4桁と有効期限（※登録しているお客さまのみ） 1855名
購入・出品履歴 22458名
ポイント・売上金、お知らせ、やることリスト 53816名
保存はしているようです。
全桁表示されなかっただけなのでは？
Re: (スコア:0)
キャッシュが見れているだけって事のようなので、保存していないとは限らないんじゃないですかね。
Re: (スコア:0)
マジでクレジットカード情報を保存して売る会社のせいで
クレジットカードの年会費が上がりまくり。
クレジット会社も対策しろよ。
Re: (スコア:0)
年会費払ってまで使おうとする人がどんどん減っている中、年会費は上がるに決まってるでしょ。
Re: (スコア:0)
手持ちのカード・・・
メインカード、年会費無料
電子マネーチャージ専用、1回決済発生で年会費無料
勤務先の社員カード、首にならない限り無料
うん、別にステータスとか求めてないし年会費掛かるカードなんて要らんな
Re: (スコア:0)
クレジットカード番号と有効期限を保存していない。
クレジットカード決済を構築するときにクレジットカード番号を保存しないことを
条件になっているから、基本最近作ったシステムはクレジットカード番号を保存し
ていないはずですけども。
購入・出品履歴も流出 (スコア:0)
＞障害が発生している間に、他者に閲覧された可能性があったのは、
＞459人の氏名・住所・メールアドレス・電話番号、
＞1855人の銀行口座情報またはクレジットカードの下4けた、
＞2万2458人の購入・出品履歴、5万3816人のポイント・売上金、お知らせ、やることリストの情報。
名前・住所・クレジットカード情報等の流出も重大だけど、
名前&住所と購入・出品履歴を紐づけられて晒されたら家や会社や学校で恥をかく人もいるのでは？
ダメなところ (スコア:0)
・お客さまからのお問い合わせを受け、問題認識
=> 自ら認識していただきたい
・切替前の検証では手元のマシンのhostsファイルを編集し、数回アクセスを行い問題なく動作していることを確認
=> 手元のマシン・・数回アクセス・・
・問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認
=> 切り替え作業前の検証時にCDN事業者に問い合わせての確認もしておくべき
メルカリのなかのひとはCDN切り替えなんてすぐっしょ？ダメなら戻せばいいし、俺たち技術力すげぇし！くらいのノリなのかもしれませんが。
# メルカリには是非いまのうちにいろんなポカやらかしてしまっておいてほしい。もっと大きくなってからだと悲惨。
Re:ダメなところ (スコア:1)
メルカリの中の人が対策できなかった問題に気づいてる俺すげぇ以上の内容が読み取れないのだが。
結果的に認識出来なかったものをただ認識しろだとか、確認しているものをもっと確認しろだとか、根性論かよ。
Re: (スコア:0)
(#3233388) は技術以前に経験がまったくないことがわかる。
Re: (スコア:0)
#3233388 をポストした者です.コメントついていたので改めて.
読み直すと誤解されてそうなので
前に書いた
『メルカリのなかのひとはCDN切り替えなんてすぐっしょ？ダメなら戻せばいいし、俺たち技術力すげぇし！くらいのノリなのかもしれませんが。』
これは
『メルカリのなかのひとは「CDN切り替えなんてすぐっしょ？ダメなら戻せばいいし、俺たち技術力すげぇし！」くらいのノリなのかもしれませんが。』
と解釈ください
> 結果的に認識出来なかったものをただ認識しろだとか、確認しているものをもっと確認しろだとか、根性論かよ。
#3233398 の「メルカリの中の人が
Re: (スコア:0)
>気づくもなにも、起こったあとのことなので誰にもどうとでも言えることを敢えて書きました。
そうね。起こったあとなら誰にでもどうとでも言えるね。
そんなことに気が付いたあなたはすごいですね。
Re: (スコア:0)
なぜなぜ分析は知識や理解が無ければ根性論や個人攻撃に陥りやすく、
効果的な運用には技術と経験が必要です。
有意義な原因究明と業務システムの改善のあらんことを。
Re: (スコア:0)
なぜなぜ分析を利用するしないに関わらず、原因を解析するセンスが必要だろうね。
知恵のある人間はなぜなぜ分析しなくても一発で問題の本質に近い所まで到達してしまう。
並の人間はなぜなぜ分析で段階を踏むことにより、問題の深い洞察を得ることができる。
知恵のない人間はなぜなぜ分析をしても堂々巡りや一般論から抜け出せず問題の効果的な対策を得るに至らない。
終着点は犯人確定ではなくシステム改善だから、〇〇がダメという結論で終わっては分析の成果とは言えない。
なぜCache-Control: no-cacheでキャッシュ？ (スコア:0)
CDN使ったこと無いからよくわからんのだけど
Cache-Control: privateでキャッシュしない→わかる
Cache-Control: no-cacheでキャッシュする→？？？
Re:なぜCache-Control: no-cacheでキャッシュ？ (スコア:1)
>またno-cacheオプションによりキャッシュ使用時にサーバに対して問い合わせを行うようになり
http://tech.mercari.com/entry/2017/06/22/204500 より
Cache-Control フィールドには、 no-store と no-cache 値（他）がある。
要約すると、no-store は、再使用禁止で、no-cache は、無断再使用禁止である。
(#3233717) （上）は、おそらく、キャッシュ禁止（no-cache）を再使用禁止（no-store）と誤解していませんか？
|no-cache
|Forces caches to submit the request to the origin server for validation before releasing a cached copy.
（キャッシュ（複製）が使用される前に、その有効性を（キャッシュ元の）サーバに必ず問い合わせます。）（大雑把な訳です。）
要は、コンテンツ（キャッシュ）の有効性（賞味期限）をサーバに問い合わせて、腐っていたら新鮮なものに更新するから、ユーザが腐ったコンテンツを食べる事故を防止できる。まだ食べられるならコンテンツ（メッセージボディ）分の通信量を節約できる。
|no-store
|The cache should not store anything about the client request or server response.
（クライアントリクエストとサーバレスポンスに関する、キャッシュを保管することは（義務として）できません。）
まだ、食べられるかもしれないのにキャッシュ（コンテンツ）を捨てる（保管しない）ので、常にコンテンツ（メッセージボディ）分の通信量を消費する。
引用元＆参考 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control
「Cache-Control: no-cache」と「Expiresヘッダ」を併用する意図は知らない。(*)また、1秒前ではなく１０年ぐらい前の固定日にしておくような。（クライアントの時計が電池切れ、電池交換などで初期化されたときの対策として）それに、時刻同期せずに利用されることを想定すると、サーバ時刻とクライアント時刻が５分違っているとレアケースでおかしくなるような。（実運用上は問題ないだろうけど）（個人的には、Expiresに１秒前は明らかにおかしいと思う。）
(*) WEBブラウザ、プロキシほか、実装が多い（運用形態が多様）から多重指定で保険を掛ける意図だろう。 Expires ヘッダはみた感じ、 Cache-Control よりも古い仕様みたいだし。使い勝手は適材適所に、なかんじ。
Re:なぜCache-Control: no-cacheでキャッシュ？ (スコア:1)
疑問は自己解決した。
|Date
|The Date general HTTP header contains the date and time at which the message was originated.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date より