ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解 160
手に負えない 部門より
jbeef曰く、"セキュリティホールmemo経由、葉っぱ日記10月17日のエントリによると、2005年5月にIPAの脆弱性情報届出窓口に届け出られたmixiの欠陥の件が、1年半たってようやく決着したという。この欠陥は、mixi内でアップロードされた画像が、mixiにログインしていなくても画像のURLを指定すれば誰にでも閲覧できてしまうというもの。もっとも、数百万人の会員がいるとされるmixiでは、いずれにせよ誰にでも見られるのに等しいのだから問題じゃないという考え方もあろう。しかし、「友人まで公開」に設定している日記の画像はどうだろうか。普通のユーザなら、写真画像も「友人まで公開」だと信じて貼り付けるのではなかろうか。
葉っぱ日記によると、IPAはこれを脆弱性として受け付け、取り扱いを開始したものの、11か月後の2006年4月になって、ミクシィ側からギブアップの連絡があったという。その内容は、「システムの改修にて試みましたが、いくつかのプラットフォームにおいてログインができなくなった」「全ユーザーに対応させることは非常に難しい」というもので、改修しないということで取り扱い終了となったそうだ。その際ミクシィは、「近々公開予定のユーザー向け啓蒙コンテンツの中で写真掲載時の注意を訴えて行く」と約束したのだそうだが、それが公開されたのは5か月後の9月だったという。(つづく)"
"その「啓蒙コンテンツ」とは、mixiの「ヘルプ」ページ内のひとつのQ&Aとして掲載された「Q.掲載した画像のURL をログアウトした状態でクリックしても、画像を見ることができる?」(この項目はログイン中でないと見えないようになっているので注意)のことらしい。ミクシィはそこで次のように言い抜けている。
たしかに、たとえ「友人まで公開」として貼り付けた写真でも、友人に裏切られて無断複製されmixiの外の世界へ放流されてしまう可能性がゼロではないというのは、ミクシィの言う通りなのだろう。それならば、日記本文だって友人に無断複製されてどこかに晒される可能性はあるのだから、いっそ、「友人まで公開」などという紛らわしい機能は廃止してしまってはどうか。A. mixi は会員のみが見ることの出来る招待制サイトですが、mixi にアップした画像は、そのURLからmixi の外でも画像を見ることが出来てしまいます。ブロック機能実装に向け改善と検証を重ねている状況ですが、他人と共有する可能性のある画像を、100%外部から保護することはできないというのがインターネットの現状とも言えます。
ユーザーの皆さまにおかれましては、mixi にアップする画像につきましても、上記の可能性を踏まえた上で掲載していただければ幸いです。
ところで、これは本当に技術的に改修できない性質のものなのだろうか。「画像は img1.mixi.jp ドメインで提供されているため」とあるように、ログイン時に発行されるcookieがそのままでは img1.mixi.jp などのホストへ送られないことが認可制御を導入できない原因であるため、ミクシィは一時、Set-Cookie: において「domain=.mixi.jp」と指定する措置をとったようだが、「おさかなラボ」の2005年8月7日のエントリ「MixiとCookieドメイン」に書かれている問題が発生したために、元に戻したという経緯があるようだ。そのときの様子が「memn0ck.com」の2005年7月21日のエントリ「mixiの仕様変更でN901iSのフルブラウザなどでパソコン向けページが閲覧不能」で紹介されている。これによると、Netscape Communicator 4 や Netfrontなどでログインできなくなったようだ。
さて、どういった方法ならきちんと改修できるだろうか。"
だって (スコア:5, すばらしい洞察)
Re:だって (スコア:2, 興味深い)
有料会員にそれは通用するのですかねえ。
#「βだから安くしてやってるんじゃぁ!」でしょうか?
Re:だって (スコア:3, すばらしい洞察)
9月まで公開(回答)しなかった理由 (スコア:5, すばらしい洞察)
値段が下がらない様に上場終わるまでわざと隠していたのでは??
非常に不誠実な印象をうけます。
Re:9月まで公開(回答)しなかった理由 (スコア:2, すばらしい洞察)
本当にすばらしい企業なら、いくらでも自力でお金を調達できますから。
新興市場ってそういうexitの為の市場ですよ・・・
全部とはいいませんけどね。
Re:9月まで公開(回答)しなかった理由 (スコア:2, おもしろおかしい)
2.すば洞にした
3.続きを読もうとホイールころころ
4.モデレートのコンボが動いてしまう。
5.おもしろおかしいになったことに気づかず
6.モデレート完了
mixi ユーザには通用する? (スコア:4, すばらしい洞察)
って、そりゃそうだけど、それが今回の問題が解決できない理由みたいな書き方はどうかと思う。
mixi ユーザは全体的にリテラシが低いって噂ですが、こんなミスリーディングに簡単に乗っちゃうんでしょうか?
mixiの現状(の一例) (スコア:2, 興味深い)
Re:mixi ユーザには通用する? (スコア:1, 興味深い)
私がたまにみてるブログで、mixiの話題がちらっとでるんだけど、コミュででるPC系の質問のレベルの低さ…質問の内容が低レベルという話じゃなくて質問の仕方が低レベルでなかなか訊ねている核心に辿り着けない…に手を焼いてるそうです。
エウレカ!エウレカ! (スコア:4, おもしろおかしい)
うーん (スコア:3, 興味深い)
mixi.jpから提供するようにすればいいんじゃね?」
ってワシは思うし、みんなまずそれを思いつくと思うんだけど
なんか他の手段で解決しようとしてるとこを見ると
ドメインを変更できない理由があるんだろうね。
Re:うーん (スコア:3, 参考になる)
mixi.jpドメインはロードバランサ配下でスクリプトの実行に専念し、静的コンテンツは(img1.mixi.jp等の)他のサーバからとらせると。
ま、ようするにバランシングの設計がまずかったわけだな。
Re:うーん (スコア:1)
View HTTP Request and Response Header [web-sniffer.net] 「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場:ITpro [nikkeibp.co.jp]
Re:うーん (スコア:3, 興味深い)
icXX.mixi.jp(XXは数字)はApacheかlighttpdの混成だった。
img-p1とimg-p3はfreeoceanでimg-p2はlighttpd。
img1はApacheでimg2はSquid。
よくわからん。
Re:うーん (スコア:1)
img1の方は、静的コンテンツを直接パスで指定し、freeoceanを使うことでロードバランシングのために多数の鯖をそろえるのをケチったわけだな。
結局のところ、当初の設計がまずかったんだろうなあ。ここまでの規模になることを想定していなかったんだろう。
#1039448のいうとおり、認証サーバをたてるのが良いのだろうが、いろいろ書き直しになるんだろうな。あるいは、画像もデータベースに放り込んじゃうとかね(w
でも、いずれにせよ、せっかく買った珍しいおもちゃ(freeocean)を捨てなきゃいけないな。
Re:うーん (スコア:2, 興味深い)
が、増え続ける負荷に対応するための努力の解説に終始しており、画像の認証に関しては言及はありません。
Re:うーん (スコア:1)
小手先だけで何の根本的解決にもなってないですけど、啓蒙だけよりはいくらかましかと。
I think I can
Re:うーん (スコア:4, 興味深い)
直リンクを許容した上で、会員だけしか閲覧できないようにするには
ブラウザに食わせる認証クッキーを*.mixi.jpから参照できるようにするのが簡単な方法。
ただ、そうするとイレギュラー(?)なクッキーを食わせる事になるので認証のトランザクション処理がmixiのサーバで完結できず、ブラウザに依存するようになる。
そのクッキーを許容できないブラウザを切り捨てるとしても、仮に1%としても5万人超のユーザになるわけで簡単に切り捨てると決断するのは難しい(サービス開発者/提供者としての意地もあるだろうし)。
すっきりするのは認証機能を分離/集約してそこからの反応によってwebサーバの(ユーザに対する)応答内容を切り替えるようなシステムに変更することじゃないかな?
ようするに現状のネットワーク/論理構成では問題を解決しようとすると破綻するので"仕様"ってことで一つヨロシクって事。
このトピックのどっかで出てたmixiCTOの公演内容を鑑みるにスケーラビリティの追求に追われてそこらへんは手が回らないのかもしんないですね。
#今こそ上場益を使うタイミングじゃないのか・・・?
Re:うーん (スコア:1)
かといって、Refererが空のアクセスも許可すると、アドレスバーに直打ちで一発回避ですし。
Re:うーん (スコア:1, すばらしい洞察)
mixi内掲示板にその画像URLへのリンクがあったらどうなる?
2個のSet-Cookieじゃだめ? (スコア:2, すばらしい洞察)
Set-Cokkie: sessionid=#############; domain=.mixi.jp
と2つのSet-Cookie:を返すだけじゃ駄目なのかな。
Re:2個のSet-Cookieじゃだめ? (スコア:2, 参考になる)
>Set-Cookie: sessionid=#############; domain=mixi.jp
だと,本文を提供しているmixi.jpにはsessionidが返されるけど,画像を提供しているimg*.mixi.jpやic**.mixi.jpにはsessionidが送られない。
>Set-Cookie: sessionid=#############; domain=.mixi.jp
だとimg*.mixi.jpやic**.mixi.jpにはsessionidが返されるようになるけど,一部のブラウザでmixi.jpには返されなくなり,ログインができなくなる。
ならば,両方つけてしまえば,どのブラウザでも,どちらのサーバーにもcookieが返るのでは? ということだと思う。
社長の日記の画像 (スコア:2, 興味深い)
http://ic46.mixi.jp/photo/diary/13/12/224241312_245.jpg [ic46.mixi.jp]
Re:社長の日記の画像 (スコア:5, すばらしい洞察)
jpg+site:mixi.jp [google.com]
Re:社長の日記の画像 (スコア:1, 興味深い)
……あ、こういうことなのか。
http://img1.mixi.jp/robots.txt [img1.mixi.jp]
http://img2.mixi.jp/robots.txt [img2.mixi.jp]
:
:(他のサブドメインは見てない)
:
http://ic46.mixi.jp/robots.txt [ic46.mixi.jp]
Re:社長の日記の画像 (スコア:3, おもしろおかしい)
そいでもって、タイーホされちゃったら...
(((( ;゚Д゚)))ガクガクブルブル
#アクセスしちゃって、それが怖くて今晩寝れそうにないのでAC(mixi非会員)
Re:社長の日記の画像 (スコア:2, おもしろおかしい)
今までこの手のねたでは、疎外感に包まれていたけど
初めてmixiドメインのページを見ることが出来た!!!
Re:社長の日記の画像 (スコア:1, 参考になる)
# アフロ? の人が気になる
apacheだとすると (スコア:1)
# 対策のために鯖を増強する金が惜しいというのが本音なような気がする。
Re:apacheだとすると (スコア:1)
理論的には出来るけど、現実的に出来ていないと。
(もちろん会員以外から画像が見えてしまう事に対するプライオリティが低いというのもありそうですが)
Masafumi Otsune [otsune.com]
Re:apacheだとすると (スコア:2, 参考になる)
img.mixi.jp CNAME img.mixi.jp.edgesuite.net
img.mixi.jp.edgesuite.net CNAME a899.g.akamai.net
日記などの、登録後数日でアクセスが殆んど無くなるような画像は img*.mixi.jp や ic*.mixi.jp などの mixi が持っているサーバに割り当てられているようです。Akamaiを使っている部分は難しいとしても、せめてこちらだけでもなんとか出来ないのかなと思いますが。
Re:apacheだとすると (スコア:1, 興味深い)
http://mixi.jp/show_picture.pl?img_src=http://ic**.mixi.jp/photo/diary... [mixi.jp]
みたいに、cgiを介してるんですよねえ。
なのに、パラメータ指定されているURLに直接アクセスできる謎仕様。
Re:apacheだとすると (スコア:2, おもしろおかしい)
/* Kachou Utumi
I'm Not Rich... */
Re:apacheだとすると (スコア:1)
# その場合QUERY_STRINGは空になってるから代わりにURLの方をパースする。
その場合の処理って軽いの? (スコア:2)
1. クッキーよりセッションキーを取得
2. セッションキーよりユーザーIDを取得
3. ユーザーIDに基づき、可視性を判断
3-1. 画像のURL (path) より表示されている場所を特定
3-2. 表示されている場所がコミュニティの場合
3-2-1. if (コミュニティが公開されている) 表示
3-2-2. else if (コミュニティにユーザーIDが属している) 表示
3-2-3. else 不表示
3-3. 表示されている場所がユーザースペースの場合
3-3-1. if (ユーザースペースは画像を公開する設定) 表示
3-3-2. ユーザーIDとユーザースペース所有者の関係の特定
3-3-3. if (ユーザーIDとユーザースペース所有者が友人の場合) 表示
3-3-4. ユーザーIDとユーザースペース所有者が友人の友人の場合
3-3-4-1. if (ユーザースペース所有者は友人の友人に表示を許可している) 表示
3-3-4-2. else 非表示
...というのを日記やプロフィール表示の場合は毎回やりますが、それを画像にまで広げるとさすがに負荷が高くなり過ぎないですかね?
URLの類推可能性はそんなに高くなく、画像が格納される場所のURL空間もかなり広いので脆弱ではあってもそんなに大きな問題にはならないのではないかと思うのですよね。
ここを保護してもダウンロードしてバラまかれたら意味ないわけですし。
もちろん、mixi運営部にもわかるようなブルートフォース攻撃をかければmixi内の全ての画像はゲットできますが、それには404 not foundを連続して出しているIPアドレスにペナルティを課す等の別の対策で十分何とかなるのではないかと思います。
Q&A消滅? (スコア:1)
Re:Q&A消滅? (スコア:5, 興味深い)
ログインしないとヘルプページが見れないのではなく、
ログインしていないヘルプページには、件のQ&Aは表示されないのですね。
失礼しました。
mixiアカウントを持っていない人にこの脆弱性を教えたくないから?それとも批判回避?
無断複製される可能性があるからアクセス制御しないというのは無茶 (スコア:1)
>いっそ、「友人まで公開」などという紛らわしい機能は廃止してしまってはどうか。
無断複製される可能性があるからと言って、アクセス制御しない、アクセス制御がなされていると勘違いされるような表記はまぎらわしいいというのは無茶な話ではないかと思います。問題は「転載、複製」という(著作権者が許諾しない場合には)違法な行為をしなくてもアクセスできてしまうことにあるのですから。
なので、結論として「いっそ、『友人まで公開』などという紛らわしい機能は廃止してしまってはどうか。」という意見には賛成なのですが、その理由が「無断複製されてしまう可能性だってあるのだから」というのはちょっと無理があると思います。
屍体メモ [windy.cx]
CTO (スコア:5, おもしろおかしい)
#両リンクともみるのにmixiログインが必要な"ハズ"です。
I think I can
お約束(Re:根本的に腐ってる) (スコア:3, おもしろおかしい)
Re:お約束(Re:根本的に腐ってる) (スコア:4, おもしろおかしい)
単純にコストの問題とか? (スコア:3, すばらしい洞察)
・ ページHTML出力 - 認証付 1
・ プロフィール画像 - 認証無 1
・ マイミク画像 - 認証無 9
・ コミュニティ画像 - 認証無 9
・ 紹介文画像 - 認証無 5
となっていて、これを全て認証付きにすると、認証サーバの能力を25倍に増強する必要があるという計算があったのかもしれない。
よって、改修しない方が低コストという結論になったのかもしれない。
もちろん憶測ですが。
Re:根本的に腐ってる (スコア:2, 興味深い)
LDAPでもNISでもWindows Directory Serviceでも何でもいいけど、状況に見合ったドメイン認証システムがあるでしょうに(;´Д`)
認証サーバ一個置いてそことDBとかWEBフロントエンドが認証取れば済むような…(?_?)
設計時点でこういう事態を想定していなかったんでしょうけど、システム設計者はここまでメジャーなサイトになることやこの手の穴が出ることまで想定出来なかったんでしょうね。
あの規模のサイトを百人程度で回していれば、新しいシステムの開発・テストなんか出来ない。って理屈なんでしょうけど。mixi側とすると…(;´Д`)
# なんか、mixiが絡むとしみったれた話が急増してくるような気がします。気だけですけど(;´Д`)
Re:根本的に腐ってる (スコア:5, 参考になる)
↓
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 [nikkeibp.co.jp]
Re:根本的に腐ってる (スコア:2, すばらしい洞察)
甘い見通しでスタートしちゃったので小手先のテクニックでごまかしながら対処してます
ってことかな?
Re:根本的に腐ってる (スコア:1)
で、今回クライアントはブラウザなんですけど、困ったことに、分母が大きいため「そんなブラウザ捨ててしまえ!」といいたくなるブラウザを使ってる人が、数で言えば相当数に上るから切り捨てられないということでしょう。
「これこれといった問題があるので切り捨てます」というのをオブラートに包んで言えば何とかなるんじゃ?というのはアレゲの戯言なんでしょうかねぇ。
Re:根本的に腐ってる (スコア:1)
画像を見た人が外部にURLを漏らしちゃってるわけだから
仮に、しっかりと認証できたとしても
URLを漏らすんじゃなく勝手に転載するって行為に変わるだけ
ってことはそういうことをする悪意のある会員にまず問題があり、
そいつを紹介した会員にも問題があり......ってなるから
会員集めからやり直さないと根本的解決にはならなそ
Re:といっても (スコア:2, すばらしい洞察)
Re:といっても (スコア:3, おもしろおかしい)
Re:選択肢 (スコア:3, すばらしい洞察)
なんか、/.とかに取り上げてもらって、解決方法を知りたいだけのような気がします。