昨日のインデックス入れるの忘れてた #wasf

posted at 09:03:19

#blog 「WASForum Conference 2010 参加メモ (2010/05/22 Sat)」<http://twilog.org/nsiena/date-100522/asc > #wasf

posted at 09:03:29

#article 読んでる: 「WASForumまとめ」<http://togetter.com/li/23160 > : 当日は読んでられなかったので目を通しとこ #wasf

posted at 09:05:39

ダブって午前に入れてしまったタスクをほぼ消化。後片付けして WASForum へ向かおう。現地入は 11:00 くらいかしらん ;_; #wasf

posted at 09:42:58

10分前くらいにコクヨホール。途中から聴いてる。 #wasf

posted at 11:27:21

ユーザセントリックID: 従来のサイトごとの認証モデルから、共通認証基盤による統一認証モデルへ #wasf

posted at 11:28:42

モバイルでの OpenID。ガラケーでは GET URI が長すぎて、OP へ要求を遅れずに失敗。応答は assertion が含まれ、更に大きく。 #wasf

posted at 11:29:10

URI を短くして単純な認証にするのはf不充分。属性連携はユーザ利便性を高めることが検証された。例えば、手入力のエラーや操作時間が減少。 #wasf

posted at 11:29:18

調査参加者は 94% 程度が非常に利用したい/利用したい、という圧倒的な結果。同時に、RP の信用性の確認手段が必要との声も。LoA 従来は個別の事業者同士の認定だったが、信頼フレームワーク提供者 (OITF) に集中化させたモデルへ。 #wasf

posted at 11:29:37

