PHP におけるセッション管理では、
$_GET ではなく、$_POST でもなく、$_COOKIE からセッションID を受け取り、
さらに、$_COOKIE 以外で半券(チケット)を受け取って、
セッションID と照合して正当性を確かめるのが定石だ。
1. $_COOKIE による受け取りが必要な理由:
したがって、
$_GET, $_POST でセッションIDを受け取るようなシステムでは、
悪意の第三者が仕掛けた罠によって、
悪意の第三者が指定したセッションID で、
あなたのセッションが開始される可能性がある。
2. $_COOKIE 以外での半券の受け取りが必要な理由:
したがって、
半券による照合のないシステムでは、
$_COOKIE だけでセッションが再開してしまい、
悪意の第三者が仕掛けた罠によって、
悪意の $_GET, $_POST が、あなたのセッションに混入する可能性がある。
$_GET ではなく、$_POST でもなく、$_COOKIE からセッションID を受け取り、
さらに、$_COOKIE 以外で半券(チケット)を受け取って、
セッションID と照合して正当性を確かめるのが定石だ。
1. $_COOKIE による受け取りが必要な理由:
1.1 悪意の第三者は、あなたのリクエストに含まれる $_GET, $_POST を、自由自在に変更する罠を作れる。
1.2 PHP ではリクエスト変数($_GET, $_POST, $_COOKIE)によってセッションID を指定できる。
したがって、
$_GET, $_POST でセッションIDを受け取るようなシステムでは、
悪意の第三者が仕掛けた罠によって、
悪意の第三者が指定したセッションID で、
あなたのセッションが開始される可能性がある。
2. $_COOKIE 以外での半券の受け取りが必要な理由:
2.1 悪意の第三者は、あなたのリクエストに含まれる $_GET, $_POST を、自由自在に変更する罠を作れる。
2.2 ブラウザは、リクエストの際に、ドメイン・パスが一致する Cookie を、自動的に付加する。
したがって、
半券による照合のないシステムでは、
$_COOKIE だけでセッションが再開してしまい、
悪意の第三者が仕掛けた罠によって、
悪意の $_GET, $_POST が、あなたのセッションに混入する可能性がある。
さて、最近は、XMLHttpRequest を使った、所謂 Ajax がアチコチで活用されているが、
get, post, cookie を上記のように駆使する事の有意性に何ら変わりない。
主要なブラウザの XMLHttpRequest では、
ちゃんと cookie が送信されるようなので、問題なし。
半券は、高木式を採用し、JavaScript で cookie を読んで、
XMLHttpRequest に追加して送信する。
ここまでは問題ない。
問題は、さらにワンタイムセッションを導入している場合だ。
複数の XMLHttpRequest を連続して実行する場合もある。
(例えば、データ登録フォームと登録済データ一覧とが、同一ページにある場合など)
そういう場合、当然、cookie も XMLHttpRequest の数だけ送信される。
通常の同期通信では、リクエスト毎に逐次セッションID が変わって無問題なのだが、
非同期の XMLHttpRequest では、非同期であるが故か? どうもそうならない。
送信内容を監視してみると、
連続する XMLHttpRequest の間 cookie の値(セッションID)が変わらない。
しかし、サーバ側では、最初のリクエストの時点でセッションID は切り替わっている。
つまり、途中でセッションが切れている?
というか、実は、
クライアント側には cookie が、
サーバ側にはセッションデータ(及び、その抜け殻)がウジャウジャ出来て、
挙動がつかみきれなくて、イヤになった。
ひとつだけ言える事は、
上記【前提】を見直したほうが良さそうだということ。
Ajax 使わないセッションならリクエスト毎にセッションID を変更してもまぁ良いかと思っているけど、
Ajax 使うと、1つのブラウザから非同期でリクエストがあるわけだから、
リクエスト毎よりはユーザのアクション毎とか、あるいはタイマーでセッションID 変えるほうが賢いかもしれない。
get, post, cookie を上記のように駆使する事の有意性に何ら変わりない。
主要なブラウザの XMLHttpRequest では、
ちゃんと cookie が送信されるようなので、問題なし。
半券は、高木式を採用し、JavaScript で cookie を読んで、
XMLHttpRequest に追加して送信する。
ここまでは問題ない。
問題は、さらにワンタイムセッションを導入している場合だ。
【前提】リクエスト毎にセッションID を変更している。ユーザの1クリックをトリガーとして、
複数の XMLHttpRequest を連続して実行する場合もある。
(例えば、データ登録フォームと登録済データ一覧とが、同一ページにある場合など)
そういう場合、当然、cookie も XMLHttpRequest の数だけ送信される。
通常の同期通信では、リクエスト毎に逐次セッションID が変わって無問題なのだが、
非同期の XMLHttpRequest では、非同期であるが故か? どうもそうならない。
送信内容を監視してみると、
連続する XMLHttpRequest の間 cookie の値(セッションID)が変わらない。
しかし、サーバ側では、最初のリクエストの時点でセッションID は切り替わっている。
つまり、途中でセッションが切れている?
というか、実は、
クライアント側には cookie が、
サーバ側にはセッションデータ(及び、その抜け殻)がウジャウジャ出来て、
挙動がつかみきれなくて、イヤになった。
ひとつだけ言える事は、
上記【前提】を見直したほうが良さそうだということ。
Ajax 使わないセッションならリクエスト毎にセッションID を変更してもまぁ良いかと思っているけど、
Ajax 使うと、1つのブラウザから非同期でリクエストがあるわけだから、
リクエスト毎よりはユーザのアクション毎とか、あるいはタイマーでセッションID 変えるほうが賢いかもしれない。
コメント (1)
そうですね。非同期でsessionIDを変えるのは結構勇気要りますね。PHPカンファレンス2006で小山さんが「セッションIDはl固定です」って言ってたのもそれなのかも。
あと、高木式というのは、
http://takagi-hiromitsu.jp/diary/20050427.html
の「簡単な方法」と言うやつですか？
セッション固定の場合、セッションIDを入れているCOOKIEの値を入れてしまうと、リスク高いだけだと思います。どこかのページにXSSあれば終わりなので。
で、結局は
> 1.1 悪意の第三者は、あなたのリクエストに含まれる $_GET, $_POST を、自由自在に変更する罠を作れる。
なんですが、これXSSでということですよね？XSSは確かに潰しきるのが大変難しいので・・・。
ただ、XSSあればチケット合ってもCSRFには無力なんですよね。
投稿者: itoh | 2006年09月07日 19:57