水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2010年のえび日記 > 2010年5月 > 2010年5月22日(土曜日)

2010年5月22日(土曜日)

WASForum Conference 2010: クロージングディスカッション 脆弱性対策至上主義からの脱却

公開: 2010年6月4日0時10分頃

WASForum Conference 2010、Live IDの話の後は最後の最後、クロージングディスカッション。壇上には三井物産セキュアディレクションの国分裕さん、テクマトリックス株式会社の酒井喜彦さん、そして司会は株式会社テックスタイルの岡田良太郎さん。席からはスピーカーの門林さん、松岡さん、高木さんが乱入する形となりました。

以下は、話された内容の一部を断片的にメモしたものです。敬称は略させていただいています。正確性はいまいちな上に、途中ところどころ飛んでいますのでご注意ください。

国分

昔からすると変わってきている。昔は自前で全部やっていたが、最近は外のサービスと連携したり、複数サイトにまたがったり、新たな考え方が今後必要になってくる。

酒井

企業サイトのマッシュアップは進んでいない?

これから対策しなければならなくなる話。伝えていかなければならない。

岡田

今日の話は脆弱性検査で指摘する範囲に含まれる?

国分

指摘している。設計に起因する問題も指摘している。かんたんログインも。

岡田

反応は?

国分

なかなか厳しい。「分かるんだけどユーザからのニーズがあるし……」と言われることが多い。やめることを検討しているお客様もいるが、さまざま。

そもそも、脆弱性検査を頼んでくるところは意識が高い。Cookie対応など、どんどん言っていってもらいたい。

門林

クライアント証明書は使われている?

属性を入れたりいろいろなことができるはずだが、そういう使い方を見たことは?

国分

使っているサイトはあるがIDのかわりにとどまる。属性まで使っているところは見たことがない。

門林

暗号学者からするとCookieも論外。暗号化されていないから。

ソフトウェアのへたくそなつくりを指摘→直れば立派、というのはそろそろ……。

国分

設計思想によって脆弱性がある、というのは被害につながるので指摘はしている。

岡田

2~3年前、雨後の竹の子のように不良検査会社が出てきた。その後どうか。

国分

ツールによる検査だけで良いサイトもある。そうではなくてしっかり見てほしい、というサイトもある。顧客も二極化している。

岡田

ものを作る立場としてどうか?

酒井

うちではAppScanがメイン。構築の方も見ているが「やっていただきたい」。今日聞いた話をいかにしてお客様に伝えるか。

ぜひ資料配付をお願いしたい。来てないけど資料で分かる、ということはあんまりない。バズワードが面白かったね、で終わらせたくない。

高木

Cookieが駄目と言われたが、SSL/TLSも一緒。CookieのポイントはJSから触れるという点だけで、やり方としては普通。

門林

ケータイは物理的なセキュリティに立脚している。ケータイを持った人を本人扱いにしてしまう。認証に重要な要素をスルーしている。だから5歳の子どもが父のケータイでゲームコンテンツを購入してしまう。誰がどう責任を取るのか。ビジネスとして考えなければならない。そこも含めてのエコシステム。

高木

ソフトバンクでは、課金の時に暗証番号を入れていたのが省略されるようになった。初回アクセスで包括認証というのは無茶ではないか。総務省研究会で問題にすべき。auも入力を省略できるようになった。リアルの契約と電子契約は違う。暗証番号によって「買う」と意思表示していたはず。これでは架空請求の餌食になる、なんとしても元に戻すべき。

門林

総務省の研究会はポリシー論だけで結論を出して終わっている。国がやれば良いじゃないか、というのも問題。インターネットにも様々な問題がある。spam、ボットネットなど。ケータイでも時間差で同じ事は起きる。かんたんログイン、透明でない仕様……情報が出てこないので専門家はどうしようもない。商用サイトも含めて検査をされている会社こそ出せる統計情報があるのでは?

ここでもやはりかんたんログインの話が。

クロージングと言いつつあんまりまとめになっていませんでしたが、それはそういうものということで。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: SDL脅威分析の方法とWindows Live IDにおけるアプローチ

公開: 2010年6月3日0時45分頃

WASForum Conference 2010。Web2.0(ツーオー)の次は最後のセッション、「SDL脅威分析の方法とWindows Live IDにおけるアプローチ」。スピーカーはMicrosoftのJiong Luさん、お話は英語で通訳付きでした。

脅威モデル

脅威の"STRIDE"
  • Spoofing (なりすまし)
  • Tampering (改竄)
  • Repudiation (否認)
  • Information disclosure (情報漏洩)
  • DoS (サービス拒否)
  • Elevation of priviladge (権限の昇格)
