« はてな認証 API への攻撃シナリオ | メイン | はてな認証 API の改善案 »
2006年05月11日
Re: 攻撃してください→はてな認証の仮想セッション
先のエントリについて、tociyuki さんが、「セッションを開始しておけば、第三者にそのセッション ID が漏れない限りハイジャックするのは難しいのでは?」ということで、
セッションを作るときは下のようにするのが通常のやりかたです。これに対して「攻撃者がステップ 10 および 11 から cert のみを取得でき、被攻撃者のクッキーを読めない」という前提で、攻撃のシナリオはどうしたら良いのでしょうか? 攻撃者と被攻撃者のクッキーのセッション ID は異なるとします。
(攻撃してください→はてな認証の仮想セッション)
というエントリを書いていらっしゃいます。
そもそも、tociyuki さんが書いてらっしゃるような対策コードを (それが有効な対策だとしても) 各アプリケーション開発者が正しく実装してくれるのか... 対策をするのであれば、認証 API レベルで対応した方が簡単かつ確実ではないでしょうか、という点はさておき。
攻撃用の手順ということで、「A+番号」という表記で説明します。
A1) | 攻撃者が、手順 1 - 6 を実行して、サードパーティアプリケーション (S) におけるログイン待ちのセッションを作成 (ss=ABCDE, mycert=12345 とする)注1 |
A2) | 被攻撃者が、 http://auth.hatena.ne.jp/auth?api_key=…&api_sig=… にアクセス (この際、 URL に有効な mycert が含まれていてもいなくても良い) |
A3) | 被攻撃者に対し認証サーバが、 http://www.some.jp/check?cert=@@@@@ へのリダイレクトを指令注2 |
A4) | A3 の後で (手順10-11のあたり) で cert が攻撃者に流出 |
A5) | 攻撃者が、 A1 のセッションとと cert を組み合わせ、 GET /check?cert=@@@@@&mycert=12345 HTTP/1.0 のようなリクエストを生成して、S にログイン
Host: www.some.jp Cookie: ss=ABCDE |
以上です。
要は、 Session Fixation の場合と話は同じで、「ログイン前にセッションID発行をしてはいけない」ということです。
参照: 「CSRF」と「Session Fixation」の諸問題について - 高木浩光, p. 42)
注1: A4 のタイミングにあわせて行っても良いし、定期的に繰り返しても良い
注2: はてなの認証サーバは、いったん承認したサードパーティアプリケーションについては、以後確認をもとめない (はてなにログイン中の場合は直ちにリダイレクトする) ので、被攻撃者にログイン用リンクを踏ませて自動的に A4 まで達するような攻撃も可能です
投稿者 kazuho : 2006年05月11日 05:59
トラックバック
このエントリーのトラックバックURL:
http://labs.cybozu.co.jp/cgi-bin/mt-admin/mt-tbp.cgi/589