パスワードを忘れた? アカウント作成
13670 story

ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解 160

ストーリー by mhatta
手に負えない 部門より

jbeef曰く、"セキュリティホールmemo経由葉っぱ日記10月17日のエントリによると、2005年5月にIPAの脆弱性情報届出窓口に届け出られたmixiの欠陥の件が、1年半たってようやく決着したという。この欠陥は、mixi内でアップロードされた画像が、mixiにログインしていなくても画像のURLを指定すれば誰にでも閲覧できてしまうというもの。もっとも、数百万人の会員がいるとされるmixiでは、いずれにせよ誰にでも見られるのに等しいのだから問題じゃないという考え方もあろう。しかし、「友人まで公開」に設定している日記の画像はどうだろうか。普通のユーザなら、写真画像も「友人まで公開」だと信じて貼り付けるのではなかろうか。
葉っぱ日記によると、IPAはこれを脆弱性として受け付け、取り扱いを開始したものの、11か月後の2006年4月になって、ミクシィ側からギブアップの連絡があったという。その内容は、「システムの改修にて試みましたが、いくつかのプラットフォームにおいてログインができなくなった」「全ユーザーに対応させることは非常に難しい」というもので、改修しないということで取り扱い終了となったそうだ。その際ミクシィは、「近々公開予定のユーザー向け啓蒙コンテンツの中で写真掲載時の注意を訴えて行く」と約束したのだそうだが、それが公開されたのは5か月後の9月だったという。(つづく)"

"その「啓蒙コンテンツ」とは、mixiの「ヘルプ」ページ内のひとつのQ&Aとして掲載された「Q.掲載した画像のURL をログアウトした状態でクリックしても、画像を見ることができる?」(この項目はログイン中でないと見えないようになっているので注意)のことらしい。ミクシィはそこで次のように言い抜けている。