OpenID for Mobile。UA は Artifact のみを送受信。これを利用して、RP が OP から JSONP 形式の assertion を取得する。なぜ GET か。ログに残るから。 .o(HTTP のセマンティクスで、と言いたいところ #wasf

posted at 11:31:08

利点: GET が小さく。サーバ間通信なので拘束。assertion disclosure の防止。OP の完全ステートレス化。NIST の LoA 4 まで対応可能。... #wasf

posted at 11:37:20

... (条件を満たせば) 繰返し属性の取得が可能。OAuth 2.0 のトークン受渡しも同時に可能。実装が簡単 (OP 300L, RP 100L 含む HTML、LoA1 の RP ならページにスクリプトを追加するだけ) #wasf

posted at 11:37:25

属性の表現。どの Type URI を共通に使うのかコンセンサスがない。AXSchema, Portable Contacts 他。米仕様なので単一スクリプト前提。→ スクリプト表現案: Type_URL#言語_スクリプト_国 e.g. #ja_Kana_JP #wasf

posted at 11:41:38

OpenID v.Next。v.Next bDiscoverty, v.Next Core (Verified attribute, Active Client, etc.)。仕様を小さくしようという声もあるが、拡大路線。 #wasf

posted at 11:44:09

「Q. SAML との違い。A. discovery があるのと、実装が簡単な点。 #wasf

posted at 11:46:04

「OdP 間の ID 移行の課題。サービス終了とともに、ID を失ってしまう → トラストプロバイドに加入していると、廃業する時には ID 引取り要請に応じなければならないということになっている。サービスの突然死でも対応可能な場合あり。」.o(かな? #wasf

posted at 11:53:55

「利便性検討: デバイス間セッション引継ぎ」.o(これは便利。デバイスへの縛りから開放される。 #wasf

posted at 11:57:12

「ケータイでパスワードを入力するのは、携帯電話識別番号を使う方式に比べて、圧倒的に支持された。しかし、安全性に大きく問題がある。 #wasf

posted at 11:57:22

「Q.キャリアで誰が携帯電話識別番号を支持しているのか。A.問題視もされている。ケータイであることを確実に検出したい。Q.ユーザが自分で変更する分には問題ないのでは。」.o(高木さん! #wasf

posted at 12:01:16

「Q.キャリアが OpenID を提供すれば。A.そういう流れもある。詳しくは割愛。 #wasf

posted at 12:02:13

「京セラの Web脆弱性診断サービスの (LT 的な) PR。利点: 実績、経験のあるエンジニアによる診断、分かりやすい報告書。アンケート回答でノベルティ + 抽選サービス。」.o(ですってよ #wasf

posted at 12:06:15

ここで休憩。次は 13:00 から。 #wasf

posted at 12:06:43

手元に電源があったので確保。 #wasf

posted at 12:38:07

そういえば、OpenID はいくつかもってるけれど、OP 死でなくなったものもいつくかあったなぁ。ほとんど黎明期の。とか思い出しながらおひるごぱん。 #wasf

posted at 12:41:32

『ケータイ2.0が開けてしまったパンドラの箱』(13:00-13:45) : 盛沢山とのこと、なのできっと書き切れない >< #wasf

posted at 13:01:32

「『安全なSQLの呼び出し方』(IPA) #wasf

posted at 13:01:59

「かんたんログイン。ケータイから端末固有ID を送る。幾つかのメジャーなサービスを紹介。かんたんログインしか提供しないサービスも。 #wasf

posted at 13:07:22

「端末固有 = 全サイトに送信される = 秘密情報ではない。書き換えできないという前提。HTTPヘッダに乗るので通常は変更できない(といわれる)。→ かんたんログインが成立する条件: ケータイ網が閉ネットワーク ∧ ケータイ端末で減ったを変更できない #wasf

posted at 13:09:39

「2009/05 のドコモの報道発表にて、JavaScript対応。1.XHR使える、2.setRequestHeader() 使える、3.これで UserAgent などを書き換えられる、でなりすませる。同/10/末に 2.が無効化された。 #wasf

posted at 13:13:44

「mpw.jp ブログにて、iモード線用サイトの HTML ソースを読む方法 (正当な行為) の記事。DNS Rebiding による成りすまし攻撃により、same origin ポリシーが破られうる。JavaScript などで個人情報を第三者サイトへ送信可能に。 #wasf

posted at 13:17:55

「ケータイブラウザやゲートウェイで泰作すべきという意見あり。ゲートウェイ経由なのでブラウザでは名前解決していない。ゲートウェイは複数ユーザ対象なので、文脈を意識した pinning は不可能。→ キャリアでは対策ででない #wasf

posted at 13:20:29

「ゲートウェイで DNS キャッシュすれば攻撃はしにくくなるが、攻撃を無くすことはできない。キャッシュ更新のタイミングを狙って誘導。ケータイメールはすぐに見る人も多いので引っ掛かる可能性がある。 #wasf

posted at 13:22:34

「実機で実験した結果。ゲートウェイアドレスは複数。負荷分散か。1分程度はキャッシュしているようだ。しかし、これは対策にならない。 #wasf

posted at 13:25:15

「ウェブサイト側で対策可能。Host フィールドをチェック。簡単に実装するには、名前ベースの仮想ホストにすれば良い。 #wasf

posted at 13:26:25

「ケータイ2.0がパンドラの箱を開けてしまった。ソフトバンクも。2004/12 頃から、JavaScript 対応の端末あり。ただし、XHR、iframe, DOM などへ未サポートないし部分的サポートだった。 #wasf

posted at 13:29:16

「setRequestHeader() で改変可能なヘッダいろいろ。ソフトバンクが Host フィールドを変更できてしまう! (要設定変更) →ソフトバンク社に連絡して対策打合せなど。 #wasf

posted at 13:34:05

「4ヶ月弱が経過。端末更新はないが、DNS が 5分程度キャッシュするなど挙動が変化。しかし、対策として不充分。90機種のマニュアルをダウンロードして検証。検証センターで実機 60台を 3時間で検証。4機種が Ajax が有効だった!」.o(偉すぎる #wasf

posted at 13:36:55

「問題機種のサマリ。NEC, CASIO, Samsung の一部機種。ソフトバンクの端末は統制が取れていない印象。メーカー間の情報共有もなされていない。ソフトバンクと ACCESS の責任。」.o(誰かが写真を上げてくれるはず! #wasf

posted at 13:39:13

.o(「日本のケータイの安全のために」自発的にここまでされるのは本当にすごい。キャリア, メーカ, ソフト屋、もっとがんばれ。なにやってんの。 #wasf

posted at 13:42:40

「能動的攻撃の可能性。iモード端末など、二つのトリックで端末固有IDの改変が可能。対策は、SSL では簡単ログインを受け付けないようにする。キャリア判定は、User-Agent などではなく IP アドレスで。 #wasf

posted at 13:45:37

「まとめ。いろいろ問題が見つかっている。Ajax規制ないいスクリプトの禁止や、アプリ側の対策など必要。これで完璧かは誰にも分からない。 #wasf

posted at 13:47:26

「まだ、かんたんログインを続けますか? #wasf

posted at 13:47:32

『どうするケータイ認証』(13:45-14:30) : 高木せんせ #wasf

posted at 13:48:07

「ケータイウェブは WASForum であまり扱って来なかった: 独自方式で、仕様が不明確, NDA の壁で語られない, キャリアが責任を以ってやるべき話であって部外者が何かをしてやる立場ではない。 #wasf

posted at 13:50:52

「しかし。ケータイ独自方式が一般サイトに浸出。iモードID送信開始, スマートフォン対応の活発化。ガラパゴス化というよりも、技術者の蛸壺化も問題か。 #wasf

posted at 13:51:03

「ログイン認証の欠陥事例。DNS rebiding は古い問題 (199x)。ドコモ公式発表では、一般向けには対策などを提供していない。曰「Ajax などについては皆が知ってるはず」。 #wasf

posted at 13:54:00

「しかし、かんたん認証とかは、普通の世界にない独自のもの。知っているという前提はおかしい。 #wasf

posted at 13:54:14

「脆弱でない実装は簡単ではない。DNS rebiding 対策をしているだけでは十分ではない。IPアドレス制限と、ケータイIDチェックを個別に行なうと、有りえない組合せでも通過してしまう。 #wasf

posted at 13:57:28

「EMnetプロキシサーバの挙動: HTTP ヘッダに X-EM-UID が既にある場合は、本物で上書きして成りすまし防止。それ以外のヘッダは関知しない。他社のケータイID を削除するのは容易ではない。→ ウェブサイト側の脆弱性か #wasf

posted at 14:00:06

「公式な解説がなく、素人のずさんな解説が蔓延。e.g. 接続元アドレス制限に Google用の穴を開ける。/ EMnetだけでなく、ソフトバンクも X-JPhone-UID に類似の問題。User-Agent 中の端末シリアル番号は素通りするので認証に使ってはいけない #wasf

posted at 14:06:11

「U-A: がソフトバンクの所定のものでなければ拒否される。'所定の文字列' の後ろの文字列は無視される。ウェブアプリ側のキャリア判定ロジックによっては、後ろの文字列に反応して誤った判定をする可能性。→ 本当にアプリ側の責任? 公式情報の不在。対策を明確化できない。 #wasf

posted at 14:10:03

「IPアドレスでのキャリア判定は確実ではない。公式情報の不在 →他キャリアと統合したサイト構築の方法は保証外。/ SSL接続で得たID はそのまま届く。任意に変更可能な場合に危険。HTTP/SSL のページを提供していないつもりでも稼動してしまっている場合もある。 #wasf

posted at 14:17:31

「キャリアIPアドレスの明確な情報。HTTP/SSLでの安全な提供方法がない。機械的に処理可能な明確な記述がない。使用IPアドレスの増減。などなど。 #wasf

posted at 14:20:28

「クッキーで実装する。ログイン後に無期限のIDを クッキーとして発行。クッキーを使えないのはドコモたけ。/ そもそも UI がおかしい。押すだけのボタンなら最初からログインさせてしまえばいい。ログアウトも意味がない。昔の utn のなごり? なにこれ? #wasf

posted at 14:28:33

「「かんたんログイン」と呼ぶこと自体をやめてしまおう! きゃんぺーん(笑) : 無思慮な技術者に真似され続けるので。発注者の目に触れさせないように。 #wasf

posted at 14:30:29

「神話: パスワードより安全 (だいじなので時間使うよ!) : パスワードを登録しないサイトは、端末と対応付けるだけで充分なら成立していたが、SNS などキャリア乗り換えで ID 移行が必要なサイトも一般化。結局、ID/PW が必要。 #wasf

posted at 14:34:32

「iモードのクッキー未対応には? 原則としてクッキーで実装し、iモード1.0 のみ別途対応することを提案したい。 #wasf

posted at 14:35:56

「ニコ動 iPhoneアプリの事例: 内臓シリアル番号 UDID をセッション管理に使ってしまった。無線LAN で接続することもあるし。 #wasf

posted at 14:39:11

「ヤマダ電機 iPhoneアプリの事例: ユニシスいわく「iPhone個体の識別子とアプリ固有IDでセキュリティの高い認証が可能」→ 安全ではない。/ 誤解が広まっている #wasf

posted at 14:39:14

「国民 ID 的な利用方法の広がり。広まってしまうと、後戻りできなくなりかねない。一般インターネットへも波及してしまいかねない e.g. フィルタリング用途, 年齢情報も送信されるようになる?, などなど。 #wasf

posted at 14:41:54

「今後, 泰作が進められる可能性がある。ウェブサイト側は事前に対策しておくことを推奨。通常の PC 向けウェブサイトと同じように作る。/ 端末固有IDが必要、という主張は、大抵は別手段がある。 #wasf

posted at 14:43:57

「何を優先する彼の問題。プライバシーか、安心安全か → 両立を目指してこそのプロ。2010/02 に docomo ID が公開されたが、OpenID なのに iモードID が属性情報にある。iモードID の取得はやめておくべき。 #wasf

posted at 14:47:41

「15分も超過しまして(笑)」司会「セッションハイジャッカーが」(^^;; #wasf

posted at 14:48:51

『OAuthとWEBサイト運営のエコシステムに潜む罠』(14:30-15:15) : 「認証ばかりなので認可の話も #wasf

posted at 14:49:33

「エコシステム = 特定業界の収益構造を指す言葉」.o(収益に限定されないような気が。 #wasf

posted at 14:51:03

「エコシステムが成立するために。他サイトとの連携: コンテンツ/サービスの提供, マッシュアップ/APIの提供。ユーザ特定: 認証の提供。ユーザ固有コンテンツと連携: 認可の提供, 多くは認証後に。 #wasf

posted at 14:52:40

「認証 (authentication, AuthN) = 本人確認。認可 (authorization, AuthZ) = リソースへのアクセス権の付与。 #wasf

posted at 14:54:57

「どうやって他サイトのリソースのアクセス権を得るか。認証情報 (クレデンシャル) を連携サービスにも預ける方法: 平文で ID/PW を保存・送付している可能性。第三の管理者による管理というリスク。 #wasf

posted at 14:57:10

「例: Twitter 連携サイトで BASIC 認証 (2010/06 に廃止)。BASIC 認証にログアウトはない。」.o(ログインという考え方ではないし。都度、認証。 #wasf

posted at 15:02:18

「認証・認可を独自に作るべきでない。エコシステムに入るには共通仕様で。→ 認可を他サイトに任せたい。認証情報は預かりたくない。→ OAuth #wasf

posted at 15:03:42

「OAuth の発端: Twitter API のアクセス権を委譲したい (2007/12-)。現在 1.0 Rev.A。2.0 を策定中。今年度中? #wasf

posted at 15:04:56

「OAuth の手順の流れの概説と twitpic の例。 #wasf

posted at 15:09:17

.o(Twitter の OAuth の使い方は、許可する範囲が限定されないのがよくないよね。読むだけとか、書くのもとか、DM もとか。RP にカテゴリと機能の強弱を限定できるようにしてほしい。何が許可されるかユーザにも分かるようにしてほしい。 #wasf

posted at 15:09:25

「アクセス権の異常で何ができるか。サービスプロバイダ次第: リソースの種類と有効期限。サービスはここ 1年くらいでかなり増えた。国内のケータイに充分に対応できてないサイトも。まだ、パスワードを預かるサイトも多い。ust とか。 #wasf

posted at 15:12:32

「今や、他サイトのパスワードを預かる必要はない。OAuth を使う。利用者にも提供者にもメリット。 #wasf

posted at 15:17:56

「デスクトップアプリには xAuth がある。クレデンシャルからアクセストークンを取得。ただし、一度はアプリに ID/PW を預けねばならない。気になるなら、すぐに PW を変えればいい。 #wasf

posted at 15:18:02

「OAuth セッション固定攻撃。アクセス権の異常を許可したユーザと、コンシューマにアクセストークンを取得させるユーザの同一性が保証されないのが原因。コールバック URI を変える余地がある。→ 2.0 で改善 #wasf

posted at 15:21:26

「今後。1.0a は実装がやや複雑。Session Extention, WRAP, 2.0。今実装するなら 1.0a。それほどの手間ではない。 #wasf

posted at 15:25:44

「ユーザに知ってもらいたいこと: 異なるドメインやサービスに ID/PW を入力してはいけない。周知徹底は難しい。一般ユーザに見分けがつく? → UIが複雑すぎて、知っている人でも分かりにくい。広まって行けば、ユーザが意識しなくてすむ。 #wasf

posted at 15:25:50

「エコシステムの中核に立ちたい、輪に加わりたい → OAuth をぜひつかうべき。 #wasf

posted at 15:26:06

.o(暑くなってきた。つらい…… #wasf

posted at 15:37:25

『Web2.0におけるセキュリティ ～ セキュアなWeb2.0環境の構築とは』(15:30-16:15) : WASForum 史上、初の女性講演者、なのだそうな #wasf

posted at 15:38:22

.o(司会との会話での紹介で時間を使っててだいじょぶなのかしら ^^;? #wasf

posted at 15:39:16

「ウェブアプリの脆弱性は依然として多い。XSS が多い。2004-2007-2010 の変遷。XSS が上位へ。CSRF の出現。 #wasf

posted at 15:44:05

「Web 2.0 的アプリの特徴: (1) Ajax などスクリプトの多用, (2) マッシュアップによるサービス統合。コンテンツには CGM も多い。 #wasf

posted at 15:45:56

「現在のセキュリティモデル: same-origin policy。異ドメインから取得したコンテンツ間の通信を制限。ウィンドウ/フレーム単位でアクセス制御。XHR通信は同ドメインに制限。Web 2.0 では、この前提の崩れ: マッシュアップ, UGC, JSONP。 #wasf

posted at 15:48:51

「リッチなクライアント側機能が攻撃に利用される傾向にある。守るべきものの変化 (増加)。ブラウザのセキュリティモデルの改善が必要。 #wasf

posted at 15:50:03

「皆がばらばらに名付けていて、共通理解が困難。→ ウェブアプリケーション脅威の発生経路を L1～L8 種類に分類。これに基づいて、脅威を T1～T7 に分類。 #wasf

posted at 15:53:04

「T3: 攻撃者(HTTPサーバ)からユーザに対する脅威。悪意のあるサーバを善意のサーバと思い込ませる。フィッシングやファーミングなど。 #wasf

posted at 15:58:25

「T4: クライアント側インジェクション脅威。XSSなど。Web 2.0 で増加。サンドボックス内で悪意のあるコンテンツを処理させる。マッシュアップによっても同様の攻撃が発生しえる。様々なバリエーションがあり、フィルタリングしにくい。 #wasf

posted at 15:59:19

「T5: 善意のユーザのブラウザを踏み台にした、サーバに対する脅威。XSRF、JavaScript ハイジャッキングなど。 #wasf

posted at 16:18:25

「T7: ローカルネットワークに対する攻撃。Javaスクリプトによるポートスキャン, Cross-Site Printing, Drive-by Pharming など。 #wasf

posted at 16:19:04

.o(資料があとで公開されるってよ! #wasf

posted at 16:24:09

『SDL脅威分析の方法とWindows Live IDにおけるアプローチ』(16:15-17:00) #wasf

posted at 16:26:23

.o(通訳付きか…… #wasf

posted at 16:26:42

「サービス提供者のセキュリティミッション。C-I-A triad。IP知的財産の保護、顧客データとプライバシ、サービス可用性、(あと一つ聴き逃した) #wasf

posted at 16:28:36

「悪意あるユーザがどこからでも攻撃して来る。様々な形式のメディアが利用される。国際的な攻撃が行われる。 #wasf

posted at 16:29:54

「セキュリティアプローチ。パッシブモード: 脆弱性に対してパッチを当てる。プロアクティブモード: 潜在的な課題を特定して対策するフレームワークで対策する。 #wasf

posted at 16:31:44

「セキュリティ開発ライフサイクル (SDL)。今日の本題。訓練→要件定義→設計→実装→検証→リリース→インシデント対応。新しいプロセスを定めるものではない。通常のソフトウェア開発プロセスに導入する。 #wasf

posted at 16:34:27

「マイルストーンの設定。プロジェクト立上げ: 職務設定 (セキュリティアドバイザ, セキュリティチャンピオン = 実施しているかの監督), 訓練。 #wasf

posted at 16:37:29

「2.設計フェイズ: スコープ・ツール要件, スレートモデル, レビュー。3.プログラミング/テスティング: コーディングと設定のセキュリティベースライン, 検証。4.リリース #wasf

posted at 16:39:14

「投票アプリを例に。まず、どのような脅威が存在しうるのかを考慮。様々な脅威が考えられる場合に、コーディングのセキュリティガイドラインが必要。基本的なリスク以外も検討。 #wasf

posted at 16:42:44

「データフロー図で信頼性の境界と特定。ユーザの入力など外部との入出力。/ STRIDE というモデルを持っている。 #wasf

posted at 16:44:20

「STRIDE = S:なりすまし, T:改竄, R:repudation, I:情報漏洩, D:DoS, E:権限の昇格。 #wasf

posted at 16:55:03

s/repudation/repudiation/ #wasf

posted at 16:55:43

.o(さっきから眠さと戦ってる。デモベースの話はつらい…… --; #wasf

posted at 17:05:32

『クロージングディスカッション～ 脆弱性対策至上主義からの脱却』(17:00-18:00) #wasf

posted at 17:20:38

「今日扱われてきた話は脆弱性検査できる? かんたんログインとか」「おお。反応は?」「きびしい」「いろいろ提言があったが変わりそう?」「……」(^^; #wasf

posted at 17:25:11

「クライアント証明書で属性認証とか使っていてもいいと思うが、スルーされちゃってるのか」「ID の代わりに使ってるのがせいぜい」「研究開発の立場では、クッキーすら平文なのでありえないのにという」 #wasf

posted at 17:28:10

「物を作るという立場から見て、どういう影響がありそうと思ったか」「ツールを入れて脆弱性対策できたという客、そこがスタートと意気込む客と様々。どのように伝えていくのかが重要な課題」「ぜひ資料を公開して広められるようにお願い > 講演者の方々」 #wasf

posted at 17:32:50

「クッキーで ID 代わりにするのは、デバイスの保持権と同一視すること。認証は楽になるが、リスクに対する責任は?」「それ以前に、UI 的な問題でセキュリティが失われるようなものも。危機感が薄れた人が増えていく。大問題。」 #wasf

posted at 17:43:58

.o(だんだん締めに向かってる。楽しく、復習、参考になった。今日は懇親会ってなかったんだっけ。 #wasf

posted at 17:49:13

おしまーい。さて、帰る準備。 #wasf

posted at 17:49:59