session変数を追加してほしい†
- ページ: BugTrack2
- 投稿者: teanan
- 優先順位: 低
- 状態: 却下
- カテゴリー: 本体新機能
- 投稿日: 2005-05-02 (月) 10:57:49
- バージョン:
ちょっと確認: セッション関係†
基礎情報†
- PHPマニュアル: セッション処理関数(session)
- http://jp2.php.net/manual/ja/ref.session.php
- Hotwired: WebMonkey: PHPを使ってユーザーの認証と追跡をしよう
- http://hotwired.goo.ne.jp/webmonkey/2001/49/index2a.html
セキュリティ関連†
- ＠IT：Webアプリケーションに潜むセキュリティホール
- http://www.atmarkit.co.jp/fsecurity/rensai/webhole10/webhole01.html
- セッションIDが奪われることを想定してあるかどうか
- http://www.atmarkit.co.jp/fsecurity/rensai/webhole14/webhole05.html
- Session Hijack / Replay / Fixation
- SecurIT-Advisory 2005-001 URLに埋め込むIDに頼ったセッション管理方式の脆弱性(2)－ REFERER情報流出によるセッションハイジャック攻撃の問題 －
- http://securit.gtrc.aist.go.jp/SecurIT/advisory/referer-2/
- IPA:経路のセキュリティと同時にセキュアなセッション管理を - SSL/TLS でクッキーを使うときはsecure 属性を付けるのを基本とする
- http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
- "Cookie の発行処理の設計において secure フラグの利用を検討する"
- 別のシステムで認証したチケットで他の同等システムの認証をすり抜けられると危険
- セッションにホスト名などを結び付け、別IPからのセッションハイジャックを防ぐ etc
- 単一のバックエンドにセッションを保存し、複数のフロントエンドで共通に使えるか etc (主にスケーラビリティ)
汎用性関連の話題†
- [PHP-users 15876]Re: cgiモードとモジュール間でのセッション受け渡しに関して
- http://ns1.php.gr.jp/pipermail/php-users/2003-June/016406.html
- CGI版PHP + SuExecではこのような問題が出る可能性があるという話。
- RPM で PHP: PHPのビルドをしてみよう
- http://wiki.poyo.jp/read/Writing/misc/linux/rpm_de_php/03.Build%20PHP
- "セッションなど一部の機能はこの種類の(共有ライブラリモジュール版)SAPIでなければ使えません．" (= CGI版では動かないように取れるが、詳細は不明)
その他†
- p0t: PHPのセッションID (が、重複する可能性はあるのか)
- http://p0t.jp/mt/archives/2004/11/phpid.html
- 海は海、風は風 dozo.rgr.jp: msession - PHP高速session(セッション)管理サーバ
- http://dozo.rgr.jp/log/eid178.html
- http://www.mohawksoft.com/
- WEBプログラミング＠2ch掲示板: 【PHP】セッションについて語ろう！【PHP】
- http://pc8.2ch.net/test/read.cgi/php/1064399467/l50
- スラッシュドット ジャパン | Movable Typeに不正アクセスを許す脆弱性
- http://slashdot.jp/article.pl?sid=05/05/13/210201
- http://www.movabletype.jp/archives/2005/05/post_11.html
- "Movable Typeのセッション管理で使われるCookieの値に、ハッシュ化されたユーザーアカウント情報が含まれており、以下の条件を全て満たした場合に、第三者による不正なアクセスが可能になります。"
- http://tdiary.seesaa.net/article/3600409.html
- "この問題は一言で言えば、セッション管理に利用しているCookie値にユーザー/パスワード情報を含んでしまっている、つまり所謂「セッションID」管理を行っていない、という点です。"
メッセージ†
PukiWiki Plus!で採用されているセッション変数の対応を希望します。
// for SESSION Variables
if (!($_REQUEST['plugin'] != 'attach' && $_REQUEST['pcmd'] != 'open')) {
if (ini_get('session.auto_start') != 1) {
session_name('pukiwiki');
session_start();
}
}
～～～～～
$_SESSION = input_filter($_SESSION);
～～～～～
$session = & $_SESSION;
- official:自作プラグイン/footprint.inc.phpのようなもの*1を作ろうとした場合に本体(スキン)に手を付けなくてもいいようにしたいです。 -- teanan
- また、official:config.inc.phpやBugTrack/714など、セッションを使ったほうが良さそうなものが出てきているためです。 -- teanan
- あとはやっぱり・・・Basic認証でAuthorizationヘッダが毎回流れるのは気持ち悪いですから、将来的には、一回認証がとおったらあとはsessionで処理、みたいにしたほうがいいのではないでしょうか*2。 -- teanan
- Basic認証については永遠にそういうものですので、セッションを利用した認証(回避)機構とは別の技術として捕らえてください :) -- henoheno
- 折角第三者として評価できるのですから、本当に上記で適切であるのかをこちらで検討する必要があります。セッションハイジャックなどの既知のセキュリティを本当にケアするのか、またプラグインに安易な脆弱性をもたらさないのか等々。他のPHP実装(GPLの)を見てもいいかもしれませんよ -- henoheno
- 既存の$get, $post, $vars にしているのと同じ対応が行われているようですが、なぜ $vars でなく $_REQUEST を使っているのか、なぜ attach プラグインの特定の状態だけ例外処理をしているのか(安定していないのか/他にはないのか)、事故を防ぐためにベースシステムとして何をしているのか(何か無くはないか)、ユーザー認証を組み込む事を考えて $_SESSION以下の特定の名前(配列)を確保して、プラグインに引き渡す前にその配列を除去しておくのはどうか等、いろいろ思うのですが情報がありません。 -- henoheno
- 単純に「セッション変数を追加して欲しい」という単発の要望だけですと、BugTrack/709における「ユーザーパスワードもmd5化して欲しい」という要望のようなものと同じように受け止めざるを得ません。目先の視点しかないコードや、誰かが書いたものを未検証のまま突っ込んだコードは既にPukiWikiの中に既に沢山あるので、それだけならばご勘弁願いたいと思います。やっとセッションの話が(ここで)始まったのですから、もう少し先に進めませんか? :) -- henoheno
- attach については見つけました。Plus! の plus:BugTrack/3ですね。回避策であるように見受けます。 -- henoheno
- セッションは、GET/POSTと同等ではなくて、より危険なものである(簡単な実装でも良い場合と、そうでない場合がある)という視点と、そのための工夫(ケア)が欲しいです。CSRFなど参照。 -- henoheno
- さて、パンドラの箱を開けてしまったようです (^^; *3。もちろん、上に書いたコードをそのまま突っ込んでほしいとか、そういうことではなくて、検証が必要であることは十分認識しております。検索かけてもセッション対応についてはあまり語られているところがありませんので、立てさせていただきました。 :) -- teanan
- ちなみに、上記コードの位置がlib/init.phpの最初の方に書かれていますので、 $varsが確定しておらず、$_REQUESTを使っているように見受けられます。 -- teanan
- ええ、今まで空けるのを避けていた(中途半端な実装は返って危険な)パンドラの箱です :) セッションを破棄するタイムアウト秒数や、セッションの保存/破棄の処理についてもじっくり検討&デバッグしなきゃですねー (本当に大変だと思いますので、重要度というか進行度は低が良いと思います・・・) -- henoheno
- 本BugTrackの先頭に各種リンクを追加。 -- henoheno
- なんか招待状？がとどいたようなので (^^; そもそも Wiki なのですから、セッションで認証関係を作成しようとするなら上記パッチはあてないほうがいいでしょう。あくまでも上記パッチのセッション、クッキーは公開情報を補助する役割として使う方向で考えるためのものです。クッキーを使用しているところでは Vote プラグインのパッチなどがあります。 -- みこ
- その上で認証情報までも考えるのであれば、がんばってください (^^) それはまさしくパンドラの箱です。*4 -- みこ
- おそらく、そのときには認証情報のプラグイン（もしかすると本体機能？）も含めてオフィシャルで作成したほうがいいでしょう。そして、その参考になるのは他のCMS系ソフトウェア(xoopsとか)になっていくかとおもいます。 -- みこ
- お疲れ様です*5。私がセッション変数を追加してできると考えているのは完璧な認証ではなく、現状の認証と同じくらいのものです。それは、例えば、一度凍結のパスワードを入力すると、そのウィンドウを閉じるまではパスワード入力が免除される、というような使い方ができないだろうか、と考えています。 -- teanan
- それこそまさしくセッションによる認証の回避、というパンドラの箱なのです。箱から世界中に飛び出るものはセッションIDという名前の認証回避チケットです。一度蓋を開ければ最後、様々な側面から外に飛び出そうとします。それを押さえ込むために必要な背景情報は多様です。上に追加した各種リンクが入り口になるかと思います (^^; -- henoheno
- なるほど*6。 -- teanan
- いえ、まだ手をつけちゃいないでしょう (^^; ともかくこのページを足がかりにでも、色々調べ回ってからでも遅くないですよ。 -- henoheno
- しっかり勉強します。ありがとうございます :) -- teanan
- いつもすいません。コメントありがとうございます。これで(このページで)上記実装のスタンスが明確になったと思います。補助的な用途といえば official:自作プラグイン/footprint.inc.php は面白いですね。(補助的な用途のために)session_start() をどこに入れるべきか、といった話題があります。 -- henoheno
セッションの下地†
- ・・・で、認証機能に手を出すかは別として、このような下地を作っておきたい、というのがこのBugTrackの趣旨なんですが (^^; -- teanan
- まぁどちらにしてもセッションハイジャックや CSRF を含め、セッションには 100% 認証する方法はないので (^^; *7 結局のところ程度の問題ではあるんですけどね。 -- みこ
- 結局のところ、認証の場合はPukiWikiを使用している人のセキュリティのレベルをどこにおくかになります。カジュアルな突破だけを防御するのか、それとももうすこし上のレベルなのか・・・10円玉を盗まれないために巨大な金庫つかってもしょうがないですしね :p -- みこ
- そういういみでは、_COOKIE, _SESSION は自由に開発者に使わせてみてもいいんじゃないですか？もともと本家で対応していない理由はクロスブラウザ対応やサーバ(自己/プロパイダ)やPHPのモード(CGI/SAPI)と多岐にわたってメンテするのを回避している理由もありましたし。 -- みこ
- どのような下地か、という点につきましては、上記のやりとりの中で「補助的な利用のためのもの」であるということは明確かと思います。それを踏まえて実装するならば、パッと思いつくだけでも以下のようなチェックポイントがあると思います。 -- henoheno
- あくまでも補助的なものであると注意書き(コメント、名称への盛り込み等)すること
- 設定で強制的にoffにできるようにする事 (PKWK_DISABLE_AUX_SESSION 等)
- https + attach(open) の時の動作をデバッグし、もう一歩、現象と理由を突き止めここに明文化すること(進展があればPlus!ののplus:BugTrack/3にも追記)
- cgi SAPIでの動作確認、確認できたのであれば php_sapi_name() でSAPIのチェックを入れるかどうか検討し、実装すること(というかcgi SAPI対応全般をクリアにすること。SuExec等) -- BugTrack/63
- クッキー(セッションでも使う)とセッションに対する調査、動作確認
- SSL利用時にクッキーにsecureオプションを入れる場合の設定方法に対する検討をすること (というかSSL対応全般をクリアにすること。port443指定時の動作等)
- SAPIによっては動かないようなものについては悩ましいですね (^^; -- henoheno
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
