« はてな認証 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
Host: www.some.jp
Cookie: ss=ABCDE
のようなリクエストを生成して、S にログイン

以上です。

　要は、 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