【PHP】セッションについて語ろう！【PHP】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/09/24 19:31ID:SnRvXmpIブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん
0348nobodyさん
2006/05/17(水) 22:20:27ID:???PHPじゃないとセッションつかえないと思ってる香具師の数→
0349nobodyさん
2006/05/19(金) 19:09:45ID:???を入れるという実装って普通しますか?
IPアドレスなんて変わることが多いからそんなことしないかと思っていたの
ですが
0350nobodyさん
2006/05/19(金) 19:18:14ID:???再利用しているところが多いし、同じIPアドレスを使ってるPCだって結構ある。
0351nobodyさん
2006/05/19(金) 19:22:28ID:???あと同じIPアドレスを使っているというのは、NATのことでしょうか?
それくらいしか思いつかなかった。
0352nobodyさん
2006/05/19(金) 19:22:52ID:oMRPSSzCSSLを使わないでデータを安全にやりとりする方法ってありますか？
JavaScriptとPHPでRSA暗号使ってやりとりしようと思ったのですが、
もっとスマートで対応するブラウザが多い方法ってありますか？
どなたかご存じの方教えていただけると嬉しいです。
0354nobodyさん
2006/05/19(金) 21:39:58ID:???RSAで簡単にやるのがSSLなんだけどね。わざわざSSL使わずにどうにかするほうが面倒で難しい。
0355352
2006/05/19(金) 21:59:02ID:???きょうびJavaScriptに対応しないブラウザよりSSLに対応しないブラウザの歩が珍しいかな。。orz
0357nobodyさん
2006/05/19(金) 22:52:14ID:???作る「もの」によるかな？
シビアなチェックが要求されるものならＩＰチェックには頼らないが、セッションハイジャックされたところで
そんなに大したもんでもない程度のものなら、ＩＰチェックすらしてないw
ＩＰチェック程度を実装する事もある
みたいな。
0358nobodyさん
2006/05/19(金) 23:02:07ID:???>>357の書く通りそれに頼ってしまうのは間違いだけど、セッションハイジャックを防ぐ方法としては比較的一般的に使われてる手法。
http://www.google.com/search?num=50&hl=ja&q=%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%8F%E3%82%A4%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AF+%EF%BC%A9%EF%BC%B0+%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
0359nobodyさん
2006/05/20(土) 10:09:53ID:???実際にどんな場合に利用してます?
個人的には無意味かなぁと思っていたのですが
保険的に利用する場合ってIPチェックして違った場合、ログを残すとかそんな感じですか?
0361nobodyさん
2006/05/21(日) 17:21:39ID:???ログイン後、操作をしない（通信をしない）時間が数分続くと、
勝手にログアウトしてしまいます。
ブラウザを閉じたわけでもないですし、session.gc_maxlifetimeは1440あります。
明示的にログアウト処理をしない限りログイン状態が続くようにしたいのですが、
どこの設定をいじれば良いのでしょうか・・・。
0363nobodyさん
2006/05/21(日) 22:09:56ID:???そう。あんまり意味無い。
でも、全く意味が無いってわけでも無い。
つまり、それ程シビアなチェックを必要とされないものなら、この程度でも良いかもね程度に考えておけばと。
とにかくだな。
あくまで１つの手段としてこんなのもあるよって話しなので、気に入らないのなら別の方法を実装すれば良いだけの話。
頭で色々考えるのも良いが、まずは先に物を作って実際に動かした方が余程勉強になるかと。
0364nobodyさん
2006/05/21(日) 22:13:15ID:???↓書き方悪かったな。
まずは先に物を作って実際に動かした方が余程勉強になるかと。
↑っていうのは、自分でセッションを使う簡易的なサイトでも作ってみて、それを自分でセッションハイジャック出来るかどうか試してみたら良いよって感じかな。
ハイジャックできてしまったら、それを防ぐにはどうすれば良いかを考えて改良し、また自分でハイジャックを試す。
そんな感じで完成度を上げていくと良いかなって思う。
0365nobodyさん
2006/05/22(月) 10:41:52ID:???他との併用でしょ。セコムのシール貼ってるだけに近い。実際の防犯にはちゃんと対策が必要。
元々HTTPはステートレス。
セッションを使って無理矢理ステートフルに見せかけてるだけ。
NATとかkeepalive切ってる場合も有るから、鯖でがんばっても無理が有ることが多い。
0366361
2006/05/22(月) 19:04:58ID:???0367nobodyさん
2006/05/23(火) 11:47:58ID:8StU5eTgセッションIDでログイン状態を判断するっていうのは
最初ログインしたときに
サーバ側のDBなどでセッションIDとログインしたユーザを
紐づけて管理するってことですよね？
それとは別に、ログイン時に
ログインIDとパスワードをクッキーに書き込んで
認証が必要なページでは毎回クッキーで判定しようと思うのですが
どんなリスクがあるのでしょう？
もちろんパスワードはMD5などの不可逆な変換を行い
クッキーもSSLのページのみで受け渡しします。
0368nobodyさん
2006/05/23(火) 14:17:16ID:???セッションIDなら一度ログアウトしてしまえば大丈夫だけど、
それだとログアウトしてもクッキーさえ持っていれば再度ログインできる。
0369367
2006/05/23(火) 15:03:01ID:???すみません、クッキーと書きましたが
ブラウザを閉じたら消えるやつで
いわゆるセッションと同じようなもののことでした。
でもブラウザの実装によっては
一時的でもクライアントに保存されるため
リスクが高いということでしょうか。
0370nobodyさん
2006/05/23(火) 20:46:03ID:???強いて言うなら、その方法だと、XSSでクッキーを盗まれたときに、
パスワードを変更しない限り、その情報が使えてしまうけど、
XSS心配したらセッションも使えないし、
リスクという点では大差ないと思う。
セッションには、
・PHPに初めから実装されていて、手軽に使える
・ブラウザを閉じるまでは、以前の情報を継続して使える
という利点があるけど、単にログイン状態を保存しておくだけだったら、>>367の方法でも良いんじゃないかな。
0371nobodyさん
2006/05/23(火) 23:07:03ID:???永続的なパスワードは一時的であれクッキーに保存するべきではない。
XSSでコッソリ取られた日には目も当てられない。
0373nobodyさん
2006/05/24(水) 15:21:01ID:8TTcDRX+10秒たってもセッションがタイムアウトしません。
なぜなんでしょうか？
環境はIIS5.0 / php5.0.3 です。
php.iniの値はこのようになってます。
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 10 10
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path no value no value
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0
0374368
2006/05/24(水) 15:58:59ID:???よくよめ。
>>371
確かに。XSSの事忘れてた。。
つーか、わざわざパス記録すんなよ。メリット無いだろ。
セッションならXSSで取られてもIPで再度チェックすれば大体防げる。
0375nobodyさん
2006/05/24(水) 17:26:05ID:???IPが変わる環境のクライアントは切り捨ててるの？
0376368
2006/05/24(水) 17:35:05ID:???ホスト名が取得出来るんだったら、末尾から数えて二つめのドットまでマッチングとかな。
自分はもうちょっと複雑に可変範囲決定してるが、方法はいくらでもあると思われ。
0377nobodyさん
2006/05/24(水) 18:12:48ID:???携帯サイトのことを言っているのならIPチェック自体がナンセンス
通常のネットワーク環境を前提にしているとしたらIPが変わった時点でセッションが切れて当然
0378nobodyさん
2006/05/24(水) 18:15:10ID:???苦情来ない？実際自分も不便だと思うからneverにしてる。
クリティカルなやりとりに入る場合は再入力させてるけど。
0380386
2006/05/24(水) 18:21:45ID:???いや、so-net.netとか。.ne.jpとかは末尾ドット二つじゃ足りなくて三つ遡ってマッチしなきゃならんが。
ヤフやらはてなやらアマゾンはそんな実装だな。>>378
関係ないけど、ヤフの会員登録(HTTP)は生でパス流してる。
0382386
2006/05/24(水) 18:23:41ID:???チャレンジレスポンスだけど、途中に割り込まれたらっつーのもあるし、今時HTTPって。。
0383nobodyさん
2006/05/24(水) 18:27:30ID:???所謂セッション管理についてのスレだから一行動としてのセッションで捉えなくて良いと思ふ、
つか、今時そんな短時間でログアウトさせてる方が珍しい、金融機関除いて
0385nobodyさん
2006/05/24(水) 18:43:29ID:???セキュリティ的には短い方が望ましいが、長い方が明らかに便利。
あ、良いこと考えた。
0386386
2006/05/24(水) 18:46:32ID:???直接PCを操作される場合のリスクを考えてﾅｶﾀ。何か良い方法無いですか？
0388nobodyさん
2006/05/24(水) 23:16:27ID:vQsxJJUNちゃんとセションファイルに書きこまれないときがあります。
具体的には
画面AでA.php?hoge=aで
$_GET['hoge']から'a'を取得し
$_SESSION['hoge']="a"といれ、
画面Bに行く。
このとき$_SESSION['hoge']はaとなっている。
ブラウザの戻るでAにもどり
URLにA.php?hoge=bと入力しエンターキー。
（$_SESSION['hoge']="b"となっているはず。）
画面Bに行く。
するとこのとき、
$_SESSION['a']の中には
aが入っていて、こちらの期待する値（b)になりません。
画面Aに戻り
URLにA?hoge=bと入力しエンターキーを押して
F5を押すと
$_SESSION['a']には期待値（b)が入っています。
どうしてこのようになるのか分かりません。
どなたか教えていただけないでしょうか。
また期待値を得るためにはどうしたら良いでしょうか？
0390388
2006/05/25(木) 00:15:44ID:wZM3F4wk↓こんな感じで書いてます。よろしくおねがいします。
top.php
<?
session_start();
$_SESSION['name'] = $_GET['name'};
print($_SESSION['name']);//ここでは表示される値は毎回更新されている
:
:
:
//入力へのリンク
print ("<a href ='input.php'>リンク</a>");
?>
input.php
<?
session_start();
print($_SESSION['name']);//←ここで値が更新されず、前の値がでることがある。
：
：
：
?>
0391nobodyさん
2006/05/25(木) 00:57:00ID:???別に問題なく動作したが。。。
動作がおかしいときは、ブラウザがキャッシュから表示してるのだと思う。
session_cache_limiterを弄ったりしてなければ、あまり起きないはずだが、
どうしても以前の情報を表示したくないのなら、
input.phpにランダムなクエリーをつけるか、POSTでアクセスするかかな。
0392nobodyさん
2006/05/25(木) 00:59:45ID:???それから、本当にキャッシュから表示してるのか確かめたければ、
input.phpに現在時刻の表示とかを入れると良いよ。
0393388
2006/05/25(木) 08:20:59ID:???どうもありがとうございます。
>input.phpに現在時刻の表示とかを入れると良いよ。
私もこれは試したのですが、
時刻は現在時刻を表示してるのですが
$_SESSIONの値は変わらずといった状態でした。
設定をもう一度見直してみます。
お世話になりました。
0394nobodyさん
2006/05/25(木) 08:36:41ID:???もしかしたらここの主旨とずれていたかもしれません。
質問用スレッドにて質問させて頂きます。
どうもすみませんでした
0395nobodyさん
2006/05/25(木) 16:05:42ID:???みなさんは自作されてるのでしょうか？
PEAR::Authを使ってるのですが
このスレを読んで心配になりました。
PEAR::Authのログインしたときのクッキーの送受信を
セキュアな接続のときに限定することはできないですよね？
0396nobodyさん
2006/05/26(金) 22:50:44ID:???ブラウザのキャッシュとは限らんよ。
ブラウザに到達するまでに色んな所でキャッシュする装置が挟まってることは良くある。
ファイヤーウォールとか、キャッシュサーバとか、プロクシとか。
0398nobodyさん
2006/05/28(日) 10:58:28ID:???ずっとログイン状態が続いてるよね。
あれってどうやって実現してるんだろう？（＆セキュリティ的に大丈夫か？？）
0399nobodyさん
2006/05/28(日) 11:25:26ID:???一時期流出してたしどこか有るでしょ。
0400nobodyさん
2006/05/28(日) 14:17:29ID:???たしかにネットカフェとかでmixiにログインして
そのままログアウトし忘れてそのまま帰っちゃうヤツとか多そうで危ないな。
0401nobodyさん
2006/05/28(日) 22:38:46ID:???ネカフェでミクシなんてあり得ないでしょ。
個人情報漏れまくりだ。
0402nobodyさん
2006/05/28(日) 23:06:01ID:???だってPCに詳しくない女性とかライトユーザが超多いから。
0403nobodyさん
2006/05/28(日) 23:26:26ID:???「次回から自動的にログイン」のチェックを入れてログインしないと、そんな事にはならないでしょ。
当たり前の実装が普通にしてあったぞ。
0404nobodyさん
2006/05/29(月) 00:00:21ID:???ハァ？？
「次回から自動的にログイン」にチェックを入れなくても
ログインが継続される仕様になってるから>>398のような疑問が出るわけだが。
今、俺が実際に実験してみたところ、「次回から自動的にログイン」をチェックせずに
ログインした状態でパソコンを再起動してもログインが継続されていた。
すなわちネカフェなどでの使用は超危険。
0405403
2006/05/29(月) 00:11:26ID:???http://mixi.jp/help.pl#10dこうも書いてあるし、バグレポ送ったらｲｲﾝｼﾞｬﾏｲｶ。
正直、そんなバグあったら界隈で大騒ぎされているとおもうが。。
0406nobodyさん
2006/05/29(月) 00:34:08ID:???チェック無し
→有効期限無し＝セッション限り
チェック有り
→有効期限2011年5月28日
再起動後もログインが継続されるとすると、ブラウザ側に問題があるが、
そういうブラウザがあるなら気をつけた方が良いな。
0407406
2006/05/29(月) 00:35:03ID:???0408nobodyさん
2006/05/29(月) 00:40:42ID:???現在進行形で祭り中
資料４（最新版） http://myon.blog.shinobi.jp/Entry/4/
0409nobodyさん
2006/05/29(月) 08:11:43ID:???便利だからって理由で「次回から自動的にログイン」にチェック入れてるでしょ。例え不特定多数が使うPCでも。
0410nobodyさん
2006/05/29(月) 10:09:07ID:???0411nobodyさん
2006/05/29(月) 19:46:17ID:???俺もIE6なんだが、、、バグだろうか？？
「自動ログイン」にチェック入れなくても、
ブラウザ閉じようがPC再起動しようが、ログイン状態が継続されてるよorz
みんなそうだと思ってたら、俺だけなのか・・・
0413nobodyさん
2006/05/29(月) 21:43:17ID:???「自動ログイン」のチェック無しでログインすると
「BF_SETTING」って項目とデータ７行。
「自動ログインあり」だと、「BF_SETTING」に加えて、
「BF_SESSION」と「BF_STAMP」ってのが追加されるみたいだね。
0417nobodyさん
2006/05/30(火) 08:23:17ID:???ログアウトしてるのに、クッキー消したら認証突破できるんじゃね？
0418nobodyさん
2006/05/30(火) 09:43:25ID:???ん？ 何を見当違いのこと言ってんだ？
「ログアウト判定のクッキー喰わせてる」って、何を根拠に言ってんだか・・・
0421nobodyさん
2006/05/30(火) 20:39:32ID:???0422nobodyさん
2006/05/30(火) 22:36:56ID:???0423nobodyさん
2006/05/31(水) 12:02:25ID:???0424nobodyさん
2006/05/31(水) 12:57:55ID:???0425nobodyさん
2006/05/31(水) 14:17:24ID:???0426nobodyさん
2006/05/31(水) 15:24:58ID:???0427nobodyさん
2006/05/31(水) 16:23:12ID:???0428nobodyさん
2006/05/31(水) 22:07:23ID:???（ ・ω・）
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗ
0429nobodyさん
2006/07/01(土) 04:01:59ID:???なおかつ、結果と、ソート状態、何ページ目は、他のページを開いても戻って来た時保持したい。
いちいちGETやPOSTからsqlクエリを毎度生成するのはめんどくさ過ぎるから、
検索条件が投げられた時点でsql文をつくって、まるごとセッションにぶち込む。URLにGETに含めるのは現在何ページ目、ソート対象、ソート方向、表示件数だけにしてしおうかと思ってるけど、こういうのはありなのかな？
0430nobodyさん
2006/07/01(土) 08:44:44ID:???2枚ウインドウを開いて違う検索しようとしたら、一方の検索条件が両方に適用されて
まともに使えないサイトがあった。
ウインドウ毎に区別されるようにしてね
0431nobodyさん
2006/07/01(土) 10:15:18ID:???暫く前の@type(転職サイト)がそう。最悪の使い心地だった。
今は他社同種のと同程度には改良されてるけど。
0432nobodyさん
2006/07/01(土) 16:27:38ID:???なるほど。そういう弊害もあるのか。
いい事聞いた。ありがと。
やはり自分で想定できることってかぎられてるんだなと。
だったら新たに窓を開いたら窓ごとに別のセッションネームをつけてsql文を格納すればよさそうですね。
表示部分の関数がsql文をわたす設計で、結果からのリンクはすべてget渡しなんで、関数内でsql文を生成するとおそろしく面倒なことになりそうだ。
0433432
2006/07/04(火) 11:39:42ID:???でもこれが完成したらすげー楽になるかも。
0434nobodyさん
2006/07/04(火) 19:13:45ID:???0435432
2006/07/04(火) 22:41:35ID:???全ての入力を統合するのは、やっぱり無理っぽいかも。もう限界に近づいて来たというのに、ひどい状態になってしまったorz
コメントアウトだらけで自分でもわけわからん、
0436nobodyさん
2006/07/05(水) 03:10:54ID:???0437nobodyさん
2006/07/05(水) 08:45:55ID:???0438nobodyさん
2006/07/11(火) 09:18:37ID:3lRF8+baアイドル状態が続くとセッションが切れてしまうのを
回避する方法を考えています。
・ サーバでのセッション保持期間を長くする
・ セッションでなくクッキーなどによる管理に変更する
これ以外になにかいい方法があったら教えてください
0439nobodyさん
2006/07/11(火) 09:21:58ID:???普通に考えたらクッキーだよな。
面白い方法だと、例えば幅無しのフレーム作って、そっちのフレームの中を<META>タグで
何秒か置きに更新させて、その中でセッションを更新させてやるとか。
↑まぁこんな事やる意味が分からないけどね(w
0440438
2006/07/11(火) 13:01:04ID:???フレームはちょっと考えてました。
あとはFlashとかで定期的に通信するとか。
でも最後の手段と考えてます。
クッキーの場合は、パスワードも暗号化したクッキーとして
クライアントに返して
毎回そのクッキーで認証するって感じでしょうか？
0442nobodyさん
2006/07/11(火) 14:59:31ID:???クッキーやワンタイムパスワードは総当たり攻撃で突破される。
そもそもHTTPなんてステートレスなプロトコルでセッションが切れるのは仕様。
SOAPとかCORBAとか他のプロトコル使ったら？
0443nobodyさん
2006/07/12(水) 02:04:51ID:???＞アイドル状態が続くとセッションが切れてしまう
session.cookie_lifetimeが「0」なら、
ブラウザを閉じない限りセッションも切れないだろ。
しかもそれってデフォルト設定だし。
0445nobodyさん
2006/07/12(水) 13:24:04ID:???削除されないよ。
実際自分のとこで動かしてるスクリプトは、
一度ログインしたらブラウザ閉じるまで何日でもログイン状態（＝セッション）続いてるし。
0446nobodyさん
2006/07/12(水) 13:41:31ID:???何日もログインできるってメモリリークしまくりに気づいてないだけじゃ？
0447nobodyさん
2006/07/12(水) 15:45:38ID:???お前が>>442で書いてることは間違い。
セッションはファイル（またはDB）で管理されるものであり、
メモリとは直接関係ない。したがってメモリリークなど起きない。
悔しかったら具体的にどういう根拠でメモリリークが発生するか書いてみたまえｗ
■ このスレッドは過去ログ倉庫に格納されています