水無月ばけらのえび日記

脅威の"STRIDE"

• Spoofing (なりすまし)
• Tampering (改竄)
• Repudiation (否認)
• Information disclosure (情報漏洩)
• DoS (サービス拒否)
• Elevation of priviladge (権限の昇格)

脅威モデルのサンプル

シンプルな1ページのみのメールフォームの例。

• 他人のメールアドレスを入れる …… Spoofing
• 他人がそのメールアドレスを入れてデータを上書きできる? …… Tampering
• Repudiation のリスクは無し
• Information disclosure もリスクゼロ
• DoS……

エコシステム

• エコシステム = 生態系の意味、特定の業界の収益構造を指したりもする
• 他のWebサイトとの連携で生態系が成り立つ、Googleなど

エコシステムが成り立つために

• コンテンツ、サービスの提供
• マッシュアップ、APIの提供

• ユーザーの特定をしたい
• ユーザー固有のコンテンツと連携したい
• twitter連携など、多くは認証後に認可まで行う

認証と認可

• 認証 = authN(authentication) / 本人確認
• 認可 = AuthZ(authorization) / リソースへのアクセス権の付与

どうやって他サイトのリソースのアクセス権を得るか

認証情報を預ける? UserID/Passを預ける → 認証、とするのは簡単だが……。

• 連携サイトに平文でIDとパスワードを送付する必要があるため、預けたサイトでは平文で (少なくとも復号可能な形で) 保存される
• 他のサイト、他の管理者によって管理される。不正アクセスに使われる可能性も

Basic認証によるAPI連携

• ID、バスワードが平文で送られる (Base64エンコードされているが簡単に読める。たとえば JavaScript の window.atobメソッド)
• ログアウトがない (一度でもブラウザからAPIを叩いてBasic認証のパスワードを入れてしまうと、容易に攻撃される)

モバイルOAuth

• アクセストークンの有効期限はデフォルト無し
• ガラケーだと「拒否」「許可」が「送信」「送信」に化ける

OAuthを使っていないサイト

• USTREAM
• twiike (Nike + twitter)
• つぶやきタカ

OAuth1.0の脆弱性

• リクエストトークンを使ったセッション固定攻撃……攻撃者がリクエストを出し、承認確認URLを利用者に踏ませる
• アクセス権の委譲を許可したユーザとアクセストークンを取得させるユーザーが同一かどうか確認していない
• 委譲同意確認後に乗っ取り

修正:OAuth1.0a……コールバックのURLをユーザーのブラウザを介さない経路に変更

OAuthなんて誰も知らない?

• 異なるドメイン・サービスにIDやパスワードを入れてはならない (入れさせてはならない)
• しかし、OAuthの画面が出ても、何を言っているのか分からない (UIやメッセージが分かりにくい)

欠陥の例

