11

Tomcat 6.0.29 で Java アプリケーションを実行しており、前に Apache 2.2.3 を使用しています。ログイン ページは HTTPS を使用しますが、ほとんどのページは HTTP を使用します。

ユーザーがログイン保護されたページ (HTTP) にアクセスしようとすると、ログイン ページ (HTTPS) にリダイレクトされ、ログインしてから、最初に要求されたページにリダイレクトされます。JSESSIONID Cookie は非セキュアとして設定され、HTTP と HTTPS の両方に使用されるため、これはうまく機能します。

ただし、ユーザーがログイン ページ (HTTPS) で開始した場合、JSESSIONID Cookie は Secure として設定されるため、HTTP でページにリダイレクトするときにログイン後にセッションを使用できず、新しいセッションが強制され、再度ログイン ページにリダイレクトされます。今回は JSESSIONID Cookie が非セキュアに設定されているため、今回は機能します。

ユーザーが最初にログイン ページにアクセスしたときに 2 回ログインする必要がないようにするにはどうすればよいですか?

4

1 に答える 1

7

(更新: わかりやすくするために)ログイン Http get/post で https を使用し、ユーザーのログイン セッション全体で https を使用します。

ログインしているユーザーがいない場合にのみ、Http を使用します。

Cookie がプロトコルの境界を越えることを許可しないのには理由があります。これは攻撃ベクトルです! (* 以下のアップデートを参照)

この非常に悪い考えを行う方法

本当に主張する場合は、リダイレクト内の jsessionId を http URL にエンコードします (または常に URL 内の jsession ID をエンコードします)。Tomcat が http リダイレクトを取得すると、Tomcat はセッションを見つけて続行する必要があります。

なぜこれをしてはいけないのか

真剣に、同じページに https と http のコンテンツが混在しているサイトは、あらゆる種類の楽しい (そして簡単な) 攻撃にさらされているだけです。

セッションの残りの部分がクリアテキストである場合、https からログインを「安全」に保つことは無意味です。では、ユーザー名/パスワード (おそらくパスワードのみ) が保護されているとはどういうことでしょうか?

常に人気のある中間者攻撃を使用すると、攻撃者はセッション ID をコピーし、それを使用して楽しんでいます。ほとんどのサイトはアクティブなままのセッションを期限切れにしないため、MIM はパスワードを持っているかのように効果的にフル アクセスできます。

パフォーマンスの点で https が高価だと思われる場合は、こちらを参照するか、単に検索してください。https のパフォーマンスを許容範囲まで改善する最も簡単な方法は、サーバーが接続でキープアライブを設定していることを確認することです。

于 2011-01-10T05:00:53.343 に答える