脅威モデルのサンプル

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

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

Live ID

……

……ありのまま今起こったことを話すと、手元のメモがここでぷっつりと途切れているわけですよ。この後はWindows Live IDの話が続いていたはずなのですが、メモが跡形もなく。

印象に残ったのは通訳の方で、この方がまたマニアックな脆弱性関連用語をさらっと訳したりしておられたわけですよ。事前の読み合わせなどもされているのでしょうが、それにしても凄いと思いました。

セッションはこれで終わりですが、最後に締めのディスカッションがあります……「クロージングディスカッション 脆弱性対策至上主義からの脱却」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: "Web2.0" におけるセキュリティ ~ セキュアなWeb2.0環境の構築とは

公開: 2010年6月1日1時30分頃

WASForum Conference 2010、OAuthの話の次は、日本IBMの吉濱佐知子さんによる「"Web2.0" におけるセキュリティ ~ セキュアなWeb2.0環境の構築とは」というお話。吉濱さんはWASForum初の女性スピーカーなのだそうです。

※全体的に話の流れが非常に速く、ほとんどメモが取れませんでした。以下、メモは断片的です。

Web2.0におけるセキュリティ

  • Webアプリケーションの脆弱性は依然として多い
  • Web2.0(ツーオー)の特徴……Ajaxによる非同期アクセス、MashUp
  • Same-Origin Policyを破るコンテンツ …… サイト運営者が用意したものではないUGC (user-generated content、ユーザが投稿したさまざまなコンテンツ) や JSONP による外部ドメインコンテンツの取り込み

脅威の発生経路

  • T1: 通信チャネルに対する脅威 …… 通信傍受、改竄。Ajax通信の部分だけHTTPSになっていない、といった破れ
  • T2: HTTPクライアントからサーバに対する脅威 …… インジェクション攻撃
  • T3: 攻撃者サーバからユーザへの脅威 …… フィッシング、Typosquatting(有名ドメイン名の打ち間違いを狙う)、Pharming(?)
  • T4: クライアント側のインジェクション …… 悪意あるマッシュアップ。たとえば、広告スペースの又貸しによって、有名サイトに悪意ある広告が出現するなど

※他、いくつかあった模様ですがメモしきれず。

Googleの事例

  • Google docsのXSS
  • 他のサービス全てに対してセッションハイジャックのおそれ

XSSの難読化

  • img要素のjavascript:スキーム
  • JavaScriptの途中に改行やNUL文字を挿入
  • %xx形式
  • <meta url=data:text/html;base64>
  • 数値文字参照、 &#x0000000000001; のような冗長な書き方
  • charset=US-ASCIIのとき、8bit目を無視するブラウザが存在
  • charsetに未知の値 (たとえばcp932) が指定されたとき
  • DOM-based XSS
  • Cross-Site Image Overlay …… コンテンツ内のリンク付き画像のpositionを調整して正規のロゴ画像にかぶせたり
  • Cross-Site Flashing ……ActionScriptの getURL() に外部パラメータをまんまインジェクションできるケース
  • jarプロトコルハンドラ …… jar:https://example.com/a.jar!/b.html のようにするとjar内のコンテンツが参照できる。jarはZIPなので、ZIPが置けるサービスに使用すると……。
  • GIFAR …… 画像として妥当だが、jarとしてもアクセスできるファイル
  • javascriptハイジャッキング …… メソッドを上書きして外部JSを呼んだり

T6: ユーザのPCに対する脅威

  • ローカルネットワークに対する攻撃
  • JavaScriptによるポートスキャン
  • Cross-Site Printing
  • CSRFによるルータ設定変更

基本的には手法などの紹介なのですが、展開が非常に早くてメモが全く追いつきませんでした。前のセッションが長引いていたので仕方ないと思いますが、もう少しゆっくり聞きたかったところですね。

紹介されていたものの中では、jarを使った攻撃手法が印象的でした。このパターンはあまり見たことがないので、少し調べてみたいですね。他の手法はおおむね既知だったり……あとは、「クロスサイト」という名前がやたら多い割に、内容がクロスサイトとは言いにくいものが多かったような気がします。海外ではクロスサイトという名前が好まれているのでしょうか?

しかし、やはり最も印象に残ったのは "Web2.0(ツーオー)" ですね。会場でも多くの人が感銘を受けていたようで、Twitterでもしばらく「ツーオー」の話が流れていました。

あとちょっとだけ続きます……SDL脅威分析の方法とWindows Live IDにおけるアプローチ

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: OAuthとWEBサイト運営のエコシステムに潜む罠