• サイボウズOffice (JVN#87730223 (jvn.jp))
• OpenPNE JVN#06874657 (jvn.jp))
• はてな、日経就職ナビ、などなど……

これらは、そもそもIPアドレスの制限をしていなかった (DNS Rebinding以前の問題)

OpenPNE2.14の事例

• 携帯キャリアのIPアドレスをプログラム中にハードコード
• 対応キャリア: docomo、au、softbankに加えて EMnet (EMobile)
• IPアドレス制限の処理、ログイン判定に使用するとID抽出の処理は、別々のモジュールで行われていた

攻撃シナリオ …… EMnetで接続し、他社のケータイIDを送信すると突破される。

誰の脆弱性なのか?

この問題は誰の責任なのか?

従って、Webサイト側の脆弱性ということになる (いわざるをえない)。

無責任な解説の蔓延

• ケータイIDによる認証の方法には公式な解説がない
• 一方、素人のずさんな解説が蔓延している
• 典型的な解説 …… アクセス制限は .htaccess で処理、ただし ENnet や Googlebot などは通す。アプリでID取得

EMnetだけの問題ではない

Softbankにも同様の問題

• 2009年夏にblog界隈でささやかれていた話
• 海外製端末向けAPNにダイヤルアップし、Proxyサーバを経由するとSoftbank携帯のIPアドレスになる
• X-JPhone-UIDを削除した上で本物を付与する (なりすまし不可)
• それ以外のヘッダには関与しない
• User-Agentの中の端末シリアル番号は書き換えないため、なりすまし可能 (そもそも書き換え困難。端末シリアル番号を含む User-Agent の書式は仕様はBNFで定義されているでもなく、いかにも日本人的な「何となく」のものでしかない)
• ただし、User-Agentが所定のもの以外ならアクセスが拒否される。Softbank以外のUAを拒否しているものと思われる

User-Agentの判定を突破

• 後ろにつけた文字列は無視される。例: User-Agent: Softbank...KDDI-
• アプリのロジックによっては突破され得る
• CGI RESCUEの「会員制携帯サイト簡単ログイン」がこの手法で突破可能だった

誰の責任?

• これはWebアプリ側の脆弱性なのか?
• キャリアは公式情報を公表していない
• 何をどこまですればよいのか不明。X-JPHONE_UIDが通るとか……きりがない。

IPアドレス別のキャリア判別なら安全?

• キャリアから正式に公表されているわけではない
• 公式サイト向けにはある?「当該ケータイIDを使用する際には当IPアドレスから……」という記述があるのではないかと想像
• キャリアは他キャリアのことは考慮してくれない。3キャリア連携の都合などは知ったことではない

SSL接続で出たID

• end-to-endのSSL接続で送信された任意のIDはそのまま届く (Softbank, EMnet)
• https: の機能を提供していないつもりでも、稼働している場合があるので注意

不確実なIPアドレス制限

キャリアが出している「IPアドレス帯域」の情報

• https:での取得が出来ない
• 機械的に処理できないカタチでの提供
• 保証しない(あくまでも目安)という宣言

• 誰も信頼あるシステムを構築しようとしない
• Google日本法人もblogで公表する体たらく
• サイボウズOfficeはさじを投げた (「お客様で制限してください」と注意喚起する以上のことはできない)

SSL必須前提では使えない

割り込んだ攻撃者は任意のIDを送信できる

端末付与型のリスク

• EZ番号は end-to-end で送られる (ゲートウェイが付加しているのではなく、端末が送信している)
• 端末が jail break されたらなりすましのおそれ

無責任なキャリア

• 公式情報を公表していない
• しかもdocomoは「iモードID」の使用を推奨している

Cookieで実装せよ

• 無期限のCookieを使えばよい
• ケータイのCookie普及率……クッキー食えないのはdocomoだけ (takagi-hiromitsu.jp)

そもそもUIが変

• かんたんログインボタン、ログアウト機能……?
• utn送信時の「はい/いいえ」に配慮?

「かんたんログイン」言うなキャンペーン

• 「かんたんログイン」という言葉を発注者の目に触れないようにする
• 駄目な理由を長く説明する……orz
• 「でもやっぱかんたんログインだよねー」「あれ作った人マジ神」 (twitter.com)

パスワードを登録しないサイト

• ワンタイム課金なら問題ない
• SNSなどはキャリア乗り換えの問題があるのでパスワードが必要なはず。ケータイID認証で徹底したとしても、どこかにパスワード入力画面がある (一番最初に登録していることが多い)
• ケータイだから弱いパスワード使う、というのは利用者の責任

docomoをどうする?

• 基本的にはCookieで実装
• iモード1.0の場合のみiモードIDで実装

ヤマダ電機

• 一人1回を実現するため?
• 国民ID的な利用
• 国民ケータイ総背番号制
• 国民IDが出来てもポイントカードでの利用は認められないだろう
• 使用が広がると戻れなくなる

一般インターネットへの波及

• 青少年保護を理由に進むケータイ独自世界の展開
• こんな発言も……「ISPはウェブ側に認証情報を提供してほしい。 (twitter.com)」

ケータイIDがなくなると困る?

IPアドレスをころころ変える荒らし

• ISPは対応してくれる
• ケータイキャリアは通信の秘密を盾に拒否?

何を取るかの問題?

• プライバシーを取るか、安全・安心を取るか……という二者択一なのか?
• 両立できないのか?
• 法務系の人々……IDやCookieのことが分かっていない

docomo ID

• Open ID なのに、iモードIDが取れる
• ボイコットしましょう
• 「iモードIDは取得していません」バナー (takagi-hiromitsu.jp)

各サービスのかんたんログイン機能

• はてな …… 「かんたんログイン」あり
• ライブドア …… 「クイックログイン」あり
• mixi …… 「かんたんログイン」あり
• ブラウザ三国志 …… なんと、「かんたんログイン」のみ。むしろ潔い?
• Twitter …… かんたんログインあり。このサービスは、端末が3台あれば3台ともかんたんログインできるように頑張っている。
• Remember The Milk …… iモードのみ、「かんたんログイン」が利用可能

かんたんログインが成り立つための条件

• 端末固有ID …… 秘密情報ではない。「書き換えができない」という前提
• ふつうにHTTPヘッダに入っている
• 携帯電話を使っている限りは書き換えできない?

ケータイJSで端末固有IDを書き換える

• XMLHttpRequestが使用できる
• setRequestHeaderが使用できる
• setRequestHeaderでリクエストヘッダを書き換ることができる

……10月の時点で、setRequestHeaderが機能しなくなった (setRequestHeaderメソッドはあるが、呼んでも何もしない)。これにより、能動的攻撃はできなくなった。

mpw.jpによる情報

• ケータイサイトのHTMLソースの閲覧方法、というテクニックが公表される (iモード専用サイトのhtmlソースの閲覧方法 - mpw.jp管理人のBlog (mpw.jp))
• →これはDNS Rebindingではないか?
• HTMLソースを読めること自体は問題ないが……。

徳丸浩の熱い日

• 事業者側での対応は困難。一方、サイト側での対策は可能。
• そのため、公表することにした。

DNS Pinning

• IEは強固だが、他のブラウザは割とゆるい。キャリアのせいというわけでもなさそう
• ゲートウェイで名前解決するので、ブラウザ側では対策できない
• ゲートウェイ側で一定時間Pinningする場合、ゲートウェイが共有であることが問題になる。攻撃者がPinning開始時間を設定できる (例: Pinningが1時間なら、攻撃者は攻撃開始の58分前に1度アクセスしておけば良い)

ゲートウェイIPの変遷

• リモートホストのIPアドレスは頻繁に変わる
• docomoは1分間はDNSキャッシュを保持
• ゲートウェイの群単位でキャッシュを共有しているらしい?

setRequestHeaderはどのヘッダを改変して良いか?

• Host, Referer は書き換えできては駄目なはず……。
• ソフトバンク端末では、なんと Host: が書き換えできてしまう!

徳丸浩の熱い日2

• 932SHを購入 (7万円) して確認。
• 問題を報告。ソフトバンクモバイルの側の担当者がアサイン
• 12月某日、ソフトバンクにて打ち合わせ

Host: の改変防止が根本対策だが……。

3月末某日

• DNSの挙動に変化が……
• DNSキャッシュを5分間保持するようになった
• ただしゲートウェイ群が切り替わると駄目

しびれを切らして……

• デフォルトAjax許可の端末はないのか?
• マニュアルを片っ端からダウンロードして通読
• 検証センターで検証!!

• NET FRONTのACCESS社は何をしていたのか!?
• IEも昔は脆弱だったが、対応してきた歴史がある。
• 携帯端末でのブラウザシェア8割に見合う責任を果たしていただきたい

幸い、Ajaxデフォルト有効機種はシェアが低いため、影響は大きくないと判断し、このたび公開を判断した。

Digital Identity

Subject / Entityに対応する、属性の集合

• 形質 traits …… 変わらないもの。生年月日、身長、体重、名前など
• 属性 attributes …… 住所 電話番号 {メールアドレス ユーザー名} …… 識別子)
• 関係性 relationships 交友関係、購買履歴、etc.

