2011年7月2日(土曜日)
secure.softbank.ne.jp廃止の舞台裏
公開: 2011年7月11日2時10分頃
secure.softbank.ne.jpが廃止されたことに伴い、なぜ廃止しなければならなかったのか、その背景についての解説が相次いで公開されています。
- secure.softbank.ne.jp ヤバイの話 (subtech.g.hatena.ne.jp)
- SoftBankガラケーの致命的な脆弱性がようやく解消 (takagi-hiromitsu.jp)
- ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る (blog.tokumaru.org)
- secure.softbank.ne.jp ヤバイの話+ (subtech.g.hatena.ne.jp)
先月まで、ソフトバンクのケータイサイトで https://example.com/ へのリンクを辿ろうとすると、以下のような動作になっていました。
- ソフトバンクのケータイでサイトにアクセスすると、ゲートウェイにより、HTML内の https://example.com/ へのリンクが全て https://secure.softbank.ne.jp/example.com/ に書き換えられる。
- リンクを辿ると、 https://secure.softbank.ne.jp/example.com/ にアクセスする。
- secure.softbank.ne.jpはプロキシとして動作し、https://example.com/ の内容を取ってくる。このとき、通常のゲートウェイの変換処理が行われており、携帯ID (X-JPhone-UIDなど) も付加されている。
普通にSSL/TLSを利用すると、サイト側にX-JPhone-UIDが送られない、絵文字が変換されないといった問題があります。そこで、ソフトバンクではSSL/TLS利用時にsecure.softbank.ne.jpを介するようにして、それらの問題を解決していたものと思われます。
ところで、昔のケータイではJavaScriptやiframeが使えず、クロスドメインで内容を取得する方法は存在しないと考えられていました。しかし、WASForum2010での徳丸さんの発表にもあるように、近年の端末はひっそりとJavaScriptやiframeに対応していたのです。
通常、https://bakera.jp/ に悪意あるスクリプトを置いても、https://example.com/ の内容を読み取ることはできません。しかし https://secure.softbank.ne.jp/bakera.jp/ にアクセスさせれば、iframeやXMLHttpRequestで https://secure.softbank.ne.jp/example.com/ の内容を取得することができます。しかも携帯IDはきちんと送出されますから、携帯IDを認証に使用している場合、ログイン後の内容にアクセスされてしまいます。
そんな問題点を私が把握したのは、2010年の初頭の頃です。この頃弊社では、本格的なケータイ公式サイト構築の仕事をしていました。過去にもケータイサイトを作った実績はあるのですが、静的コンテンツだったり、HTML納品だったりすることが多く、認証を伴う公式サイトのバックエンドまで開発したのはこの時が初めてでした。
認証まわりを実装したのは私ではなかったのですが、担当者があっさり問題に気付き、実証することに。実際に https://b-architects.com/ ドメイン上に検証用のコンテンツを置き、見えてはならないものが見えてしまうことを確認しました。また、この問題とは別に端末の脆弱性も発見されていて、微妙に関連する話でもあったため、一緒にIPAに届け出るようにお願いしました。
そのとき社内で話していたのは、「どうして問題になっていないのだろう」ということです。この仕組みに問題があることは明らかですし、公式サイトの認証まわりを実装すれば高い確率で気付くはずです。実はけっこう気付いている人がいて、しかしNDA (秘密保持契約) の壁で黙っているのではないか、などと想像していました。
そうしてしばらく経った頃、WASForum2010の直前だったと思いますが、高木さんからTwitterのDMでご連絡をいただきました。高木さんが既に書かれている、以下のくだりですね。
迷っている間に、何人かの脆弱性発見に慣れた方々に、「こんな脆弱性があるのですが、どうすべきですかね」と話しかけてみたところ、「その件は先日届け出た」という情報を得た。なるほど、既に先に気づいて届け出た人がいると。ならばということで、私としては届出をしないで、独自の活動をすることにした。根本的な解決は、端末の修正ではなく、この方式の廃止だと考えたからである。
実はWSAForumで徳丸さんがこの問題が公表されるのだとばかり思っていたのですが、公表されたのは別件でした。この時点で徳丸さんも既に問題をご存じだったのですが、公表するタイミングではないと判断されたとのことでした。
その後の流れは高木さんも書かれている通りで、Twitter上でのCTOとのやりとり (togetter.com)が実現し、廃止が実現することになりました。時間はかかりましたし、全てが解決できたわけでもありませんが、それでも大きく前進したことは間違いないと思います。ソフトバンクの方も大変だったことでしょう。ソフトバンクの方、IPAの方、他、本件にご尽力くださった全ての方に感謝いたします。
- 「secure.softbank.ne.jp廃止の舞台裏」にコメントを書く
関連する話題: セキュリティ / モバイル / secure.softbank.ne.jp
- 前(古い): 2011年7月1日(Friday)のえび日記
- 次(新しい): 2011年7月3日(Sunday)のえび日記