公開: 2010年6月1日0時30分頃

WASForum Conference 2010、高木さんのセッションが延びてしまって開始予定時間を大きく過ぎたところで、トライコーダ上野宣さんによる「OAuthとWEBサイト運営のエコシステムに潜む罠」。

自己紹介

エコシステムの中核は認証と認可

エコシステム
  • エコシステム = 生態系の意味、特定の業界の収益構造を指したりもする
  • 他のWebサイトとの連携で生態系が成り立つ、Googleなど
エコシステムが成り立つために
  • コンテンツ、サービスの提供
  • マッシュアップ、APIの提供
  • ユーザーの特定をしたい
  • ユーザー固有のコンテンツと連携したい
  • twitter連携など、多くは認証後に認可まで行う
認証と認可
  • 認証 = authN(authentication) / 本人確認
  • 認可 = AuthZ(authorization) / リソースへのアクセス権の付与
どうやって他サイトのリソースのアクセス権を得るか

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

  • 連携サイトに平文でIDとパスワードを送付する必要があるため、預けたサイトでは平文で (少なくとも復号可能な形で) 保存される
  • 他のサイト、他の管理者によって管理される。不正アクセスに使われる可能性も
Basic認証によるAPI連携
  • ID、バスワードが平文で送られる (Base64エンコードされているが簡単に読める。たとえば JavaScript の window.atobメソッド)
  • ログアウトがない (一度でもブラウザからAPIを叩いてBasic認証のパスワードを入れてしまうと、容易に攻撃される)

OAuth

モバイルOAuth
  • アクセストークンの有効期限はデフォルト無し
  • ガラケーだと「拒否」「許可」が「送信」「送信」に化ける
OAuthを使っていないサイト
  • USTREAM
  • twiike (Nike + twitter)
  • つぶやきタカ
OAuth1.0の脆弱性
  • リクエストトークンを使ったセッション固定攻撃……攻撃者がリクエストを出し、承認確認URLを利用者に踏ませる
  • アクセス権の委譲を許可したユーザとアクセストークンを取得させるユーザーが同一かどうか確認していない
  • 委譲同意確認後に乗っ取り

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

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

とまあこんな感じでOAuthの話でしたが、全体的には入門的な内容で分かりやすかったと思います。もっと先にこのセッションを持ってきても良かったのではないかと思いました。

部分的に少し説明不足かな、と感じるところもありましたが (たとえばBasic認証の危険性のあたり)、これはセッションハイジャックの影響も大きいでしょう。

続きます……"Web2.0" におけるセキュリティ ~ セキュアなWeb2.0環境の構築とは

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: どうするケータイ認証

公開: 2010年5月31日0時45分頃

WASForum Conference 2010、ソフトバンクの脆弱性の話に続き、産総研の高木浩光さんによる「どうするケータイ認証」。

ケータイWebの世界

従来、WASForumではあまり扱ってこなかった分野。その理由は……

  • 独自方式、仕様が明確でない
  • NDAの壁 (特に公式サイト)
  • 契約で縛った独自世界なら、キャリアが責任を持つべき。部外者は何かを言うべき立場にない

しかし、昨今では……

  • ケータイ独自方式が一般サイトにまで侵出
  • 2008.3 iモードIDがスタート
  • スマートフォン対応の活発化

ログイン認証の欠陥

  • ID (契約者固有ID) による認証を JavaScript + DNS Rebinding で突破される問題
  • 海外ではあまり問題にならない
  • DNS Rebindingという手法は古くから知られていたのだが、そんな認証は日本でしか使われていないため、海外では問題になりようがない
    • iモードIDを使った認証がDNS Rebindingで突破される件、2010年1月4日に読売新聞の記事となる
    • その際のdocomo広報の言い分: JSの危険性は皆さんご存じのとおりであり……?

※正確には、読売に載ったコメントは「ジャバスクリプトの安全な利用はサイトを作る側にとって基本的知識であり、具体的に説明はしていない」というものだったようです。この話では攻撃者がJavaScriptを使うことを想定しているので、安全な利用も何もないのですけどね……。

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

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

ケータイIDによるログイン認証

ケータイID (契約者固有ID) の利用によるログイン認証、IPアドレスを制限していればOK?

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

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

誰の脆弱性なのか?

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

EMnetのProxyの動作
  • EMnetのProxyはX-EM-UIDを挿入
  • 既に (偽物の) X-EM-UIDがついている場合は、それを消して上書きする
  • 他のヘッダについては関与しない。他社のIDを示すヘッダがあってもスルーしてしまう
他社のIDを削除しないから悪い?

