問題タブ [session-hijacking]

月曜日に、ログインするまで、セッションをユーザー IP として設定することで、セッション ハイジャックのセキュリティ問題を解決したと思っていました。同じ IP を持つ 2 人のユーザー (自分自身とテスト ユーザー) がいて、2 人の間で切り替えを続けていました。これを防ぎ、同じ IP を持つ 2 人のユーザーが自分のサイトに登録できるようにする方法はありますか?

前もってありがとう、テリー。

loginStatusコントロールを使用して、ユーザーがログアウトできるようにしています。ログアウトプロセス（セッションの削除、Cookieの削除、ユーザーのリダイレクトはありません）のコードをこれ以上記述せず、コントロールの組み込みコードに依存します。

ここで、LoginStatusコントロールをページに配置し、残りを自分で実行するだけで十分かどうか（つまり、セッションCookieを削除してユーザーをサインアウトすることを意味します）、またはそのイベントを処理して、Cookieを削除してユーザーをログアウトするコードを作成する必要があります。

LoginStatusコントロールでユーザーをログアウトした後でも、セッションCookieを削除して、他のユーザーがそれを取得して使用しないようにする（ハイジャックする）か、IPや...などの文字列をコンテンツに追加してハイジャックを回避する必要があることを読みました...それは本当ですか？

JSESSIONIDがセキュリティの観点からどのように機能するかについての「ダミー向け」のわかりやすい英語の説明を探しています。

• 私の現在のJSESSIONIDを知っているだけの人が、私のセッションを偽装/ハイジャックできますか？
• どのシナリオでJSESSIONIDがURLの一部になり、このOWASP＃2セキュリティリスク（シナリオ＃1）はTomcat / Glassfishの最新バージョンに引き続き関連しますか？もしそうなら、それを防ぐために何を「オフ/オン」にしますか？

私は金融サービス Web アプリケーションを構築しており、私の会社は Facebook 認証を組み込みたいと考えています。私たちは金融の世界にいるので、セキュリティは最優先事項です。統合に facebook PHP SDK を使用していますが、セッションのハイジャックが非常に心配です。大学時代、セッションハイジャックで周りのみんなのがらくたを盗み出していました (これはとても楽しかったです) が、自分のアプリケーションでこれを防ぐ方法を見つけようとしています。

私の会社では、認証プロセスをできるだけ合理化したいと考えているため、2 要素認証のようなものは望ましくありません。しかし、Facebook のログイン後にユーザーに別の情報を入力するよう求めるのが、最も安全な方法のようです。プロセス全体をシンプルかつ迅速に保ちながら、これを保護する他の方法を思い付くことができる賢明な人々がいると思いますか?

セッションハイジャックを防ぐ方法を見つけようとしています。これが私がやろうと思っていたことです：

ユーザーIDセッションに加えて、ユーザーエージェントとユーザーIPセッションも追加します。ページが読み込まれるたびに、これらのセッションが一致するかどうかが確認されます。これで十分でしょうか。例えば：

ありがとう。

何時間もの欲求不満の後、私はなんとかPHPセッションをデータベースに保存するスクリプトを書くことができました。私の質問は、これはセッションのハイジャックや固定を防ぐのでしょうか？

前もって感謝します。

SSLを使用せずにPHPセッションを保護することに興味があります。

驚いたことに、中間者がユーザーとサーバーの間で交換されたパケットを傍受した場合、セッションが認証されていたとしても、非常に簡単にセッションを盗むことができます。ログイン/ログアウト時にセッション ID を変更したり、ユーザーのシステム パラメータ (OS、ブラウザなど) を記録/確認したりするなど、被害を最小限に抑えるためのいくつかの戦術があることを私は知っています。

ただし、すでに認証されており、ログアウトされていないセッション中に (タイムアウトする時間もありませんでした)、攻撃者がセッション ID を取得できる場合、攻撃者はセッションを簡単に乗っ取ることができます (私が問題を理解している限り)。 ）。

暗号化されたログイン認証中に、サーバーがランダムなセッションパスワードをクライアントに送信できる解決策を考えました。session-password は、そのログイン セッションの間のみ有効です。したがって、そのセッション中に交換されるすべてのメッセージは、セッション パスワードを使用して署名する必要がありました (例: MD5(セッション パスワード+メッセージ コンテンツ))。

問題は解決しましたか? 攻撃者が最初のログイン交換を暗号分析できないと仮定すると、このアプローチの弱点は何ですか?

Cookie / セッションと DB データに関する問題の安全な解決策を見つけようとしています。

私はすでにhttp://www.devshed.com/c/a/PHP/Sessions-and-Cookies/のようなさまざまな記事を読んで、さまざまな Cookie の盗難とセッションの固定方法を説明しており、セキュリティの問題について理解しています。向き合います。