• 例: Wii でいうところの mii。mii に体重なども結びつけて記録することができる
• ただし、mii は Wii の中でしか生きられない
• 標準化・Open化すると Open mii → Open ID

認証プロセス

• Digital Identityの制御者として「正当性の確認」「属性引き渡し」を要求
• Digital Identityの制御者としての正当性の確認
• 正当性と属性確認書 (Assertion) の発行とお届け

OpenIDの基本モデル

• IDプロバイダとサービス提供者

認証基盤連携フォーラム

「通信プラットフォームのあり方について」で規定

• 分散&連携
• ユーザー中心
• 高可用
• 信頼&評判

目的は、ユーザセントリックIDの実現

属性連携はユーザ利便性を高める

属性情報を全て入れてもらう場合と、属性連携を使って一部の属性情報入力を省いた場合とでユーザテストを実施。

• 時間短縮削減、エラー発生率低下の効果
• 1分33秒 vs 19秒
• 19.6% vs 7.1%
• テスト後のアンケートでは、属性連携を「非常に利用したい」53%、「利用したい」41%、「利用したくない」3%、「全く利用したくない」0%、「わからない」3% となり、予想以上の評価
• ただし、情報提供先が信頼できるのかどうかを確認したいという声も見られた

OpenID for mobile (Artifact Binding)