EMnetのProxyが他社のIDを削除するべき?

  • どうやって削除するのか?
  • 他社が新たなIDを創設するたびに対応する?
  • X- で始まるフィールドを全て削除する?

いずれも現実的ではない。

従って、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で実装せよ
そもそもUIが変
  • かんたんログインボタン、ログアウト機能……?
  • utn送信時の「はい/いいえ」に配慮?
「かんたんログイン」言うなキャンペーン
パスワードを登録しないサイト
  • ワンタイム課金なら問題ない
  • SNSなどはキャリア乗り換えの問題があるのでパスワードが必要なはず。ケータイID認証で徹底したとしても、どこかにパスワード入力画面がある (一番最初に登録していることが多い)
  • ケータイだから弱いパスワード使う、というのは利用者の責任
docomoをどうする?
  • 基本的にはCookieで実装
  • iモード1.0の場合のみiモードIDで実装
ヤマダ電機
  • 一人1回を実現するため?
  • 国民ID的な利用
  • 国民ケータイ総背番号制
  • 国民IDが出来てもポイントカードでの利用は認められないだろう
  • 使用が広がると戻れなくなる
一般インターネットへの波及
ケータイIDがなくなると困る?

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

  • ISPは対応してくれる
  • ケータイキャリアは通信の秘密を盾に拒否?
何を取るかの問題?
  • プライバシーを取るか、安全・安心を取るか……という二者択一なのか?
  • 両立できないのか?
  • 法務系の人々……IDやCookieのことが分かっていない
docomo ID

基本的には高木さんの日記 (takagi-hiromitsu.jp)で既出の論点のまとめ、という感じでしょうか。徳丸さんのセッションに引き続き、キャリアが情報を公開していないことの是非、キャリア側の責任のあり方について問われる内容になりました。

しかしなによりこのセッションで驚愕したのは、おおっぴらにセッションハイジャックが行われたこと。終了時間になっても「まだ重要な話がありますので、上野さんのお時間をいただいて……」と続行、後に続く上野さんのセッションを乗っ取ってしまいました。

そんな不幸な上野さんのセッションに続きます……「OAuthとWEBサイト運営のエコシステムに潜む罠」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: ケータイ2.0が開けてしまったパンドラの箱

公開: 2010年5月30日16時40分頃

WASForum Conference 2010。OpenIDのお話の後は、昼休みを挟んで午後のセッションです。午後の一発目は、HASHコンサルティングの徳丸浩さんによる「ケータイ2.0が開けてしまったパンドラの箱」。実はこのセッション、事前に「未公表のネタ2件を発表する (twitter.com)」と宣言されていました。未公表の脆弱性が複数公開されるのではないか……と、期待と不安が高まります。

かんたんログインのお話

各サービスのかんたんログイン機能
  • はてな …… 「かんたんログイン」あり
  • ライブドア …… 「クイックログイン」あり
  • mixi …… 「かんたんログイン」あり
  • ブラウザ三国志 …… なんと、「かんたんログイン」のみ。むしろ潔い?
  • Twitter …… かんたんログインあり。このサービスは、端末が3台あれば3台ともかんたんログインできるように頑張っている。
  • Remember The Milk …… iモードのみ、「かんたんログイン」が利用可能
かんたんログインが成り立つための条件
  • 端末固有ID …… 秘密情報ではない。「書き換えができない」という前提
  • ふつうにHTTPヘッダに入っている
  • 携帯電話を使っている限りは書き換えできない?
  • ケータイ網が閉じたネットワークであること
  • ケータイ端末の機能が低く、HTTPヘッダを書き換える必要がないこと

iモードブラウザ2.0

  • 2009年5月19日、iモードブラウザ2.0の発表
  • JavaScript対応、Ajax対応、Cookie対応、Referer対応
ケータイJSで端末固有IDを書き換える
  • XMLHttpRequestが使用できる
  • setRequestHeaderが使用できる
  • setRequestHeaderでリクエストヘッダを書き換ることができる

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

mpw.jpによる情報
徳丸浩の熱い日
  • 事業者側での対応は困難。一方、サイト側での対策は可能。
  • そのため、公表することにした。
DNS Pinning
  • IEは強固だが、他のブラウザは割とゆるい。キャリアのせいというわけでもなさそう
  • ゲートウェイで名前解決するので、ブラウザ側では対策できない
  • ゲートウェイ側で一定時間Pinningする場合、ゲートウェイが共有であることが問題になる。攻撃者がPinning開始時間を設定できる (例: Pinningが1時間なら、攻撃者は攻撃開始の58分前に1度アクセスしておけば良い)
