- 締切済み
セッションハイジャックについて
とあるサイトの話ですが、一度ログインすると（ログイン画面のみSSL） ログオフしない限りログインを維持しています。 前回閲覧から数日経っていようと。 確認したわけではないのではっきりとはわからないですが、恐らく セッションタイムアウトが設定されていないのかなと思っています。 以下のことを試してみました。 (1) Aのパソコン、Bのパソコンそれぞれそのサイトにログイン。 そのままブラウザを閉じる。 (2) Aのパソコンでログインパスワードを変更した。 (3) もう一度A,Bみにいくと当然のごとくログイン状態のままだった。 (4) 双方とも閲覧した（普通に閲覧可能だった）あとにブラウザを閉じ、 また開くとログオフ状態になっていた。 このサイトの脆弱性、及び危険性はどの程度なのでしょうか？
- blackaces
- お礼率85% (34/40)
- ネットワーク
- 回答数4
- ありがとう数4
- みんなの回答 （4）
- 専門家の回答
みんなの回答
- koi1234
- ベストアンサー率53% (1866/3459)
#2です >ログインした暦のある他のPCでそのままログインできていたのは >どういう理屈になるのでしょうか？ ってことは最小化ではなくブラウザは 再起動してるということでいいんでしょうか？ 通常であれば考えにくい状況だと思いますが 何か思い違い（操作ミス）とかって可能性ないですか？ 細かく確認したわけでもないですしブラウザの挙動によるものかもわかりませんし どこのサイトの話かも分からないのであくまで想像になってしまいますので 何とも言えません
- SaKaKashi
- ベストアンサー率24% (755/3136)
大半のサイトはブラウザ終了時までしょうね。 そうじゃないサイトはcookieを使ってますし、cookieを使っていてもそれなりに有効期限を設定しているところが多いです。
- koi1234
- ベストアンサー率53% (1866/3459)
>(1) Aのパソコン、Bのパソコンそれぞれそのサイトにログイン。 > そのままブラウザを閉じる。 ここでの閉じる というのはブラウザ終了の意味・ 最小化の意味 どちらでしょうか？ ブラウザ閉じてればセッションが維持され続けるということはありえないはずです （TCP/IPのプロトコル上セッションが終了します） 再起動時にセッションが維持されているように見える（思える）だけで その際に再認証されているだけだと思います ブラウザ閉じれば危険はありません ※ 最小化であれば維持されたままになります 共有PCなどはそういったことがあり得るので ブラウザをいったん終了してくださいといった注意書きなどが Q&A等にも掲載されているはずです
補足
なるほどありがとうございます。 詳しくもないのに中途半端な内容で申しわけありませんでした。 確かにその通りでした； しかし再認証ということであれば、別PCでログインパスワードを変えている のに、ログインした暦のある他のPCでそのままログインできていたのは どういう理屈になるのでしょうか？
- SaKaKashi
- ベストアンサー率24% (755/3136)
ログインしてブラウザが終了するまではＯＫなのでしょう。 異なるＰＣでログイン不可のチェックはしてないのです。 二重ログインを厳密にチェックすると、ログイン中にパソコンが壊れたら永遠にログインできないことになりかねず、解除は人手に頼ることになり、手間暇がかかります。 本人確認の問題もありますし。 特別に危険なことはないですが、ログアウトするようにするか、ブラウザを終了しましょう。
お礼
すいません、自分が一番知りたかったのは二重ログインではなくて、 セッションがいつまでも保持されていること。 そのお陰でパスワードを変更したにも関わらず旧パスワードで ログインしていた状態のままでログインが維持されてしまっていることです。 セッションがいつまで経っても保持されているということは セッションハイジャックができる機会も増えるのではという危惧です。
関連するQ&A
- SSL2.0と3.0について
SSLには2.0と3.0があり、２．０はセキュリティに脆弱性があるため3.0で改善されたと聴きました。 SSL３．０が使われていて２．０が使われていないサイトでは、ブラウザの設定で２．０をオフにした方がよいのでしょうか？ また、このサイトはどのSSLが使われているか分かる方法はあるのでしょうか？ よろしくお願いします。
- ベストアンサー
- ネットワーク
- セッション脆弱性を克服するには？
またお世話になります。 いつも的確な回答を頂いて助かっていますm( __ __ )m 【仕様】 ・ ログイン認証ページのみ SSL で、それ以外のページは 【非SSL】 です。 ・ ログイン認証時にセッションIDをクライアントのクッキーに保存し、サーバー側では MySQL にセッションIDとログイン情報を保持します。 ・ 認証以降のページでは、クライアントから送信されてくるクッキーセッションIDを元に MySQL のデータと照合し、ユーザーのログイン状態を維持します。 ・ 言語は PHP を使っています。 よくあるセッション管理サイトだと思います。 そして、セッションIDさえ盗まれなければセキュリティとして問題無いと考えています。逆に言うとセッションIDが盗まれると極端に弱いと思います。 【私の考える脆弱性】 ・ ログインページ以外が 非SSL ということから、セッションIDの盗聴が可能かと思います。 ・ 普通に使用していても悪意あるサーバーを経由したらトレースされて簡単にセッションIDが抜かれると思います。 ・ ログインした状態のユーザーが怪しいリンクをクリックしてクロスサイト攻撃でクッキーを抜かれる可能性もあります。 質問は、なぜ、こういった多くの問題が予測できるのに この「教えて！Goo」の認証もログインページはSSLですが、それ以外は非SSLです。といった具合に多くのサイトがこのような認証方式を取っているのか？ もう一つ質問は、私は先に上げたような脆弱性を防ぐ方法がわからないのですが、何か画期的な方法でセッションハイジャックなどを防御しているのでしょうか？ もしくはセッションIDが盗まれてもそのセッションIDでのアクセスを無毒化するような方法があるのでしょうか？ 以上です。 よろしくお願いします。
- ベストアンサー
- ネットワーク
- Cookieを用いてのセッション管理
以前も問い合わせさせていただいた件なのですが、 未だ解決していないので、再掲させていただきます。 やりたいことは、 個人認証のページを作り、ログオフ後、ブラウザの戻るボタンを押しても、 ログイン中となるのを避けたい。 以下のような感じで、cookieを使って実現しようとしているのですが、 ログオフ時にcookieの削除は、うまくいったのですが、 ブラウザの戻るボタンでログイン中のページに戻ると、 $ENV{'HTTP_COOKIE'}の中身を見ると、実際にはCookieは削除されているにも関わらず、 Cookieの情報がよみこまれているため、ログイン中となってしまいます。 何か基本的なやり方を間違っているような気がします。 どなたかご教授願います。 ↓a1.cgi（ログイン画面）-------------- ： （ID、パスワード認証後） #Cookie書き込み print "Content-type: text/html\n"; print "Set-Cookie: NAME=aaa; expires=Tue, 1-Jan-2030 00:00:00 GMT;\n"; print "\n"; ： ↑a1.cgi（ログイン画面）-------------- ↓a2.cgi（ログイン中）-------------- ： #Cookie読み込み $cookie01 = "$ENV{'HTTP_COOKIE'}\n"; ： <HEAD> <!-- キャッシュクリア --> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Cache-Control" content="no-cache"> <meta http-equiv="Expires" content="Thu, 01 Dec 1994 16:00:00 GMT"> ： </HEAD> ： ↑a2.cgi（ログイン中）-------------- ↓a3.cgi（ログオフ）-------------- ： #cookie削除。 print "Content-type: text/html\n"; print "Set-Cookie: NAME=aaa; expires=Fri, 31-Dec-1999 23:59:59 GMT;\n"; print "\n"; ： </HEAD> ： ↑a3.cgi（ログオフ）-------------- ※a1.cgi、a2.cgi、a3.cgiは同じディレクトリです。 よろしくお願いします。
- ベストアンサー
- Perl
- システムの復元時に、、、
いつも大変お世話になっています。 OSはXP、ユーザーはAとBの二人で使用しています。 Aでログイン中に、少しパソコンの動きが悪くなった気がしたのでシステムの復元をしようと試みました。 すると『他のユーザーがログインしていますのでログオフしてから復元されることをお勧めします』みたいなメッセージが出てきたのです。 確認してもBはログオフの状態でした。 これはパソコンの動きが悪かったからこのようなメッセージがでたのでしょうか？ それとも、パソコンの電源が入ってる間はログオフしていてもなにかBで動いているのでしょうか？ 今後、システム復元時にはどのように対処したらいいのやら、、、 あまりに初心者でかなりおかしな質問をしているかも知れません、またどう伝えて良いか判らず説明不足な点があるかも知れませんが、詳しい方、どうかよろしくお願いいたします！
- ベストアンサー
- Windows XP
- セッション情報について
現在、ユーザー名とパスワードを入力し自分専用のページにログインするようなサイトを作成しています。 top画面A⇒ログイン画面B（新しい画面）⇒専用ページC ログインが成功した時点で2画面AとCが存在します。 Cではログインした際、状態識別としてセッション変数に値を入れています。 そこで、C画面をログアウトからでななく、直接ブラウザの×ボタンにて閉じると、上記で設定したセッション変数が残っているため、アドレスバーにCのURLを直接記述するとなんなくログインできてしまいます。 上記をできなくする方法などはないでしょうか？ 分かりづらい説明で申し訳ありませんが、宜しくお願い致します。
- 締切済み
- PHP
- SSLで、セッションを保ちたい。
PHPでコミュニティサイトのようなものを作っているのですが、個人情報もある程度扱うことになっているため、SSLを導入することになりました。 そこで、とりあえずレンタルサーバの無料サービスである、共有認証SSLを用いて、ログインや住所登録をしてもらうことにしようと思ったのですが上手くいきません。 やりたいことは、ログインのときや、住所登録（または変更）のときだけSSL通信にして、そのほかの会員制の掲示板への書き込みなどは、普通にhttpでやりたいのですが、色々試していると、どうもSSL(https)から、普通のhttpに戻るときに、セッション変数が持ちまわせていないことが原因だと分かってきました。 アドレスは以下のような感じなので、 http://www.example.com/ https://userID.securesites.com/ おそらく見えるファイルはどちらも同じなのですが、実質的に別サーバ扱いであるために、セッション変数が持ちまわせないのかな？という風に今は考えています。 この推測は正しいでしょうか？ セッション変数を持ちまわすには、独自認証SSLにすれば解決するのでしょうか？？ 独自認証SSLの場合アドレスでいうと、以下のようなものになります。 https://www.example.com/ また、共有認証でも、ログイン後、httpに戻ったときにちゃんとログインした状態を保持する方法はありますか？ その他、セッションハイジャックの対策など、注意すべき点などがございましたら、ご教授お願いします。よろしくお願いします。
- 締切済み
- PHP
- ログオフについて
ログオフについて質問があります。 例えばＡでログイン、その後、スタート＜ログオフ＜ユーザーの切り替えでＢでログオン、その後、Ｂでログオフを選択すると、真っ暗な画面になり、中央少し左上にカーソルが点滅、操作不能になります。 Ａでログイン、Ｂでログイン、その後、Ｂを終了させてＡに戻りたい時、どの様な操作をすれば、真っ暗な操作不能画面にならずに済むでしょうか。 この状態になった時、いつも電源なが押しで強制終了させてます。他に回避方法があれば、教えて下さい。よろしくお願いしますm(_ _)m。
- ベストアンサー
- Windows XP
- ログイン・ログアウト
サイトに入る時に「ログイン」しますが、「ログオフ」していないのに、ログオフの状態になることがあります。 ここのサイトでは、『２時間』何も操作しないと「ログオフされてしまう」ことは知っています。 ここのサイトに限らず、それ以外の理由で「ログオフ」状態（表示）になってしまう原因として考えられることは、何でしょうか？
- 締切済み
- ネットワーク
- ログインパスワード忘れました
osは98使ってます。 パソコンのログインパスワード忘れました。 ログオフはずっとしていません。 なのでパソコン起動の時はパスワードを求められません。 パスワードを知るにはどうしたらいいですか。 因みにこのままログオフするとパスワードを求められて ログインできないですよね。 よろしくおねがいします。
- ベストアンサー
- ノートPC
- ＯＫ ＷＡＶＥのログインがよくログオフになり不便です。
ＯＫ ＷＡＶＥのログインがよくログオフになり不便です。 自分のパソコンですが時々というかしょちゅうログオフになり いちいちログインするために入力するのが面倒です。 どうすればずっとログインの状態になるのでしょうか？
- ベストアンサー
- その他（SNS・掲示板・ブログ）
お礼
すいません、その通りでした； セッションの問題ではないですね。。。