A. mixi は会員のみが見ることの出来る招待制サイトですが、mixi にアップした画像は、そのURLからmixi の外でも画像を見ることが出来てしまいます。ブロック機能実装に向け改善と検証を重ねている状況ですが、他人と共有する可能性のある画像を、100%外部から保護することはできないというのがインターネットの現状とも言えます。
ユーザーの皆さまにおかれましては、mixi にアップする画像につきましても、上記の可能性を踏まえた上で掲載していただければ幸いです。
たしかに、たとえ「友人まで公開」として貼り付けた写真でも、友人に裏切られて無断複製され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, すばらしい洞察)

    by flutist (16098) on 2006年10月18日 12時08分 (#1039421)
    まだβ版ですから。(笑
  • by Anonymous Coward on 2006年10月18日 12時32分 (#1039458)
    ミクシィの上場が9/14。
    値段が下がらない様に上場終わるまでわざと隠していたのでは??

    非常に不誠実な印象をうけます。
  • by Anonymous Coward on 2006年10月18日 12時32分 (#1039460)
    > インターネットの現状とも言えます。

    って、そりゃそうだけど、それが今回の問題が解決できない理由みたいな書き方はどうかと思う。

    mixi ユーザは全体的にリテラシが低いって噂ですが、こんなミスリーディングに簡単に乗っちゃうんでしょうか?
  • エウレカ!エウレカ! (スコア:4, おもしろおかしい)

    by copel (28292) on 2006年10月18日 15時18分 (#1039669)
    驚くべき解決策を私は見つけたが、これを記すには余白が狭すぎる
  • うーん (スコア:3, 興味深い)

    by Inetpub (20077) on 2006年10月18日 12時08分 (#1039420)
    「img1.mixi.jpで提供しているものを
    mixi.jpから提供するようにすればいいんじゃね?」
    ってワシは思うし、みんなまずそれを思いつくと思うんだけど
    なんか他の手段で解決しようとしてるとこを見ると
    ドメインを変更できない理由があるんだろうね。

    • Re:うーん (スコア:3, 参考になる)

      by Another_View (29838) on 2006年10月18日 12時15分 (#1039433) ホームページ 日記
      単純にロードアベレージの問題ではないか?。
      mixi.jpドメインはロードバランサ配下でスクリプトの実行に専念し、静的コンテンツは(img1.mixi.jp等の)他のサーバからとらせると。

      ま、ようするにバランシングの設計がまずかったわけだな。
      親コメント
    • 素人考えですが、せめてimg1.mixi.jpへのアクセスはリファラがmixi.jpのみ許可とかできなかったんでしょうか。
      小手先だけで何の根本的解決にもなってないですけど、啓蒙だけよりはいくらかましかと。
      --
      I think I can
      親コメント
      • Re:うーん (スコア:4, 興味深い)

        by nikomi (28640) on 2006年10月18日 15時02分 (#1039655)
        外部からの直リンクを一切禁止にする(リファラ見て弾く)とユーザビリティが下がる。
        直リンクを許容した上で、会員だけしか閲覧できないようにするには
        ブラウザに食わせる認証クッキーを*.mixi.jpから参照できるようにするのが簡単な方法。
        ただ、そうするとイレギュラー(?)なクッキーを食わせる事になるので認証のトランザクション処理がmixiのサーバで完結できず、ブラウザに依存するようになる。
        そのクッキーを許容できないブラウザを切り捨てるとしても、仮に1%としても5万人超のユーザになるわけで簡単に切り捨てると決断するのは難しい(サービス開発者/提供者としての意地もあるだろうし)。

        すっきりするのは認証機能を分離/集約してそこからの反応によってwebサーバの(ユーザに対する)応答内容を切り替えるようなシステムに変更することじゃないかな?

        ようするに現状のネットワーク/論理構成では問題を解決しようとすると破綻するので"仕様"ってことで一つヨロシクって事。

        このトピックのどっかで出てたmixiCTOの公演内容を鑑みるにスケーラビリティの追求に追われてそこらへんは手が回らないのかもしんないですね。

        #今こそ上場益を使うタイミングじゃないのか・・・?
        親コメント
      • by Angelica (23122) on 2006年10月18日 12時32分 (#1039459) 日記
        それはそれで、セキュリティソフトが満足にいじれない層から苦情が来そう。一部の製品はRefererをいじりますからね。

        かといって、Refererが空のアクセスも許可すると、アドレスバーに直打ちで一発回避ですし。
        親コメント
      • Re:うーん (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2006年10月18日 12時56分 (#1039499)
        > 素人考えですが、リファラがmixi.jpのみ許可とか

        mixi内掲示板にその画像URLへのリンクがあったらどうなる?
        親コメント
  • by Anonymous Coward on 2006年10月18日 12時16分 (#1039435)
    Set-Cokkie: sessionid=#############; domain=mixi.jp
    Set-Cokkie: sessionid=#############; domain=.mixi.jp

    と2つのSet-Cookie:を返すだけじゃ駄目なのかな。
  • by Anonymous Coward on 2006年10月18日 12時40分 (#1039473)
    mixiのIDが無くとも見られるかテストしてみて~

    http://ic46.mixi.jp/photo/diary/13/12/224241312_245.jpg [ic46.mixi.jp]
  • パスの一部をCGIとして動かせるはずだ。というわけで、どこかにチェック用CGIでも置けばいんじゃね?
    # 対策のために鯖を増強する金が惜しいというのが本音なような気がする。
    • CTO講演などによると、現状でmixiの画像サーバーはAkamaiの利用を含めてかなりの負荷対策をしているらしいので、チェック用CGIを入れたら負荷に耐えられないのではないでしょうか。

      理論的には出来るけど、現実的に出来ていないと。
      (もちろん会員以外から画像が見えてしまう事に対するプライオリティが低いというのもありそうですが)
      --
      Masafumi Otsune [otsune.com]
      親コメント
      • by yoosee (196) on 2006年10月18日 17時13分 (#1039763) ホームページ 日記
        Akamaiを使っているのは img.mixi.jp で、これは mixi の共通画像(UIのボタンや背景)やプロフィール写真、コミュニティ画像などの表示頻度が高くて変更頻度が低いものに使われているようです。

        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を使っている部分は難しいとしても、せめてこちらだけでもなんとか出来ないのかなと思いますが。
        親コメント
    • by Anonymous Coward on 2006年10月18日 13時25分 (#1039545)
      実際、mixiの日記の画像表示は
      http://mixi.jp/show_picture.pl?img_src=http://ic**.mixi.jp/photo/diary... [mixi.jp]
      みたいに、cgiを介してるんですよねえ。
      なのに、パラメータ指定されているURLに直接アクセスできる謎仕様。
      親コメント
      • Re:apacheだとすると (スコア:2, おもしろおかしい)

        ic**.mixi.jpをグローバルIPでなく、ローカルIPにしておけば…なんて、安直に考えてしまった。
        --

        /* Kachou Utumi
        I'm Not Rich... */
        親コメント
      • んーと、mixi.jpの方は認証されてるからそのままでいいんだ。問題はic**.mixi.jpの方で、こっちがだだ漏れになってるんだから例えば「ic**.mixi.jp/photo」っていうCGIを置こうよって話。そういうCGIがあるとapacheだとhttp://ic**.mixi.jp/photo/diary/**/**/**.jpgをアクセスしたときにそのCGIが動いてくれる。
        # その場合QUERY_STRINGは空になってるから代わりにURLの方をパースする。
        親コメント
        • まあ、その手のCGIを入れた場合の処理は、単純に実装するとこうなりますが、軽いんですかね?

          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アドレスにペナルティを課す等の別の対策で十分何とかなるのではないかと思います。
          親コメント
  • by IKeJI (13535) on 2006年10月18日 12時38分 (#1039470) ホームページ
    今見たら、Q&Aにあったという啓蒙コンテンツが見つからないのですが、 どこにあるのでしょうか?
    • Re:Q&A消滅? (スコア:5, 興味深い)

      by IKeJI (13535) on 2006年10月18日 12時44分 (#1039476) ホームページ
      自己レスです。

      ログインしないとヘルプページが見れないのではなく、
      ログインしていないヘルプページには、件のQ&Aは表示されないのですね。
      失礼しました。

      mixiアカウントを持っていない人にこの脆弱性を教えたくないから?それとも批判回避?
      親コメント
  • >それならば、日記本文だって友人に無断複製されてどこかに晒される可能性はあるのだから、
    >いっそ、「友人まで公開」などという紛らわしい機能は廃止してしまってはどうか。

    無断複製される可能性があるからと言って、アクセス制御しない、アクセス制御がなされていると勘違いされるような表記はまぎらわしいいというのは無茶な話ではないかと思います。問題は「転載、複製」という(著作権者が許諾しない場合には)違法な行為をしなくてもアクセスできてしまうことにあるのですから。

    なので、結論として「いっそ、『友人まで公開』などという紛らわしい機能は廃止してしまってはどうか。」という意見には賛成なのですが、その理由が「無断複製されてしまう可能性だってあるのだから」というのはちょっと無理があると思います。
    --
    屍体メモ [windy.cx]
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...