ゲートウェイIPの変遷
  • リモートホストのIPアドレスは頻繁に変わる
  • docomoは1分間はDNSキャッシュを保持
  • ゲートウェイの群単位でキャッシュを共有しているらしい?

ソフトバンク端末のJavaScript対応

  • 2004.12 ノキア JS対応
  • 2006.3 804SS JS対応 (ただしiframeには対応せず)
  • 2008.3 922SH Ajax対応

実は、2006年からパンドラの箱は開いていた!

setRequestHeaderはどのヘッダを改変して良いか?
  • Host, Referer は書き換えできては駄目なはず……。
  • ソフトバンク端末では、なんと Host: が書き換えできてしまう!
徳丸浩の熱い日2
  • 932SHを購入 (7万円) して確認。
  • 問題を報告。ソフトバンクモバイルの側の担当者がアサイン
  • 12月某日、ソフトバンクにて打ち合わせ

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

3月末某日
  • DNSの挙動に変化が……
  • DNSキャッシュを5分間保持するようになった
  • ただしゲートウェイ群が切り替わると駄目
しびれを切らして……
  • デフォルトAjax許可の端末はないのか?
  • マニュアルを片っ端からダウンロードして通読
  • 検証センターで検証!!
検証結果

検証センターで3時間かけて64機種を調査したところ、以下の4機種でAjaxがデフォルトONであり、しかもHost:書き換え可能であることが判明。

  • 940SC
  • 820N
  • 821N
  • 830CA

SH (シャープ端末) はデフォルトでAjaxが無効となっている。ユーザーが設定を変えた場合には影響を受ける。

NEC、CASIOの端末では Refererの改変も可能。

  • NECとCASIOは、いったんAjax有効の端末を出したものの、後継機種では何故かまた無効になった。
  • SHARPは一貫してAjaxがデフォルト無効であり、慎重な姿勢が見られる
  • メーカーごとに対応がバラバラであり、連携がない。他メーカーの教訓が生かされていない
  • NET FRONTのACCESS社は何をしていたのか!?
  • IEも昔は脆弱だったが、対応してきた歴史がある。
  • 携帯端末でのブラウザシェア8割に見合う責任を果たしていただきたい

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

対策は?

  • アプリ側の対策はない
  • ユーザ側にセキュリティ設定を促す
  • 運営者にやる気があれば……危険な機種のみかんたんログインを無効にする
  • ソフトバンク端末ではかんたんログインを無効に

能動的攻撃の可能性

  • SSLでエンドトゥエンド通信にすると、キャリアのゲートウェイでヘッダフィールドを書き換えられなくなる
  • "User-Agent" ではなく "User_Agent" というヘッダフィールドをつけることで、User-Agentを誤認識させることができる (CGIプログラムで環境変数 HTTP_USER_AGENT を参照している場合)
  • SSLではかんたんログインを受け付けないことが対策になる

まとめ

  • 機種に依存する要素が多い
  • そのため、全ての端末について検証しないと何とも言えない。が、一人でやるのは大変
  • オープンに議論できる場が必要なのではないか

というわけで、ソフトバンク端末の XMLHttpRequestで Host: が改竄されるという脆弱性が公表されました。

私もソフトバンク端末が JavsScript や XMLHttpRequest にひっそりと対応していることには気付いていて、ひっそりと問題視していたのですが、XMLHttpRequestはデフォルト無効になっているものと思っていました。デフォルト有効の機種があったとは……。そして、その調査のためにわざわざ検証センターに出向き、64もの機種を調査されたというのが凄いです。会場も沸いていました。

しかし、そんな検証を個人でやるのは大変だという事実。キャリアから公式サイトに向けた資料はNDAベースですし、端末のメーカーごとに対応がまちまちだったりするところを見ると、端末側の技術資料もあまり共有されていないように見受けられます。そういったところがオープンになり、情報が共有されるようになって行けば、安全性の向上にもつながりそうですね。

続きます……「どうするケータイ認証」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: OpenIDのモバイル対応 ~ 認証基盤連携フォーラムの取組み他から

公開: 2010年5月29日22時10分頃

WASForum Conference 2010、Yahoo!のお話に引き続き、OpenIDのお話です。野村総研の崎村夏彦さんによる「OpenIDのモバイル対応 ~ 認証基盤連携フォーラムの取組み他から」。

OpenIDって、何?

  • Open Identity
  • Identity とは?
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の実現

OpenIDはモバイルでは……。

  • コンテンツ画面で「ログイン」をクリックすると……エラーが発生
  • GET URLが長すぎる
  • POSTにすれば通るが、ユーザーがクリックしなければならない
  • レスポンスにはAssersionが全て乗るのでさらに大きくなる
