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

IIJmioの新アプリ「My IIJmio」で別ユーザー情報が誤表示されるトラブル。サービス停止へ 45

ストーリー by nagazou
誤表示 部門より

IIJは16日、7月15日から同社が提供している「IIJmioモバイルサービス ギガプラン」用の専用アプリ「My IIJmio」において、利用者とは別のユーザー情報が表示される不具合があったと発表した。この影響により「My IIJmio」の提供は15日18時55分に一時停止されている。影響が確認されているのは254名分。誤表示された情報は以下の通りとなっている(IIJリリースケータイ Watch)。

  • 電話番号の一部 (4桁目から7桁目までがマスクされた状態)
  • データ残量
  • データ残量有効期限
  • データ利用量
  • ご請求金額
  • 高速通信ON/OFFの状態
  • 5Gオプション
  • データシェアの設定状態
  • ご契約情報 (mioID、サービスコード、サービス状態、料金プラン、申し込み日、利用開始日)
  • Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。
    https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org]

    にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として
    Cache-Control: no-store を挙げていて、
    プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として
    Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
    を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。

    今回の件が、このせいかどうかは分かりませんが、MDNを信じて情報漏えいが起きたケースは業界で割とよく耳にします。

    ある程度の規模のサイトや、世界を対象としたサイトでは、CDNを使うのが今の常識です。
    大手サイトでCDN使ってないケースなんてきわめてまれです。CDNを考慮していない解説は、セキュリティ上不適切です。

    「レスポンスがどのキャッシュにも保存されないようにするには、代わりに no-store を使用してください。」(no-cache の解説より)
    「no-store レスポンスをキャッシュに保存することはできません。他のディレクティブを設定することもできますが、最近のブラウザーではレスポンスがキャッシュされることを防ぐために必要なディレクティブはこれだけです。」(no-store の解説より)

    特に上の解説が酷く「no-store」で「どのキャッシュにも」保存されないかのような書き方、つまりCDNもキャッシュしないかのような書き方をしていますが、
    no-store を普通にキャッシュする CDN は非常に多いです。

    ブラウザのキャッシュ制御とCDNのキャッシュ制御を分けられないと不便ですから、
    「no-store」はブラウザ向けの指示、「private」は CDN やプロキシ向けの指示として扱われているのが、現状の実装のデファクトスタンダードです。

    つまりは、どこにもキャッシュさせたくなければ「悪い例」の書き方が正解なのです。
    「private」(これがあるとCDNはキャッシュしないか、CookieのセッションIDで同一の端末のみ有効なキャッシュとする)、
    「max-age=0」(キャッシュの有効期限0秒としてキャッシュしないCDNも無いわけではないかもしれないが、基本はブラウザ向けの指示と解釈される)とCDNのキャッシュ無効化に役立つ項目もきちんと含まれています。
    「pre-check」と「post-check」は IE5 の独自拡張でIE6で廃止されたはずなので今更必要ありませんが、あっても通信容量が25バイト無駄に消費される以外の害はありません。

    なお、『「private」を含めよう』の対象は、個人情報などのユーザ個別のプライベートな情報を含む全てのページです。
    プライベートな情報を含まないページにもつけたら、CDNが全ページキャッシュできなくなってCDNの役目が減ります。
    (CDNによっては private を付けた場合はCookieのセッションIDをもとにそのユーザのみを対象としたキャッシュとして扱うこともあります)

    ※CDNが独自のヘッダー等でのキャッシュ設定をしている場合に、「no-store」かつ「private」でもキャッシュする場合があることは否定できません。
    ※CDNのマニュアルを読むことが重要なのですが、CDNで急に障害が発生して予定していない他のCDNに急いで乗り換えることになるケースとか、
     急にDDoSを受けたとかで慌てて作業することになるケースが多いので、そういうケースも想定して乗換候補のCDNの説明書なども読んで色々なCDN向けのヘッダーを山ほど予めつけておくことが大切です。

    ここに返信
    • by Anonymous Coward

      「no-store」でキャッシュするような CDN を使った時点で負けなんじゃないか?

      • by Anonymous Coward on 2021年07月19日 16時49分 (#4074000)

        CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
        https://engineering.mercari.com/blog/entry/2017-06-22-204500/ [mercari.com]

        問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは
        Cache-Control: private
        が含まれている場合のみとわかりました。

        「場合のみ」とあるので、「no-store」じゃ駄目で「private」の必要があるとあります。
        CDN業者の名前は書かれていませんが、有名アプリのメルカリが使うような大規模なCDNでも、「no-store」無視の仕様だったりするのです。

        また、

        Expiresヘッダは、Cache-Controlヘッダにmax-ageまたはs-maxageがない場合採用されます。ただし、過去の日付である場合、0秒として扱われます。キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様になっていました。
        このため、お客さまがWeb版メルカリに対してアクセスを行い、メルカリのサーバがレスポンスを構築している途中で、別のお客さまから同じURLに対してリクエストがあった場合、レスポンスがまとめられ、最初のお客さまの情報がふくまれたコンテンツが別のお客さまへ配信される事態に至りました。

        と、キャッシュ有効期限を0秒としても、「サーバがレスポンスを構築している途中」に次のアクセスがあると0秒扱いになってキャッシュが使われてしまって、それで情報漏えいが起きたようです。

        ほんの一瞬でキャッシュの有効期限が切れるので、負荷テストのような大量アクセスをするテストでないと問題が再現せず発覚しにくいです。

        • まともな議論になってないから、遅ればせながら指摘するけど、“CDNが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもCDNに対するディレクティブではない。「Cache-Control」フィールド自体、CDNが無い時代に作られた。「Cache-Control: private」はCDNが無断借用しているだけ。
          CDNというのは、HTTP仕様としては違法や脱法的扱いのもの(違法改造)で、限定的に使われていたもの(動画配信やアップデート)が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。
          だから、 #4073928 の指摘は

          • by Anonymous Coward

            質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの?

            HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。

          • これは酷い。
            そもそも、ダイアルアップが主流の「インターネット」が高価だった時代は、キャッシュするプロキシの存在が一般的だったのじゃぞ。
            会社・学校などの組織がそれぞれプロキシを運用していたのじゃ。

            例えば、児童・生徒・学生がパソコン室から20台で同じサイトを見たら帯域がもたないから、公開のプロキシサーバがキャッシュして1回ですむようにしていたのだ。

            当時有名なのは Squid というプロキシで、1996年 (25年前)からあったのじゃぞ。

            その後、利用可能な帯域幅が増えて、組織がプロキシサーバを持たなくなってきて、その後、常時SSL化(TLS化)の流れでキャッシュがしにくくなって廃れていったというのが歴史の流れ。

            ということで、大昔から Cache-Control で共有キャッシュの制御は行われていたし、RFCにもそれを想定した記述が山ほどある。

      • 時代に乗り遅れてる老害的な書き込みだなぁ
        それだと今流行のFastlyも使えなくなる

        Reddit、Spotify、Twitch、Stack Overflow、GitHub、gov.uk、Hulu、HBO Max、Quora、PayPal、Vimeo、Shopify、Stripe、CNN、The Guardian、The New York Times、BBC、Financial Times
        これ全部 Fastly 使ってるぞ

        https://support.fastly.com/hc/en-us/community/posts/360040167351-Fastl... [fastly.com]

        最初にキャッシュを行わない条件について理解しておきましょう。Fastlyサーバーでは以下の条件の場合はキャッシュを行いません。
        ・オリジンからのレスポンスにCache-Control: private が含まれている
        (Cache-Control: no-store, no-cache はキャッシュ対象となります)

        • by Anonymous Coward

          Fastly が流行的で大手なのは認める(ついでに老害というのも認めよう)。
          でも、事故の臭いのするものを使ってキャッシュ漏れるなら、別のサービス利用したら良くない?って私は考えるよ。

          • by Anonymous Coward on 2021年07月19日 22時43分 (#4074228)

            何故 Fastly を使うのか [hatelabo.jp] を読んで欲しいんだけど、
            「普通の CDN が数十秒?数分とかかるのにたいして 0.2 秒で全部消えることが保証されている」の部分が今 Fastly が流行ってる理由なの。

            え、たった0.2秒? それ意味あるの? と思うかもしれない。
            でも、よく考えて欲しいんだけど、それだと例えば掲示板やチャットサイトでも使える。
            スラドのコメントだって反映に0.2秒かかっても問題ないからスラドでも問題なくキャッシュが活用できる。
            0.2秒の遅延が許せない場合を除けば、リアルタイムのニュース配信だってなんだってキャッシュできるし、いちいちこのコンテンツは○分キャッシュして~なんて考えなくて良いわけ。

            キャッシュサーバが0.2秒キャッシュしてくれるだけで、当該ページへのオリジンへのアクセスは秒間5回ですむ。
            それならどんなへっぽこサーバだって当たり前に捌けるわけで、0.2秒もキャッシュしてくれれば実は十分なわけだ。

            で、そうなるとブラウザキャッシュって邪魔だよね。
            ブラウザの「戻る」を使ったときにもメモリキャッシュなんて使わずに最新(遅延0.2秒未満)の情報をロードして欲しい。
            スラドだったら「戻る」で戻っても新しいコメントが反映されてた方がユーザが新しいコメントに気が付いて返信増えてサイトが盛り上がるかもしれない。

            だとすると、自然とブラウザキャッシュを無効にしたくなるし、そのためには、

            Cache-Control: no-store

            とすることになる。(ちなみに、仮にブラウザキャッシュの有効期間1秒にしても、1秒以上経過した後でもブラウザの戻る・進む機能ではメモリキャッシュが使われることもあるので no-store にした方が確実)

            それで Fastly のキャッシュも無効になったら不便なので、機密だからキャッシュして欲しくないコンテンツには、「private」の方を使って制御した方が便利、ということになる。

            # RFC的には no-store をキャッシュするのはよくから、RFCに反する挙動に関する警告をもっとしっかり告知すべきだとは思うが。

            しかし、CDN業者に関連RFC守れというのは、正直関係RFC自体が古臭くてどうしようもなくなっているからRFC守ったらイノベーションが破壊されるのが現状だと思う。

            例えば、キャッシュ時間を制御するための max-age は、「秒」単位なんだよね。

            https://datatracker.ietf.org/doc/html/rfc7234#section-1.2.1 [ietf.org]
            「The delta-seconds rule specifies a non-negative integer, representing time in seconds.」とあるから小数点も使えない。

            CDNのキャッシュを 0.2秒 にする時代に、キャッシュ時間指定に秒単位の整数で指定って、正直時代にそぐわない。あまりにも美しくない。

            ってことで、
            ・「Cache-Control: no-store」でブラウザキャッシュは完全無効(更新しない png, css, js 等は除く)
            ・CDN のキャッシュ時間は全ページ 0.2秒
            ・個人情報を含むページは「Cache-Control: private」でCDNキャッシュ無効
            のシンプル運用がお勧めなのです。

            Fastlyは素晴らしいのでFastly使いましょう。

            これが「別のサービス利用したら良くない?」への反論です。

      • by Anonymous Coward

        いまのインターネットは人類に対して複雑すぎるのかもしれないですね :D

        MDNはあくまでブラウザの仕様について書かれているドキュメントなんで
        ここにCDNを考慮した内容を載せるというのはちょっと期待し過ぎかなーと個人的には思います
        もちろんそこまで考慮した内容になっているに越したことはないのですが...

        CDNのドキュメントちゃんと読めというだけの話に思えるのですが
        正直こんなのわからん人にはわからんような気がしていて
        前にメルカリで事故ったやんと言ってもそれ知らない人にとっては一体何が悪かったのかわからない
        (場合によっちゃあ間にCDN入ってることすら知らなかった可能性あ

        • by Anonymous Coward

          そのMDNのページ、「共有キャッシュ」「プロキシ」でページ内検索すると色々書かれているので、中途半端に共有キャッシュのことに触れているのが問題かと……

        • by Anonymous Coward

          キャッシュ制御に関係するHTTPヘッダー、Cache-ControlのほかにSurrogate-ControlとCDN-Cache-Controlもあり、そういえば自分はいつどうやって知ったんだっけ?みんなどうやって知るんだ?とか思う。

          さらには、個人的なものだと慎ましくCDN使っておらず、NginxのX-Accel-ExpiresとX-Accel-Bufferingを考慮したりしなかったりする。

        • by Anonymous Coward

          MDNの内容に問題があるのならCDNの中の人か、問題意識を持っている当人が働きかけるべきなんじゃって気がしますね。
          (GitHubで内容修正のプルリク出せるよね?)
          CDNでの挙動についてMDNを悪者にするのは違うと思う。

  • by Anonymous Coward on 2021年07月19日 12時07分 (#4073847)

    His (Her) IIJmioだったわけですな

    ここに返信
  • by Anonymous Coward on 2021年07月19日 12時29分 (#4073857)

    個人情報部分にまでリバースプロキシを噛ませたに1ギガ。

    ここに返信
    • by Anonymous Coward

      しばらくこのサービスは動かないみたいだけど、リバースプロキシの問題だけなら比較的時間はかからずに改修できるのではないでしょうか?

      • by Anonymous Coward on 2021年07月19日 12時49分 (#4073867)

        たとえリバースプロキシだけが問題だったとしても、
        ・何が問題だったのか、根本原因の深堀
        ・他に同種の問題が無いか、水平展開
        ・再発防止策
        までそろえないと再開できないってのが、真っ当な企業ってもんですぜ。

        • by Anonymous Coward on 2021年07月19日 13時42分 (#4073891)

          >・何が問題だったのか、根本原因の深堀
          担当者のミスでした!

          >・他に同種の問題が無いか、水平展開
          ないと言ってるので問題なし!

          >・再発防止策
          チェックリストを作ったのでヨシ!

          みたいな企業も多いような。

          • by Anonymous Coward

            理由の無いミスは普通にある。それを認めないと理由はデッチ上げになるよ。

            • by Anonymous Coward

              人間だったらミスをする。ヒューマンエラー。それを認めない問題分析は意味が無い。
              ミスが起きる前提で、如何にミスを流出させないようにするかが企業努力です。

              工具だったら色分けする、大きさを変える、とか、
              コードだったらlint通す、テストの手法改善する、とか。

              • by Anonymous Coward

                ミスが起きる前提?
                大抵の日本企業は「ミスが起きないのが前提」で、「ミス対応を考えるなら、そのミスが100%起きないようにしろ」というのが企業努力です。
                ヒューマンエラーなんて以ての外。そんなことはありえない……という前提でしか行動できないので、なにか起きると対応できずに大事になるばかり。

                責任? 担当者が辞めればOKでしょ?

            • by Anonymous Coward

              理由のないミスがなんなのか考えてみたけど何一つ出てこなかったので、具体例を挙げていただけると助かる

              # ちなみに「うっかりミス」も「うっかり」という理由のあるミスです

              • by Anonymous Coward

                なぜ、うっかりしたのですか?

        • by Anonymous Coward

          たとえリバースプロキシだけが問題だったとしても、
          ・何が問題だったのか、根本原因の深堀
          ・他に同種の問題が無いか、水平展開
          ・再発防止策
          までそろえないと再開できないってのが、真っ当な企業ってもんですぜ。

          たしかにその通りですが結構こういうのもある

          偉い人「どうしてこうなった!」
          管理者「こうこうこういう経緯であります」
          偉い人「どうしてそうなった!」
          管理者「こうこうこういう、、、
          偉い人「言い訳するな!」
          管理者「。。。。。」
          偉い人「なんとか言え!」
          管理者「こういった対策を、、、
          偉い人「質問に答えろ!」


          # 仕組みルールも人で壊れるみたいな

    • by Anonymous Coward

      Servletでスレッドをわかっていない初心者がやらかしたとか。
      これもありそうかと思った。

  • by Anonymous Coward on 2021年07月19日 13時03分 (#4073871)

    他人の取引画面が目の前に表示された、数秒間。
    他のユーザーメール(特定)が継続的に届いた。

    ここに返信
    • by Anonymous Coward

      自分のところは出てないけど、自分のが出てた可能性もあるかな。
      そもそもアプリが毎度ログインなのがめんどくさかった。
      そのうちみおぽんみたいなAPI公開されるのかな。

    • by Anonymous Coward

      > 他のユーザーメール(特定)が継続的に届いた。

      これ、IIJのリリースには載っていないけど、IIJは把握しているのでしょうか?

  • by Anonymous Coward on 2021年07月19日 13時04分 (#4073873)

    IIJmioのギガプラン組ですが
    プラン移行後新アプリもまだ入れてないし
    ここ一週間くらいはブラウザでもマイページにアクセスしていなかったので
    キャッシュならセーフ
    そうでないならアウトかも
    という判断がつくかなと

    ここに返信
    • by Anonymous Coward

      全く報道もプレスリリースも出てないけど、
      楽天買収後のFREETELで2019年1月7日にログインページとログインした後に、妙な乱数が表示される不具合があった
      俺も確認したし、5ちゃんに書き込んでるやつもいる
      https://mao.5ch.net/test/read.cgi/isp/1496688608/943-944n [5ch.net]

      この乱数は一体何だったんですかね楽天モバイルさん???
      何かハッシュ流出とCloudbleedみたいなのだったらやだよ

      • by Anonymous Coward

        楽天ならともかくIIJがやらかすとは...

        • by Anonymous Coward

          楽天なら「ざまぁwww」ってなもんだが、IIJがとなれば俺は明日から何を信じて生きて生きていけバインダー

          • by Anonymous Coward

            ごめん動揺し過ぎて日本語おかしくなった

        • by Anonymous Coward

          関連リンク見てもCloudflare、メルカリ、Amazonがやらかしてるわけだし

  • by Anonymous Coward on 2021年07月19日 15時03分 (#4073948)
    1. 4月1日にギガプランを見切り発車で提供開始
    2. 6月1日にギガプランを機能拡充、ただし会員専用アプリ「My IIJmio」は6月以降に提供予定と発表 [iij.ad.jp]
    3. 結局6月中にはアプリを提供できず(発表では6月「以降」なので想定内だが、サービス自体は4月に始まってるのですでに3カ月遅れのうえ、見通しの立たない状態に批判が増え始める)
    4. 7月3日のIIJmio meeting30 [youtube.com]でアプリの提供遅れを陳謝、サービス開発の裏側を赤裸々トーク
    5. 7月14日にIIJmioモバイルサービスで通信データ量管理のソフトウェア障害発生 [iijmio.jp]
    6. 7月15日に専用スマホアプリ「My IIJmio」を提供開始 [iijmio.jp]
    7. 同日セキュリティインシデントが発生

    なるべくしてなったような気がしてならない

    ここに返信
    • by Anonymous Coward

      財務省OBが入ったあたりからおかしくなりましたよね、IIJ。

      日本の税制を設計して責任を取らないで逃げ切る老害連中だから、さもありなんだが。

  • by Anonymous Coward on 2021年07月19日 20時36分 (#4074139)

    元々このアプリ6月中提供って言ってたんだよ。それなのに7月までズレ込んでこのザマ。
    ついでにIIJmioで調べると利用料金の決済額の間違えだの日付通りに金が落とされないだの色々なトラブルだらけ。
    技術力が偏りすぎなのでは?

    IIJは基本的にユーザーの通信を弄らない(通信の最適化とかhttpsペーシングとかTCP最適化をやらない)所が好きなので、もっと頑張って欲しい。

    ここに返信
    • by Anonymous Coward

      ズレ込んでるから、このザマなんだろ

    • by Anonymous Coward

      素人なので通信を弄らないの範囲がよく分かりませんが、ギガプランは必ずDNSフィルタリングする仕様なので、全く触らないってことではないと思います。

typodupeerror

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

読み込み中...