問題タブ [session-hijacking]

登録ユーザーが（有効なパスワードを使用して）ログインし、ユーザーIDに基づいてセッションをセットアップできるphpサイトがあります。しかし、私はこれがハイジャックされていると確信しており、そこに置いていないサーバー上に「新しい」ファイルを見つけました。私のサイトでは、SQL インジェクションと XSS のすべてのユーザー入力をクリーンアップしていますが、これは引き続き発生します。これを解決する方法について何かアイデアを持っている人はいますか?

Kohana フレームワークを使用したセッション ハイジャックを回避するために何か特別なことをする必要がありますか? セッションはKohana Sessionライブラリのみで操作されると仮定しています

ASP.NETの現在のバージョンに組み込まれているセッションIDハイジャック保護について知りたいのですが。

最近、IPアドレスとユーザーエージェントヘッダーをセッションIDにエンコードする追加のレイヤーを実装することで、セッションのセキュリティを強化する方法を説明するこの非常に有益な記事を見ました。これらの詳細は、後続の各リクエストで検証されます。

この記事はASP.NET1.1向けに作成されたようですので、同様の機能がASP.NETに組み込まれているかどうかを知りたいと思います。このような追加のレイヤーを実装することには、まだメリットがありますか？

ありがとう。

小さなサイトでシンプルなショッピング カートを作成しています。

カートのアイテムとログインした user_id をセッション変数に保存する予定です。

物事をもう少し安全にするために、私はこれを行うと思いました：

1. セッションに格納する前に、user_id を sha1() します。

2. また、sha1() を使用して http_user_agent 変数をいくつかのソルトとともに保存し、これを user_id とともにチェックします。

できることは他にもあることは知っていますが、これは少なくともかなり役立つと思いましたよね？簡単に実装できます。

物事を説明したり、フローチャートを書いたりするのが得意ではないので、あらかじめお詫び申し上げます。これは特定のコードの問題ではなく、セッション セキュリティに関する一般的な質問です。

一度にできるだけ多くの潜在的な問題を排除しようとしています。私はこれが世話をすると思います：

• CSRF
• セッション固定
• セッション予測
• Cookie の盗難 (ブラウザの脆弱性による)
• セッションのサイドジャッキング

攻撃者の IP とユーザー エージェント ヘッダーの両方が認証されたユーザーのものと同じである場合、セッションは依然としてサイドジャックされる可能性があることを認識しています。その防弾を作るにはSSLが必要だと思いますか？

以下のclusterfuckで私が言おうとしていることを理解できれば、どんな批評でもありがたいです. これは多かれ少なかれ私がやっていることです:

編集 - 私が持っていた別の質問: これが問題になるほど頻繁に変更される IP アドレスをユーザーが持っていないと仮定しても安全ですか?

サーバーがユーザーに対して持っている信頼を考えてみましょう。

セッションの固定: 固定を避けるためにsession_regenerate_id()、認証 (login.php) でのみ使用します

セッション サイドジャッキング: サイト全体の SSL 暗号化。

私は安全ですか？

私は、Flash や Javascript などを使用したクロスサイト スクリプティングについて多くのことを読み、任意のサーバーからのアクセスを許可する crossdomain.xml を持つ Web サイトのリストもいくつか見つけました。たとえば、flickr.com はすべてのドメインを信頼します。

これが安全だと思われ、セッションハイジャックのような攻撃につながらない理由を誰か説明してもらえますか? これらの crossdomain.xml はサブドメインでのみ有効であるため、攻撃者がセッション キーを取得することはできませんか?

私は uploadify を使用しており、スクリプト (adobe flash を使用) は、アップロード アクション URL を要求するときに、現在のセッションを使用する代わりに新しいセッションを作成します。これを修正するには、セッション ID を先に渡す必要があります。

セッション固定 (ハイジャック) を許可せずにこれを行う方法はありますか?

問題の詳細は次のとおりです。 セッションとアップロード

ありがとう！

私が理解している限り、ユーザーがSpring Securityにログインすると、セッションが無効になり、新しいセッションが作成されます。
したがって、明確な sessionID cookie を使用して http から来た場合、Spring Security は、後続の https リクエストでのみブラウザーによって返される新しい sessionID の「安全な」cookie を設定する必要があります。
私が見逃しているのは、「ログインした」ユーザーが https から http に切り替えるとき、セッションを追跡するために非セキュア Cookie としてどこかに保存されている sessionID Cookie が必要であるということです。
Springがそれをどのように管理するかわかりません。
ユーザーがログインした後、http を参照すると、クリアな sessionID Cookie は安全な SessionID と同じになり、世界中に表示されますか? 誰かがそれを読んで、セッションを乗っ取ることができます。
Spring Security フローがわかりません。誰かがどのように機能するのか説明してもらえますか?
ありがとう

他のユーザーが信頼できるサイトに植え付けたjavascript関数を使用して、セッションIDCookieを簡単に盗むことができます。この種の攻撃に対して考えられる対策は何ですか？

ほとんどすべてのサイトがjsを使用しているため、クライアント側ですべてのjavascriptスクリプトを拒否することはおそらく困難です。サーバー側で考えられる対策は何ですか？有効なセッションIDが別のホストから使用されるのを防ぐために、セッションID値にクライアントIPアドレスのハッシュを含めることは可能ですか？このアプローチは理にかなっていますか？

貴重な回答で言及されているリソースの1つで、リクエストごとにセッションIDが変更されるソリューションが提案されています。そのような機能は、アプリサーバー/フレームワークですでにサポートされていますか？特にDjango/pythonはどうですか？