• RPはリクエストファイル作成、そのURLをOPに送信
• OPはファィルを取得、Artifactを送信
• RPからArtifactをOPに送信、Assertion取得

• リクエストファィルはJSON
• AeerstionもJSON
• Artifactは302リダイレクト
• OP https Endpoint に対して GET で取得 (ログ残る)

実装サンプルが https://openid4.us (openid4.us) で見られる。

• ブラウザ経由のGETを小さくできる
• ほとんどサーバ間通信
• Assertion Disclosureの防止 (ブラウザを経由しないため)
• OPの完全ステートレス化も可能
• NISTのLoA4まで対応可能
• Signed Assertion Requestを使えば繰り返し属性の取得が可能 (ユーザの許可があれば)
• OAuth2.0のtoken受け渡しも可能 (OAuth2.0--)
• 実装が簡単
• OPがサポートすればSAMLやWSSも返せる

スケジュール……5末仕様凍結、12月最終仕様?

連携の例

• smart.fm × Yahoo!
  • Yahoo!側のプロフィールをsmart.fm側で出せる
  • 渡したくないものは渡さないように選択できたりする
• Oisix × Yahoo!
  • 決済・ポイント連携

どのように連携するか

• ID連携のみ (OAuth)
• + 属性連携 (Attribute API)
• + 決済連携 (Wallet API)
• + ポイント連携 (Point API)

どの属性情報をどの外部サービスに提供するか

• 本人が利用する情報 : 配送先、氏名、電話番号など。ショッピングサイト、銀行などに提供
• 他のユーザーに見せる情報 : 表示名、画像など。SNS、ゲーム、コミュニケーション用サイトなどに提供
• SNSなどは両方を使ったりする

API公開情報レベル区分

• LV1 提供可能: 購入・決済に関わらない情報
• LV2 特定企業に審査後に提供可能: 購入・決済に関わる情報
• LV3 提供不能: 個人を識別する情報

内外比率

• 内部の利用 …… 93.8%
• 外部からの利用 …… 6.2%
• 外部利用のうち、OAuthとOpenIDは2%。そのほか、古いチケット型の認証の仕組みが残っていて利用されている

パスワード再確認

