ショップチャンネル、特定の一人の個人情報が特定の一人にだけ漏曳するシステム障害 27
ストーリー by nabeshin
本当に一人なのか確認中？ 部門より
本当に一人なのか確認中？ 部門より
backslashdot 曰く、
テレビショッピングチャンネルの大手であるショップチャンネルのWebサイトでのサービスである 「ネットでSHOP」、「ケータイでSHOP」が システムの不具合で停止しているとのことである。 ショップチャンネルのWebには現在も改修作業中である旨のメッセージがでている。 これだけだと珍しい事象ではないわけだが、その不具合というのは、 特定の1人の顧客の氏名、住所、電話番号などの個人情報が、別の特定の1人の顧客から閲覧できるという障害だったということだ。 原因の究明を進めた結果、1人の顧客にしか障害が発生しないことが分かったため、サービスの停止と原因を公表したとのことだが、 特定の1人のユーザにしか起きない事象というのは実に興味深い。どのようなコードであれば、このような事象が起きるのだろうか。
似たような不都合が別のサイトにて (スコア:5, 参考になる)
カロリヲというダイエットサイトなのですが、
メールアドレスが他の１，２人からみれてしまう [calorio.jp]不都合があったようです。
サイトは今も閉鎖中です。
こちらの原因は
なので、仮登録のURLの一部をランダム生成しなかったことによるようです。
Re:似たような不都合が別のサイトにて (スコア:1)
Re:似たような不都合が別のサイトにて (スコア:1)
>ランダム生成したらそれこそ衝突しますよ。
時間＋ランダムなら…と思わなくは無いですが、ただ単に
「ユニーク」やら「重複しない」という言葉が出てこなかったのかと。
Re: (スコア:0)
Re:似たような不都合が別のサイトにて (スコア:1)
「時間＋ランダムなら…と思わなくは無いですが、ただ単に」
の補足ですが…。
昔、自作プロクシのリクエストログを個別のファイルで出したくなった時の話ですが…。
”日時分秒ミリ秒＋ミリ秒シードの4桁乱数”でファイル名を吐く部品を作ってみたところ
一秒に1000ファイル以上吐いて、ファイル名は重複しませんでした。
ユニークな名前にする事だけ考えてランダムにしていましたが、ログなんだからランダムに
する意味がないじゃんと…、桁増やして連番に変えたら秒間4000ファイルに…。
無駄なボトルネックを作っていましたよorz 馬鹿だね俺は。
ランダムで重複しなかったのは、ある意味たまたまかと…。
Re:似たような不都合が別のサイトにて (スコア:1)
「その時点でのミリ秒の値」をシードにした乱数ってことでしょうか？ ストレートに解釈すると、同じミリ秒では毎回同じ乱数が出そうな気が。
ファイル名のフォーマットを変えたら秒間4000ファイルに増えたのは、実は「乱数のときにはファイル名が重複していたから」なのでは…。
（上書きされるので、重複していない1000個のファイルができたように見える）
それにしても、毎秒4000ファイル作成ってすごいですね。どれだけのリクエストに耐えるproxyだったのでしょう。
（オフトピック）Re:似たような不都合が別のサイトにて (スコア:1)
>それにしても、毎秒4000ファイル作成ってすごいですね。どれだけのリクエストに耐えるproxyだったのでしょう。
誤読ではなく、私の言葉不足です（汗）
その上、正確には”にているだけで参考にならない話”なのですよ。
ファイル数は”部品のテスト”でのファイル数ですよ。
プロクシにつっこんだら、500いきませんでしたorz（ネットの速度が…。）
>「その時点でのミリ秒の値」をシードにした乱数ってことでしょうか？
>ストレートに解釈すると、同じミリ秒では毎回同じ乱数が出そうな気が。
「日時分秒ミリ秒＋”ミリ秒を元にしたランダム”」なのです。実行時に同じ
「日時分秒ミリ秒」だった時に、「ミリ秒を元にしたランダム」を付加した意味が出てくる様にと。
ファイル生成が早いと「日時分秒ミリ秒」だけでは”ファイル名が重複する”（した）ので、
ユニークな名前とする為、実行時のミリ秒を元にランダム値を付加したわけです。
ランダムの桁数は”4桁で十分だろう”と適当に（汗）
できたファイルの一覧を見ていて”なんとか生成順にならないかのぉ”と思ったときに
初めて「付加値をランダムにする必要なんてないじゃん」とorz
>ファイル名のフォーマットを変えたら秒間4000ファイルに増えたのは、
>実は「乱数のときにはファイル名が重複していたから」なのでは…。
>（上書きされるので、重複していない1000個のファイルができたように見える）
ファイル名が重複すると意味をなさなくなるので、生成に失敗したら即落ちるようにしていました。
が、バグの可能性が否定できません（汗）
実際、同じ「日時分秒ミリ秒」の間だけしか重複する可能性がないので、たまたま重複しなかったのかと。
＃今更ながら、間抜けさに気づいた当時の俺に拍手です（汗）
今から検証しようにも、今時々使っている”直したソース”しかないorz
Re:似たような不都合が別のサイトにて (スコア:1)
uuid のような徹底した乱数を想定していました。
データベースが一つなら、ID + 時刻 + 乱数 あたりをハッシュにかければ
十分でしょうか。
uuid ぐらい長いと、まず衝突しないだろうということで
最近はユニークさが要求されるキーとかに容易に使っちゃってますけど、
これってまずいのでしょうか？
Re: (スコア:0)
横着して時刻をそのまま使ってたけど、
ユーザが二人以上になったら同時アクセスは起こり得るわけで、
子供のお遊び以外でその設計は有り得ないと思うんだ...。
今の楽天でも (スコア:3, 興味深い)
再度ログインしたりすると元に戻るようですが。
ID文字列の同一視、とか？ (スコア:2, すばらしい洞察)
あるいは、ショボいハッシュ使ってて衝突しちゃったとか。
Re:ID文字列の同一視、とか？ (スコア:2, 参考になる)
IDカラムにbinaryをセットしてなくて、
登録時はアプリケーション側で大文字小文字の区別をしつつ同一IDがないかを確認して登録して、
認証するときに where id='hoge' and password = 'hogehoge'; な行が*1行以上あるか*で確認して、
ユーザー情報を表示するときには where id='hoge' で取得できた1行目のデータを表示、
なんて実装になっていれば、ID:hogeの人がID:Hogeの人のデータを見れてしまう可能性はありますね。
参考：デフォルトでは、MySQL 検索では大文字と小文字は区別されません [mysql.com]
Re: (スコア:0)
誕生日パラドックス脳の恐怖？ (スコア:2, 参考になる)
100万人の会員がいたとして、半々くらいの確率で「その中の2人がコリジョンを起こす」のだとすると、ハッシュは40ビットあたりですかね。
逆にハッシュが32ビットだったとしたら、会員数は6万人程度かな。
例えば、DB記録の都合上IDを32ビット数値で扱いたくて、MD5の一部から32ビットだけ抽出したとか。
「32ビットの空間なら、50%の確率で衝突が起きるのはユーザーが21億人になったとき。余裕、余裕」
Re: (スコア:0)
Microsoftは止まらない (スコア:1, 興味深い)
去年は連絡もしたのに。
どうしたらいいんですかね。
閾値チェックとか (スコア:1)
＃ACは価値ある発言してください
特定の1人の顧客から・・・ (スコア:0)
想定される対応 (スコア:0)
見せない
END-IF
コボラー風でやってみた
IDより短いハッシュでID区別してるんじゃね？ (スコア:0, 余計なもの)
0からか、1からか (スコア:0, 余計なもの)
そのため、顧客管理番号が1ずつズレて処理されてしまった。
で「特定の1人の情報が、別の1人に漏洩」が顧客全員で起こったとか？
P2P (スコア:0)
深読み (スコア:0)
なので本当は全員が自由に読めるシステムだけど公表は「特定の一人」
とりあえず思いついたままに (スコア:0)
1ビット (スコア:0)
原因がはっきりすればいいけど (スコア:0)