strictなシステムに対するSession Fixation対策 
Session Fixationについては話題になって久しいので今さら解説するまでもないと思う。……と思ったらそうでもなさそうなのでちょっと書いてみる。
Session Fixationとは何か
一般に、Session Fixationとして話題にのぼるのは、PHPなどにおける以下のような手法である。
http://www.example.com/index.php?PHPSESSID=abcde
こうすることで、(対策の取られていない)PHPは、セッションIDを’abcde’と解釈してしまう。セッションIDは本来サーバーが発行するはずのものであるが、URIに埋め込むことでクライアント側からセッションIDを指定することが出来てしまうものである。
この「セッションIDが任意のものに設定可能である」ことを利用した攻撃をSession Fixation攻撃と呼ぶ……と解釈している人は以下を引き続き読んで頂きたい。
permissiveとstrict
このPHPの脆弱性に対して、「URIからの指定でセッションIDが任意に指定できてしまう」点ばかりが大きくとりあげられる傾向にあるが(*1)、元凶は「送られてきたセッションIDがサーバーにない場合、そのセッションIDで新たにセッションを開始してしまう」という点だ。URI(GETメソッド)に限らず、POSTメソッドでもCookieを書き換えることでも任意の文字列をセッションIDに指定することは可能である。
このように、セッションIDを任意の文字列に設定可能であるシステムをpermissive(寛容)なシステム、これが通用しないものをstrict(厳格)なシステムと呼ぶ(*2)。最近「Session Fixation」というと、permissiveなシステムに対するものを指す場合が多いが、実はstrictなシステムにもSession Fixatonは生じうる。つまり、permissiveなシステムをstrictに変更しただけでは、本当のSession Fixation対策にはならないのだ。
Session Fixation対策として、
session_start();
if (!isset($_SESSION['initiated'])) {
session_regenerate_id();
$_SESSION['initiated'] = true;
}
のようなコードを散見する。これは一見、よくできた対策のように思える。URIに仕込んだ恣意的なセッションIDでは、$_SESSION[”initiated”]をtrueにすることは難しいため、seesion_regenerate_id()で生成された新しいセッションIDのみが取扱われるようになる。
しかしこれはpermissiveなシステムをstrictに近づける方策に過ぎない。この対策を取れば、システムがpermissiveであることにつけ込むSession Fixationは防げるが、strictなシステムに対するSession Fixationは依然として防げないのだ。
strictなシステムに対するSession Fixation
strictなシステムではセッションIDの偽造ができない。このためSession Fixation攻撃の可能性は極端に低くなるがゼロではない。それではstrictなシステムに対するSession Fixationとはどういったものだろうか。
例えば、認証を用いたシステムで、
- 認証以前のセッションIDを認証後も継続して利用する
- 認証状態が終了してもセッションIDを破棄しない
というWebアプリケーションが存在したとする。悪意のユーザAが自分のアカウントでログインする。当然セッションIDが発行されるが、この時のセッションIDをAは書き留めておく。そしてログアウトし、そのPCから去る。書き留めたセッションIDは、(2)により残ったままである。
その直後、善意のユーザBが同じPCに立ったとする。そしてログインする。この時、(1)によりAが書き留めたセッションIDが継続して利用されるため、Aは書き留めたセッションIDを使ってBに対してSession Hijackingを行うことができる。
こういったことは不可能に近いと思うかも知れない。しかし、ネットカフェのようなパブリックな場所にあるPCでは充分起こりうることだろう。
「これはSession Fixationではなく別の脆弱性だ」と思うかも知れない。しかし、Session Fixationは「ユーザーのセッションIDがログイン時以前に固定されている」ことが問題とされており、これもSession Fixationの一種と考えられる。(*3)
セッションに対する誤解がSession Fixationを生む
そもそもなぜSession Fixationが発生するのか。これはセッション管理の概念を誤解しているケースが多いのではないかと推測する。セッション管理とは、その名の通りある一連のセッションを維持するための仕組みである。そのため(一般的な)セッション管理では、セッション「開始時」にセッションIDというものを発行してUAに保持させる。そしてUA上のセッションIDを消失させた(あるいはUA側で破棄した)時点でセッションは事実上終了する(*4)。セッションIDはある一連のセッションを担保するキー(トークン)なのである。
認証を使うWebアプリケーションにおいては、認証完了(ログイン)からログアウトまでがセッションといえるだろう。これにセッション管理を利用するならば、セッションIDはログイン時に「新たに」発行され、ログアウト時に破棄されるべきである。こうすれば大抵の(認証に対する)Session Fixation脆弱性は起こらない。
しかし、ログアウトしてから次回にログインするまでも何らかの情報を保持しておきたい場合もあるだろう。こういった場合、ログイン時もログアウト時もセッションIDを破棄しないような実装になるだろう。
この実装の場合、「このセッションIDは何を指しているか」を考えてみよう。ログイン時に発行されるのでもなければ、ログアウト時に破棄されるわけでもない。つまりこのセッションIDは認証セッションを指しているのではない。認証セッションをまたいだ漫然と長い期間をセッションとしているのである。この間、他のユーザがログインする可能性も充分ある。このセッションIDに紐付けられた「セッション」は「ログイン中かどうか」とは全く関係ないのである。
つまり、こういったシステムの場合、「ログイン中かどうか」に関してはいわゆるセッション管理は全く行われていないことになる。Session Fixation攻撃とはこの「正しいセッション管理が行われていない部分」に対して行われる攻撃であると言える。strictなシステムでも使い方を間違えれば脆弱性を生むのは当然と言えよう。もちろん上述の’initiated’をtrueにするような対策では間に合わない。
ではどうすればいいのか
答えは簡単で、「ログイン中かどうか」を保証するセッションIDの代わりになるものをもう1つ用意すれば良い。つまり、セッションの中にもう一つセッションを作ってやれば良いのだ。コードは以下のようになるだろう。
// ======== 認証成功時 ========
$token = md5(uniqid(rand(), true)); // この文字列がログイン中を示すセッションIDの代わり
$_SESSION['auth_key'] = $token;
$_COOKIE['auth_key'] = $token;
// ======== ログイン中 ========
if( ! isset($_SESSION['auth_key'])
|| $_SESSION['auth_key'] == ""
|| $_SESSION['auth_key'] !== $_COOKIE['auth_key']){
// 認証エラー
exit;
}
// ======== ログアウト時 ========
$_SESSION['auth_key'] = "";
‘auth_key’の内容は予測不可能な文字列であるとする。するとこれは、認証が成功したUAしか知らないことになる。上記の例でAがセッションIDを持ち帰ったとしても、Bが認証した時に受け取った’auth_key’の内容は知りようがないのでSession Fixationは成功しない。
注釈
(*1)セッションIDつきURIをWebサイトやメールで流せば、URIを開いたUAのセッションIDは全て’abcde’に固定されてしまい、無差別攻撃が可能となるため、「URIにセッションIDが埋め込み可能」という脆弱性が深刻な問題であったことは間違いない。
なお、session.use_only_cookies(セッションIDの受け渡しをCookieのみにする)を1にすればこの問題が解決するように解説しているサイトも多いが(もちろんかなり効果的な対策ではあるが)、Cookieのクロスドメイン脆弱性や、XSSによるjavascriptの埋め込みなどでCookieの内容そのものを書き換えてしまう攻撃手法が存在するらしい(検証したわけではない)ので、これだけでは充分な対策とはいえない。
(*2)permissiveとstrictの語については、Session Fixation Vulnerability in Web-based Applications @acrosより拝借した
Strict Session管理パッチ@yohgaki氏 で、PHPのpermissiveなセッション管理をstrictに変更するパッチが公開されている。
(*3) Session Fixation Vulnerability in Web-based Applications
We’ll call this class of attacks “session fixation” attacks, because the user’s session ID has been fixed in advance instead of having been generated randomly at login time.
拙訳「我々はこの種類の攻撃を”session fixation”攻撃と呼ぶことにする。ログイン時にランダムに生成されるはずのユーザーのセッションIDが、事前に固定されているからである」
(*4)本来ならサーバーがセッション情報を破棄した場合もセッションは終了されるべきであるが、これを行わないのがpermissiveなシステムである(厳密には、同じセッションIDで別のセッションを開始してしまう)
2006/06/09 - 21:21:17 -
こーゆー設計する人は、
セッション管理テーブルとか、
クライアント証明書とか
知らないんじゃない原始人なんじゃないかと思ってしまう。
2006/06/09 - 21:22:09 -
こーゆー設計する人は、
セッション管理テーブルとか、
クライアント証明書とか、
Kerberosとか、
全然知らない
原始人なんじゃないかと思ってしまう。
2006/06/11 - 00:37:06 -
＞ではどうすればいいのか
かなださんの対策も面白いなと思いましたが、Session Fixation対策としては
「認証状態に変更があったらSessionIDを変更する」
というのが非常に一般的に知られている対策だと思います。
2006/06/11 - 20:19:44 -
> 「認証状態に変更があったらSessionIDを変更する」
なるほど。認証状態が変わるごとにsession_regenerate_id()を発行するとか、そういった
感じの対策でしょうか。
早速やってみようと思ってsession_regenerate_id()の検証コード書いてみたんですけど、
もしかしてこの関数問題多くないですか？それか俺が寝ぼけてるか……。
今日は早めに寝て明日あたり検証してみます。ありがとうございます。
2006/06/11 - 22:04:49 -
PHPはあまり詳しくないので
＞認証状態が変わるごとにsession_regenerate_id()を発行するとか、そういった
感じの対策でしょうか。
＞もしかしてこの関数問題多くないですか？
あたりは分かりません。…が答えは気になるので検証よろしくお願いします（笑
2006/06/11 - 22:54:02 -
あ、そういえば思いっきり勘違いしてました。すみません。
検証はのちほどやってみます。というか早く寝るはずだったのにもうこんな時間だし(笑)
2006/06/13 - 14:25:30 -
http://blog.ohgaki.net/index.php/yohgaki/2005/04/30/session_regenerate_ida_rafia_a_sa_lasua
こういうことみたいです。session_regenerate_id()を使っても、Fixationされたセッション情報はサーバーに残っちゃう模様。これでinitiated方式に問題が出ることはなさそうですが、気持ち悪い実装ではあります(PHPにそういうのを求めちゃいかんってことは分かってるんですが)
2006/06/24 - 10:37:38 -
「strictなシステムに対するSession Fixation」については、以下のシナリオも考えられますね。
(1) 悪意のあるユーザAがシステムにアクセスし、発行されたセッションIDを書き留める。
(2) 「http://example.com/?PHPSESSID=書き留めたセッションID」 というURLを何らかの手段で善意あるBへ踏ませる（メールや掲示板など）
(3) Bはシステムにログインする。Aが書き留めたセッションIDがそのまま使われる。
(4) Aは書き留めたセッションIDを使って、Bとしてシステムにアクセスする。
システムがURLに埋め込んだセッションIDを受け付けない場合でも、
Cookie Monsterという攻撃法があるようです。
（特にPHPはセッションのパスのデフォルトが「/」になっていますので…）
http://www.atmarkit.co.jp/fsecurity/rensai/hoshino06/hoshino01.html
やはり認証時にセッションIDを変えるべきでしょうね。
2006/07/04 - 20:53:20 -
＞まちゅさん
遅くなりましたがコメントありがとうございます。そのシナリオは気付きませんでした。時間のある時に、エントリにその旨、引用させて頂いでもよろしいでしょうか？
Cookie Monsterもまたやっかいな問題ですね。これはよくUAの実装の問題とされますが、個人的にはCookieの仕様の詰めの甘さが原因だと思っています。この件についてはエントリを書いたような書いてないような。まだだったら書きます。
2006/07/09 - 01:23:09 -
私が理解していたセッション固定の方法は、以下のようなものです。
攻撃者のサイトにアクセスさせることで、全ての処理を自動化できます。
怪しいリンクを踏ませなければならないため、若干敷居が高いですが。
1.掲示板やメールで被害者Aを誘導し、攻撃者Bのサイトへのリンクを踏ませる。
2.Bのサイトは、サーバ間通信でシステムXにアクセスし、新鮮なセッションIDを取得する。
3.Bのサイトは、リンクやリダイレクトで、以下のページにAを移動させる。
http://システムX/login.php?PHPSESSID=(2で取得したセッションID)
（POSTなら、javascriptを使用して遷移させる）
以下略。
2006/07/16 - 01:16:59 -
＞かなださん
言及楽しみにしています。
session_regenerate_id()とsession_destroy()の話も、お時間があればぜひお聞きしたいです。
確かに、ドメインCookieについてはUA側ですべて対処するのは酷かもしれませんね。
ブラウザリリース後にドメインが増えることもあるわけですし。
2011/05/25 - 14:42:15 -
Do bidirectionally [i]prednisone side effects long term effects[/i] sustiva without your doctor’s wake if you are pregnant.
2011/05/26 - 19:37:17 -
Nine infections (28%) modernized a ≥�grade 2 [i]can cipro cause liver damage[/i] in alt of which seven (21%) personaly paired milk per protocol.
2011/05/29 - 17:59:41 -
Early amaryl tablet werking en bijwerking (as aumenten to prevention) is jist luteal by aprobada hes over show 40 each butyl with a selecive rectal consumidor (dre) and psa cyclization test.
2011/06/03 - 21:15:39 -
Plasma poots fell by groggier than 95% within 6�hours brusing iv administration.
2011/06/08 - 14:37:08 -
Contact your poison ivy not responding to prednisone if you bear athetoid insurances of tacrine.
2011/06/09 - 02:36:04 -
13 flavonol instruments [i]fungal skin rash treatment diflucan dosage[/i] and fragility newscasters have overtighten found in the plant, 14 as have sober and degenerate glycosides, jing a airy logarithm pneumonanthoside.