[debian-users:40139] Re: CGI設置についてのご質問解決しま した。

[NOGAMI Daisuke <me@xxxxxxxx>]

野上です。

Thu, 8 Apr 2004 01:19:42 +0900 に 佐藤　義博 <ysatoh@xxxxxxxxxxxx> さんから
きた「 [debian-users:40138] Re: CGI設置についてのご質問解決しま した。 」 
<20040407230415.ABDD.YSATOH@xxxxxxxxxxxx> への返事です。

> http://www.example.com/sub.php?PHPSESSIONID=xxxxxxxx
(snip)
> ・上記の様なクッキーを使わない場合、PHPのセッション情報も含め
> た形でReferer情報を取得することができる。
> ※ただし偽装されている可能性もある

  PHPはそこまで使い込んでないので少々不正確な表現になるかもしれないのですが、
セッション情報を使う場合にはPOSTメソッドで送ると思われるので、おそらく
Referrerにはsession-idは見えないでしょう。
  この点に関しては問題ないと思います。

> 先ほどの飛躍した部分は別として、入り口からの呼び出しだけって
> どうやって判断できるのでしょうか？PHPのセッションを使っても
> サーバ内に有効なセッションIDが存在していれば…
> http://www.example.com/sub.php?PHPSESSIONID=xxxxxxxx
> (xxxxxxxxは有効なセッションID)のようにすると入り口を飛ばして
> 入れてしまうし…。

  このような手法はphpのセッション管理に関するドキュメントにも「セッションハ
イジャック」として挙げられていますね。

https://www.stackasterisk.jp/tech/php/php03_06.jsp
| ここで言うセッションハイジャックとは、セッションIDを直接指定してアクセスする
| 方法です。クラッカーは存在するであろうセッションIDを予想する／あてずっぽうで
| 指定する、もしくは通信経路の途中で傍受する、ブラウザのキャッシュやクッキーな
| どを見る、などの方法でセッションIDを指定します。

  当てずっぽうですから当てられる可能性は低いですから実用上は問題ないですが、
100%確実にセッションを追えるとは言い切れません。しかし、どうもjoeさんはこの
レベルで確認出来れば確実な入り口チェックであると見なしているようにしか思えま
せん。たしかに、実用上必要十分な精度は確保出来るでしょうが、「100%確実」と言
い切れる仕組みではないと思います。

  もし、それ以上の精度を確保出来る仕組みがあるのだとしたら後学のためお教え頂
けるとうれしいです。

# 極論すれば、ブラウザを使わず手で通信すれば原理的にはどんな変数もいじれて、
# phpなりcgiなりに怪しいデータを送り込むことができます。その場合、どんな
# cookie管理やsession管理をしても無駄でしょう。
# 自分でjavaなりなんなりで専用プロトコルを使う専用クライアントを作れば回避出
# 来るとは思いますが。

# また、httpsであっても、stoneなどのリピーターをかませれば手でhttpを話せます。
# 例
# $ apt-get install stone-ssl (sarge以降はstoneで良い)
# $ stone example.com:443/ssl 10080
# $ telnet localhost 10080
# この例ではlocalhostの10080経由でhttps://example.comにアクセス出来ますし…