属性連携はユーザ利便性を高める

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

  • 時間短縮削減、エラー発生率低下の効果
  • 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月最終仕様?

属性をどう表現するのか

  • Type URI で表現するのが主流
  • どの Type URI を使うかのコンセンサスはない
  • AXSchema, Portable Contacts, etc... ユーザのOPによってリクエストするURLを使い分けなければならない
  • フリガナなどはない。そもそもスクリプトの概念がないので、ひらがな/カタカナ/漢字のような指定ができない
  • "Type_URL#言語_スクリプト_国" の形で表現する案 例: http://axschema.org/nameParson#ja_Kana_JP
  • Artifact Binding の短縮表記案 例: ns:ax/foo = http://axschema.org/foo

Q&A

  • Artifact Binding
  • SAMLなどと比較した際の優位性は?
  • OpenIDとSAMLの相互運用性確保
  • Idプロバイダが廃業すると……
    • 今まではサービスプロバイダ = IdPだった
    • 分離されると……IdPの廃業でサービスにログインできなくなってしまう
    • アメリカで4社廃業、うち2社はトラストフレームワークに入っており、データをエスクローしていて問題なし
    • どこまでの情報を移行すれば良いのか?
    • RPごとに別々のIDを振り出せる……どこにどのIDか、という情報まで必要
  • デバイス間のセッション引き継ぎ
    • 携帯電話上でパスワードを入れさせるのはユーザからの評価が非常に低い
    • しかし、インターネット上で識別番号を使用するのは非常にまずい
    • タンパリングされている可能性が高い
    • ガラケー → フィーチャーフォン
    • ケータイから来ているかどうかを知りたい、というニーズがある(AOL / Yahoo)
    • ケータイキャリアがOpenIDプロバイダになれば良いのだが……

WASF2008のときにはOpenIDをあんまり理解していなかった私ですが、2年経ってもそんなに理解が進んでいない気がしております。というわけであんまりコメントすることはありません。

※結構知らない単語や概念があったりして、勉強不足を痛感しております。orz 午後の上野さんのセッションの方が入門的な内容だったので、順番が逆の方が分かりやすかったかもしれません。

このセッションで一番印象に残ったのは、やはり「フィーチャーフォン」でしょうか。「ガラケー」ではなく「フィーチャーフォン」と呼ぶのがクールみたいですよ。

続きます……「ケータイ2.0が開けてしまったパンドラの箱」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: 国民のためのウェブサイトを運営するID認証の舞台裏 (後半)

公開: 2010年5月29日13時35分頃

WASForum Conference 2010、国民のためのウェブサイトを運営するID認証の舞台裏。前半に引き続き、外部サービスとの連携の話に移って行きます。

オープン化とプライバシー

  • 社内で明文化されたポリシー : 「ヤフーをプラットフォームとして、ヤフーだけにとどまらず、パートナーサイトとの最適な連携を通じて、インターネット上に存在する情報・サービスの中から、お客様にとって最良の情報・サービスを提供して行く」
  • OpenID、OAuthなどによるプラットフォーム提供
  • プロバイダ側が充実しても、ユーザーにはその事が分からない。共同プレスリリースを出して行く
連携の例
  • smart.fm × Yahoo!
    • Yahoo!側のプロフィールをsmart.fm側で出せる
    • 渡したくないものは渡さないように選択できたりする
  • Oisix × Yahoo!
    • 決済・ポイント連携
  • 何が起きるかを明確にユーザーに説明する必要がある
  • パートナーサイト→ログイン画面(Y!)→同意画面(Y!)→パートナーサイト登録画面(追加情報の登録)→パートナーサイト登録完了画面
どのように連携するか
  • ID連携のみ (OAuth)
  • + 属性連携 (Attribute API)
  • + 決済連携 (Wallet API)
  • + ポイント連携 (Point API)
どの属性情報をどの外部サービスに提供するか
  • 本人が利用する情報 : 配送先、氏名、電話番号など。ショッピングサイト、銀行などに提供
  • 他のユーザーに見せる情報 : 表示名、画像など。SNS、ゲーム、コミュニケーション用サイトなどに提供
  • SNSなどは両方を使ったりする
API公開情報レベル区分
  • LV1 提供可能: 購入・決済に関わらない情報
  • LV2 特定企業に審査後に提供可能: 購入・決済に関わる情報
  • LV3 提供不能: 個人を識別する情報
  • 大切なお客様の情報をどういった基準でどこまで提供するか? → 現状はYahoo!として独自に判断している
  • 各企業の独自判断ではなく、共有できるルールか必要とされている
  • facebook connect 50%以上、twitter OAuth 25%くらい
  • Activity Stream から生まれるトラフィックが魅力
  • さらにfacebook、twitterを利用するというエコサイクルを作っている

