セッションアダプション脆弱性がないセッション管理が必要な理由 »

3 コメント

コメント from: 華乃美 [訪問者]
**---
華乃美>同じセッションデータベースを共有しているシステム

とありますが、徳丸さんのプログラムを見る限り、xssの方は踏み台としてのみ使用しデータベースどころかPHPすら使ってないと思います。

徳丸さんのプログラムの勘所は、攻撃者へログイン失敗で発行された「正規のセッションID」を他の人ブラウザへ「ログイン前に設定」して、その人の「ログイン後のセッションID」として使用させるという点だと思います。
故に、session_regenerate_id()を使用しないと防げないと言ってるんじゃありませんか?
2012/12/11 @ 14:27
コメント from: Yasuo Ohgaki [メンバー] メール
Yasuo Ohgakiphpinfo()で、私のパッチを当てた時にできるphp.iniのスクリーンショットもあるのでPHPは使ってるはずですよ。

徳丸さんが指摘しているのは、有効なセッションIDがある場合、session_regenerate_id(true) (セッションデータを削除するこのtrueは重要です。本文に書いていませんが、重要なプラクティスです)を呼ばないとセッションハイジャックが出来る、という点では?このセッションハイジャックはアダプション脆弱性の有無に関係なく、セッション管理手法が悪いと発生する問題です。(ご指摘の通り、PHPというインフラの問題でなく、プログラマやフレームワークの問題)

しかし、これは未初期化のIDを受け入れさせるアダプション脆弱性を使った攻撃ではありません。セキュリティ専門家以外の方にはあまり意味がなく細かい事で恐縮ですが、徳丸さんはセキュリティ専門家なので、違いますよ、と指摘しているのです。


データベースが同じ場合、ガーベッジコレクションされる前なら防御されない点について最初から異論はありません。しかし、だからといってアダプション脆弱性は直さなくてもよい脆弱性ということにはなりません。本来脆弱なセッション管理機構でなければ、ないハズのアタックパスが出来る。これを修正する事が重要ではないでしょうか?

そもそも私はこのPHPのアダプション脆弱性を「修正する為に防御できるケース」を広めてPHPに取り込もう、としてたので防御できないケースを解説していませんでした。不親切だと言われるかも知れませんが、わざわざ広める必要も無いと思っています。また、セッションIDを再生成することはアダプション脆弱性の有無に関わらず重要であると広めているいる事も理解してください。

少なくともPHPのアダプション脆弱性を直すまで、この事はあまり書きたくなかったのですが、セッションIDを更新するAPIを持たず(呼ばず)、セッションデータベースを共有しているWebシステムは、PHPに限らず結構あるのではないかな?と思っています。その場合、ドメインやパスでアプリケーションを分離しているつもりでも、Javascriptインジェクションで「他のアプリ」のセッションIDを盗めてしまいます。PHPに限った事ではない、という指摘はその通りなので他のプラットフォームでWeb開発を行っている方もセッションIDを正しく再生成してください。(PHPの様に、古いデータを削除できる仕組みであれば良いのですが。session_regenerate_id()にtrueオプションが後で足された理由はそこにあるので)

2012/12/11 @ 14:35
コメント from: Yasuo Ohgaki [メンバー] メール
Yasuo Ohgakiところで、「PHPユーザ」にとってアダプション脆弱性は過去には「重大な脅威」でしたが、現在では重大な脅威ではありません。普通にsession_regenerate_id(ture)を呼び出せば脅威ではないので当然です。

PHP本体を開発する「PHP開発者」にとってアダプション脆弱性は「重大な脅威」でしょうか?私は重大な脅威だと考えています。セッションIDというセキュリティの要を明らかに守れるケースがあるにも関わらず、既知の攻撃パスを残し、攻撃を受けたユーザには重大な影響があるかも知れない脆弱性を放置することは、PHPプロジェクトに対する信頼性を大きく損なう問題だと考えています。(少なくとも私はかなりがっかりしてました。PHPプロジェクトへの貢献もほとんどしなくなるほどに。これだけじゃ無いのですけどね。)

脆弱性が「重大な脅威」であるか、でないか、は立場が違えば異なります。脆弱性に「影響されるかどうか」「影響した場合の結果」が判断基準になるでしょう。ですから影響されないようなPHPプログラムを使っている、書いている、一般のPHPユーザが重大な脅威ではない、と評価することに異論はありません。

「セキュリティ専門家」は「PHP開発者(PHP本体を開発する開発者)」の立場を共有すべきでは?と考えるのは私だけでしょうか?
2012/12/11 @ 16:07

コメントを残す


Your email address will not be revealed on this site.

頂いたURLは表示されます。
PoorExcellent
(改行が自動で <br /> になります)
(Name, email & website)
(ユーザに、メッセージ・フォームを通じた連絡を許可します (あなたのメール・アドレスは表示されません))