AES_ENTRYPT()問題は次のとおりです。ユーザーパスワードを使用して暗号化するデータエントリを格納する DB テーブルがあります。つまり、情報を読み取るためにも、平文のパスワードを使用してデータを復号化する必要があります。

パスワードを変数に保存するだけであれば、これはおそらく問題にはなりませんが、それでは$_SESSION、Cookie を介して数日間ログインし続けることができなくなります。

言い換えれば、プレーンテキストのパスワードを Cookie に保存する必要があります (少なくとも、ログイン状態を維持する機能を有効にするため)。

パスワードの代わりに、salted MD5() または SHA-256() ハッシュを識別子として使用できるようになりました。しかし、ハッシュを使用してデータを復号化することはできません。これは、パスワードをサーバー側に(データベースに? または他の安全な方法がありますか?) 格納し、それを識別子に接続する必要があることを意味しますが、データベースにアクセスできるすべての人がパスワードにアクセスでき、直接そこでデータを復号化します。

私がCookieに保存した識別子を接続し、それをサーバーに保存されたユーザー入力（パスワード/アカウント名）に接続して、データベースにアクセスできる人にそのサーバー側を読み取る可能性を実際に与える安全な方法はありますか保存されたユーザー入力？

要件は、誰かがデータベースと Cookie のダンプを持っている (ただしサーバー RAM にはアクセスできない) という最悪のシナリオであっても、その人がユーザー パスワードにアクセスして保存されたデータを復号化できないようにすることです。

混乱を避けるために、簡単に要約します。

これはユーザー識別の問題ではありません。ログイン プロセスは個別に行われます (通常の方法: パスワードの md5() ハッシュ / logindata)。私の問題は、ユーザーデータ (住所、名前、電子メールなど) がユーザーパスワードで暗号化されていることです。したがって、それらを復号化するには、ログインからのパスワードが必要です。$_POST データにパスワードがあり、それを使用できるため、ユーザーがログインするだけであれば問題ありません。でもログイン後？$_POST または $_SESSION がなくなるとすぐに、データを再度復号化する方法がありません。

考えられる解決策

いくつかの入力の後、私は方法を考え出したかもしれません - それは完全に安全ではありませんが、十分にうまくいくはずです:

(これはログイン/ユーザー認証プロセスとは別のものであり、暗号化/鍵部分のみを参照しています)

ここでの唯一の問題は、誰かが $auth を取得できた場合、$key を復号化してからデータを復号化できることです。ログインごとに新しい $auth を生成することを考えていますが、古い $auth が失われた場合にキーをどのように復号化するかという疑問が生じます。これとトークンの違いは、トークンが暗号化キー自体ではない別のレイヤーが追加されることです。とにかく、解決策は、公開鍵/秘密鍵以外で、私が意図したものに最も近いと思います。どうもありがとうございました。

stackoverflowはログインページでSSLのみを使用し、質問/回答はHTTP経由で投稿できることに気づきました。

そのためにはユーザーがログインしている必要があるため、SSLが使用されていない場合、stackoverflowがログインしているユーザーを追跡する方法を知りたいと思います。

現在、Cookieを使用してログインステータスを追跡するRailsアプリを作成しています。それを安全に行うにはSSLが必要だといつも思っていました。しかし、私はこれをログインユーザーとしてHTTP経由で投稿しています。

実行してからstackoverflowにアクセスすると、「usr」という名前のtcpdump -i eth0 -ACookieがあり、このCookieはSSLなしでプレーンテキストで送信されます。Wi-Fiカフェなどの安全でない接続を介してログインした場合、ハッカー/パケットスニファが私のusr cookieを取得し、セッションを再生できますか？

RailsアプリでSSLを使用することは避けたいので（ホストはそれを実装するために腕と脚を充電するため）、stackoverflowと同じ手法を使用したいと思います。SSLを使用せずにユーザーをログインさせたままにしたい。

ここではデータベース（またはmemcache / redis）セッションストアが使用されていると思います。しかし、確かにある種のクッキーはまだ必要ですか？なぜこれらのCookieをSSL経由で送信する必要がないのですか？これらのCookieを別のマシンのハッカーに冗長化するバックグラウンドで何か他のことが起こっていますか？

私のサイトは、攻撃者がユーザー アカウントへのアクセスを取得しようとするブルート フォース攻撃を受けています。ボットにはユーザー エージェントがありません。アカウントごとに 10 分以内に 3 回を超える試行を行うと、そのユーザーのサインインをブロックするシステムが導入されています。

また、ユーザー エージェントをチェックし、そうでない場合は終了するようにしました。

私の質問は: セッションはブラウザーにのみ保存されますか? 私が考えているのは、コマンド ライン経由で実行されるスクリプトを使用しているということです。

私もこれを実装しました：

これらの攻撃を防ぐために他にできることはありますか?