4

最近、URL から jsessionid を削除し、「セッション ハイジャック攻撃」を防ぐために Cookie ベースのセッション管理を行いました。

しかし、Cookie が有効な場合、最初のリクエスト URL には常に jsessionid があり、後続のリクエスト URL には jsessionid がないことがわかりました。

最初の URL の jsessionid を使用すると、ワークフロー内の他のページに直接アクセスできます

質問 : 最初のリクエストでのみ jsessionid を公開するセキュリティ上の脆弱性はありますか?

最初のリクエストから jsessionid を削除する解決策がありますが、変更を強制するのに本当に脆弱かどうかを確認したかったのです

ありがとうJ

編集：疑問が明確になりました。返信ありがとうございます。

4

3 に答える 3

10

ここで行ったことにより、ソリューションの全体的なセキュリティがいくらか向上する可能性がありますが、必ずしもセッション ハイジャックを防止できるわけではありません。

URL にセッション ID を配置する際のセキュリティ上の問題は、URL がさまざまな場所で公開されることです (たとえば、URL をコピーして貼り付けるとライブ セッションが公開される可能性があり、URL はプロキシ サーバー ログ、Web サーバー ログ、およびブラウザー履歴に保存される可能性があります)。攻撃者が有効なセッション ID を取得して、ユーザー データにアクセスできる可能性があります。

理想的には、すべての場所で URL から JSESSIONID を削除し、Cookie ストレージのみを使用する必要があります。

さらに、セッション ハイジャックを軽減したい場合は、他にも考慮すべき点がいくつかあります。

セッション ID が渡されるすべてのページで SSL を使用する必要があります (これは、転送中にセッション ID が傍受されるリスク (Firesheep 攻撃など) を軽減するためです)。

ユーザーを認証する前にセッション ID が設定されている場合は、ユーザーのログイン時に新しいセッション ID が発行されるようにする必要があります。

また、可能であれば、セッション Cookie は httpOnly フラグとセキュア フラグを使用して、クリアテキスト チャネルを介して漏洩するリスクを軽減する必要があります。

OWASP サイトにいくつかの優れた追加情報があります。

ところで、セキュリティ面でさらに質問がある場合は、 Security.stackexchange.comに専用のスタック交換サイトがあります。

于 2011-01-18T13:49:57.093 に答える
2

「セッションハイジャック攻撃」を防ぐためにCookieベースのセッション管理を行いました

クッキーが乗っ取られるのを止めるのは何ですか？

セッション管理はサーバー側のものです-ユーザーがログインすることを意図していることを（Cookieに基づいて）確認するためにサーバーを使用する必要があります。

正直なところ、ここでセキュリティが向上したとは思いません。この優れた記事を見て、その理由を確認してください。

于 2011-01-18T09:03:13.567 に答える
0

誰かがセッションIDを入手した場合、セッション全体を乗っ取る可能性があります。予測可能なセッションIDの脆弱性を参照してください。

于 2011-01-18T09:06:32.333 に答える