外部サービスとの連携の際に、「何が起きるかを明確にユーザーに説明する必要がある」というお話は印象深かったです。いつも思うのですが、twitterのOAuthの画面などは何が起きるのか分からないわけでして、実際、OAuthでspamツイートを送信させるような攻撃が行われています。

あとは、どのサービスにどの属性を渡すのかというレベルの話ですね。

……完全に余談ですが、スライドの左上に「Y!」のロゴが入っていて、そのすぐ右にページタイトルが入るというデザインになっていたので、ページタイトル部分が「Y!××」というサービス名のように見えました。

続きます……「OpenIDのモバイル対応 ~ 認証基盤連携フォーラムの取組み他から」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: 国民のためのウェブサイトを運営するID認証の舞台裏 (前半)

公開: 2010年5月26日1時25分頃

WASForum Conference 2010、オープニングセッションに続いて、ヤフーの松岡泰三さんによる「国民のためのウェブサイトを運営するID認証の舞台裏」。松岡さんは「R&D統括本部プラットフォーム開発本部セントラル開発1部」に属し、OpenID、OAuth、認証API、認証(ログイン)、ソーシャルプラットフォーム、ストレージプラットフォーム、外部サービス連携……といった諸々のお仕事をされているそうで。

今回のお話は大きく前後半に分かれていて、前半はYahoo!の認証に関する仕組みや統計データについてのお話、後半は外部サービスとの連携の話になっていました。まずは前半部分のメモから。

Yahoo! Japan ID の現在

  • アクティブユーザ数 …… 2396万ID
  • Yahoo!ウォレットのユーザ数 …… 1900万
  • Yahoo!プレミアムの会員数 …… 759万

アクティブユーザ = 月1回以上ログインしているユーザと定義、単純な会員数はほぼ日本国民の数と同じくらい。

  • ログイン試行数 …… 775万回/日
  • ログイン成功数 …… 698万回/日 (90.4%)
  • ログインエラー数 …… 77万回/日 (9.6%)

主な間違いは ID、パスワードの入力ミス (ログインフォームのIDはフィルしていない)。

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

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

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

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

Yahoo!のIdentityプラットフォーム

安心・安全・便利

さまざまなニーズ
  • さまざまなサービス …… 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!きっずでしかログイン状態にならない)
どれがベストか?
  • パスワード再確認画面は何で必要なの? どういうリスクがあるの?
  • 多様なニーズに応えながらも、守るべきは守る

ユーザを守る機能とその課題

不正アクセスからユーザーを守るために「ログイン履歴」「ログインシール」「ログインアラート」という仕組みを用意している。社内ではこれら3つを「ログイン3兄弟」と呼んでいる。

ログイン履歴
  • 直近60件のログインの履歴を表示。成功も失敗も記録。
  • 表示する情報は……どのサービスでログインしたか、ログイン時刻、ログインなのか再確認なのか、成功or失敗、IPアドレス、端末がPCかモバイルか
  • 悪いことをしようという人にもこのサービスの存在を知ってもらって、抑止につなげたい
ログインシール
  • ログインフォームに、ユーザーが設定したシールを表示する
  • フィッシング防止のため
ログインアラート
  • ログインするたびにメールが届く
  • メールにはURLが書かれており、そのURLにアクセスするとアカウントをロックすることが可能。ログインに心当たりがないときにはロックを。
  • ただし強制ログアウトにはならず、現在のセッションは有効。次回ログインからブロックされる。
ログイン3兄弟の課題
  • 利用率がイマイチ……。
  • 場所が分かりにくい。たとえば、ログインアラートは「Yahoo!トップの右上」→「ガイドページの左下」→「ログインアラート説明ページ」と辿らないと出てこない
  • ログイン履歴の利用 = 136万PV/月
  • 他の2機能の利用数は非公開 (と言いつつ、利用数のグラフは公開)。シールは利用率が低く、アラートはさらに低い
  • 選択式ではなかなか利用者数が増えない
  • しかし、全ユーザーに利用を強制するわけにも行かない
  • 利便性を保ちつつ全ユーザに適用できる対策はないか?
リスクベース認証
  • "Login Risk Manager" という仕組み
  • あらかじめユーザーの利用環境、アクティビティの情報を持っておく
  • 普段の利用と著しく異なる時間、環境、国からのアクセスは怪しい
  • ログインイベントの不審度(リスクレベル)を判定し、レベルによって通知or追加認証orブロックを実施する
  • この仕組みであれば、非常時以外は普段と何も変わらない利用ができる

