web-dev-qa-db-ja.com

ログイン後にユーザーがHTTPSからHTTPにリダイレクトされた場合、セッションがハイジャックされることはありますか？

ユーザーがログインしていない限りHTTP呼び出しを行うWebアプリを開発しています。
ユーザーが ログインする ボタンをクリックすると、HTTPSである「ログインページ」に送信されます。

ログインによりサーブレットへのAjax呼び出しが行われ、特定の属性がセッションに追加されます。
次に、の問題を解決する 「セッション固定」、現在のセッションが無効になり、新しいセッションが作成されます。

ログイン後、ユーザーはHTTPを使用してアプリケーションページにリダイレクトされます。

順番に 負けない セッション属性（HTTPSとHTTPの間）デフォルトを上書きしました Glassfish JSESSIONID Cookieをキャッシュし、それを応答として送信することによるメカニズム：（これはj2eeアプリケーションです）

  Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId());
  cookie.setMaxAge(-1);
  cookie.setSecure(false);
  cookie.setPath(request.getContextPath());
  response.addCookie(cookie);

それは正常に動作しますが、私はスタックオーバーフロー IT Security を読んでいて、通常はオンラインで、セッションがまだハイジャックされる可能性があることを読んでいます。たとえば この答え は、それは非常に悪い考えであり、真ん中の男がそれを乗っ取ることができると述べています。

私はセキュリティの専門家ではありませんが、私が作成した次のメカニズムについてのフィードバックをお願いします。

  • WebアプリのURLを入力する場合、最初のランディングページはHTTPです。すべてのメカニズムはHTTPです。
  • ユーザーが「ログイン」することを決定すると、ユーザーはページにリダイレクトされ、その「ランディング」ページはHTTPSになります（j2eeによって強制されます） 機密 セキュリティ制約）
  • サーブレットでは、セッションの固定化は、セッションを無効にして新しいセッションを作成することによって処理されます。次に、セッション属性が追加されます。
  • HTTPに戻るときにセッション属性を失わないようにするために、Cookieは手動で同じ「セッションID」で上書きされ、「非セキュア」に設定されます。
  • すべてのアプリ要求は再びHTTPです。

これはまだセッションハイジャック/ MITM /またはその他のセキュリティ上の欠陥の簡単な標的ですか？
セキュリティの詳細についてはあまり経験がないので、フィードバックをいただければ幸いです。

tlscookiessession-management
7
shadesco

HTTPでページをリクエストするときは常に、すべてがプレーンテキストで送信されます。つまり、IDを含むセッションCookieもプレーンテキストで送信されます（画像リクエストの場合も）。これにより、MITM攻撃の標的となりやすくなります。 CookieをHTTPSページのみに送信するように構成できますが、もちろん、HTTPページではセッションが失われます。

この問題に対処する最善の方法は、サイト全体をHTTPSのみにすることで、この方法で多くのトラブルを回避できます。サイトのトラフィックが非常に少ない限り、今日のサーバーでは問題になりません。

本当にHTTPページとHTTPSページを切り替える必要がある場合は、セッションと認証の維持という2つの懸念を切り離すことができます。認証のためだけに2番目のCookieを追加し、それをHTTPSページのみに制限できます。セッションCookieは、HTTP要求とHTTPS要求の両方に使用できます。これを実装する方法の example を作成しました（PHPで記述されていますが、このアイデアは他の環境にも実装できます）。

10
martinstoeckli

はい。セッションはハイジャックされる可能性があります。あなたのアプローチは安全ではありません。適切なセキュリティを提供する唯一の方法は、すべてにHTTPSを使用することです。

HTTP経由でセッションIDを送信しています。つまり、平文で送信されているため、傍受される可能性があります。インターセプトされると、攻撃者はユーザーのアカウントを制御するために必要なすべてのもの（おそらく、HTTPSに委任したアプリケーションの部分を含む）を手に入れます。

まさにこの種のアーキテクチャーを利用するFiresheepを読むことをお勧めします。サイトが盗聴や中間者攻撃に対して安全であることを望む場合（たとえば、オープンWifi経由で接続しているユーザーに対して安全であることを望む場合）、サイトはすべてに対してHTTPSを使用する必要があります。

このサイトで次の質問を参照してください。 サイト全体のSSL（https）の長所と短所は何ですか？ 、 HTTPセッションCookieがWi-Fi経由で危険にさらされるのはいつですか？ 、および FireSheepに対して依然として脆弱なサイトはありますか？ 。

これが私があなたのサイトに提案するものです：

  • サイト全体でSSLを使用：つまり、HTTPSではなくHTTPSのみを使用します。何のためにもHTTPを使用しないでください。 HTTPSのみを使用します。 HTTP Strict Transport Securityを有効にします。すべてのCookieにセキュアフラグを設定します。

  • ユーザーを認証する方法について慎重に検討してください。

4
D.W.

HTTPSに関する最大の攻撃ベクトルの1つは、ユーザーを騙すことに依存しています。ユーザーが期待するときにHTTPSが使用されていることを確認するのは、常にユーザーの責任です。ユーザーだけが、プレーンHTTPにダウングレードされていないかどうか（および証明書が有効かどうか）を確認できます。

「j2ee CONFIDENTIALセキュリティ制約」は、その点ではほとんど役に立ちません。はい、強制的にリダイレクトされますが、このリダイレクトはアクティブなMITMで処理できます。 HTTPSセクションのリンクがhttps://を使用していることを確認してください（詳細 こちら ）。

@martinstoeckliが言ったように、可能であれば、どこでもHTTPSを使用します。それができない場合は、HTTPSがより重要であると判断した場合は必ず、ユーザーがHTTPSを使用することを期待してください（これらのページがプレーンHTTPのみを使用している場合は移動します）。

ユーザーが正しい検証を行うための技術的な解決策はほとんどありません。それらの1つは、ユーザーが HTTP Strict Transport Security をサポートするブラウザーを使用することですが、（a）そのようなブラウザーが必要であり、（b）初めてHTTPSを期待します（これはより優れています） HSTS対応サイトの事前ロードされたリスト ）がある場合。

2
Bruno