Yahoo!では、ログイン状態でも再度パスワードを訊くケースがある。

重要情報はログイン直後でないとアクセスできないようになっている。個人情報を閲覧する場合、決済シーンなど。

• パスワード再確認の比率 …… 15.72%

さまざまなニーズ

• さまざまなサービス …… Yahoo! のサービス一覧 (services.yahoo.co.jp)、数えるのに力尽きたがたぶん150くらい

  ※私がカウントしたところでは、2010-05-25現在で157あるようです

• さまざまな端末 …… PC、ケータイ、スマートフォン、テレビ、カーナビ
• さまざまなユーザーエージェント …… Webアプリ、クライアントアプリ、ガジェット

• Yahoo!のサービスと、外部のサービス
• コンシューマと、ビジネスユーザ
• オトナと、子ども。子ども向けのIDが欲しいというニーズがあり、「Yahoo!きっず」というサービスがある

さまざまな認証

• Web
• 内部クライアントアプリケーション向け (Token Login)
• 外部クライアントアプリケーション向け (RawAuth)
• 端末ID認証 (モバイルログイン)

  ※ここで高木さんが来場されているかどうか確認 :-)

• テレビ向け
• Webブラウザ向け
• OpenID
• OAuth
• SSO
• AEAuth (教育機関向け)
• ビジネスID
• きっずID (「IDを入力してね。」のようにやさしい文言。Yahoo!きっずでしかログイン状態にならない)

どれがベストか?

• パスワード再確認画面は何で必要なの? どういうリスクがあるの?
• 多様なニーズに応えながらも、守るべきは守る

ログイン履歴

• 直近60件のログインの履歴を表示。成功も失敗も記録。
• 表示する情報は……どのサービスでログインしたか、ログイン時刻、ログインなのか再確認なのか、成功or失敗、IPアドレス、端末がPCかモバイルか
• 悪いことをしようという人にもこのサービスの存在を知ってもらって、抑止につなげたい

ログインシール

• ログインフォームに、ユーザーが設定したシールを表示する
• フィッシング防止のため

ログインアラート

• ログインするたびにメールが届く
• メールにはURLが書かれており、そのURLにアクセスするとアカウントをロックすることが可能。ログインに心当たりがないときにはロックを。
• ただし強制ログアウトにはならず、現在のセッションは有効。次回ログインからブロックされる。

ログイン3兄弟の課題

• 利用率がイマイチ……。
• 場所が分かりにくい。たとえば、ログインアラートは「Yahoo!トップの右上」→「ガイドページの左下」→「ログインアラート説明ページ」と辿らないと出てこない
• ログイン履歴の利用 = 136万PV/月
• 他の2機能の利用数は非公開 (と言いつつ、利用数のグラフは公開)。シールは利用率が低く、アラートはさらに低い

• 選択式ではなかなか利用者数が増えない
• しかし、全ユーザーに利用を強制するわけにも行かない
• 利便性を保ちつつ全ユーザに適用できる対策はないか?

リスクベース認証

• "Login Risk Manager" という仕組み
• あらかじめユーザーの利用環境、アクティビティの情報を持っておく
• 普段の利用と著しく異なる時間、環境、国からのアクセスは怪しい
• ログインイベントの不審度(リスクレベル)を判定し、レベルによって通知or追加認証orブロックを実施する
• この仕組みであれば、非常時以外は普段と何も変わらない利用ができる

ユーザとWebブラウザ

• うまいユーザ vs 下手なユーザ、地味なブラウザ vs 派手なブラウザという軸
• 地味なブラウザの例: w3m
• 下手なユーザ + 地味なブラウザ = ダサイ
• 下手なユーザ + 派手なブラウザ = 危険

Webブラウザの進化

• 1993年 CERN = 自転車
• 1994年 Netscape Navigator = スーパーカブ
• 2010年 (あえて具体名は出さない) 爆速・多機能 = デコトラ

デコトラの運転は危険がいっぱい。