数値データは参考になります。特に、ログインエラーの数が1割近いというあたり、いろいろ考えさせられるものがありますね。

それから、ログイン3兄弟の話。ログインシールは実際どのくらいの有効性があるのかな、と疑問に思っていたのですが、そもそも使っているユーザが多くないようですね。

ちなみに、一部で「ログインシールも捏造され得るのでは?」という疑問も出ていたようですが、このログインシール、ベリサインのシールなどとは根本的に異なるものです。このYahoo!のログインシールは、ブラウザのCookieと連動して表示される仕組みになっています。そのため、ドメインが異なる偽サイトにアクセスした場合、ログインシールのCookieは送られませんから、正しいシールをく表示することができないという仕組みです。そのため、ブラウザを変えると表示されなくなるという欠点もあり、以下のように説明されています。

ログインシールはブラウザ(Internet Explorer、Firefoxなど)ごとに設定するので、1台のパソコンを家族で共有している場合などは、誰がログインページを表示しても同じログインシールが表示されることになります。また、複数のパソコンや複数のブラウザを利用している場合(家や会社など)はそれぞれに設定する必要があります。

以上、ログインシールでフィッシング詐欺対策 - Yahoo! JAPAN IDガイド より

……というわけで、欠点もありますが、仕組みとしては有意義なものです (繰り返しますが、ベリサインのシールとは違います)。

リスクベース認証の話はなかなか筋が良いと思いますが、利用者の身近な人による不正アクセスは防ぎにくそうにも思えますね。他のさまざまな仕組みと組み合わせて使って行く必要があるのでしょう。

後半に続きます : 国民のためのウェブサイトを運営するID認証の舞台裏 (後半)

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: オープニングセッション -「Webサイトを安全に使う秘技とユーザが直面する3つの危険」

公開: 2010年5月24日17時30分頃

WASForum Conference 2010 (wasforum.jp)に行ってきました。印象に残った話を中心にメモ。ただし、あんまり網羅できていなかったりしますし、聞き違いや勘違いが含まれている可能性もありますのでご注意ください。

まずはオープニングセッション、「Webサイトを安全に使う秘技とユーザが直面する3つの危険」。フォーラム代表でもある、奈良先端科学技術大学院大学の門林雄基さんによるお話です。

Webアプリのセキュリティ問題

  • ユーザ - デベロッパという軸と、クライアント - サーバという軸の2軸で見ることができる
  • セキュリティという面では、ブラウザ(ソフトウェア)、サーバの比重が大きく語られてきた
ユーザとWebブラウザ
  • うまいユーザ vs 下手なユーザ、地味なブラウザ vs 派手なブラウザという軸
  • 地味なブラウザの例: w3m
  • 下手なユーザ + 地味なブラウザ = ダサイ
  • 下手なユーザ + 派手なブラウザ = 危険
Webブラウザの進化
  • 1993年 CERN = 自転車
  • 1994年 Netscape Navigator = スーパーカブ
  • 2010年 (あえて具体名は出さない) 爆速・多機能 = デコトラ

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

3つの危険

  • まぜるな危険
    • あそびと、しごと。同じブラウザ?
    • あそびはChrome、仕事はFirefox?
  • アクティブコンテンツ危険
    • 聞いたこともないサイトにJavaScriptオンのままアクセスする達人はいませんよね?
  • パスワード危険
    • いろいろなサイトで同じパスワードを使っていたり……
    • 2要素認証、クライアント証明書も使える
    • 流行ってないですよね……と言われますが使っていないだけでは?

どうやって安全運転させる?

  • URLバーの色だけで状況判断できる?
  • 自動車の運転席 vs 飛行機の操縦席
  • ゾーン設定のツマミは、ダッシュボードの奥の方?

危険をどうやって伝える?

  • 自動車の場合、道路標識がある
  • 「慎重にクリックしてください」?
  • マウスが滑ったら事故が起きる? onmouseover="game.over"

今までのWASFではサーバー側のセキュリティ問題を中心に扱ってきていて、ユーザー側、クライアント側のセキュリティについてはあまり取り上げて来なかったというお話でした。今回はユーザー側、クライアント側の問題を中心に、ユーザーへの教育という観点も含めて論じて行きたい……ということですね。

というわけで、このお話は前振りです。ざっくりとテーマが提示されたところで、次のお話に続きます : 国民のためのウェブサイトを運営するID認証の舞台裏 (前半)

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

最近の日記

関わった本など

ウェブの仕事力が上がる標準ガイドブック 5 Webプログラミング