web-dev-qa-db-ja.com

HttpページからHttpsページへのリンク-セキュリティ上の問題ですか？

保護する必要のあるサイトはほとんどありません。ただし、ログインしたユーザーのみを対象とするサイトの小さな部分があります。

したがって、私の通常のサイトはHttpであり、ログインしているユーザーのサイトはHttpsを介しています。

私の通常のHttpサイト-そのコンテンツにアクセスする必要があるユーザーのためのhttpsログインページへのリンクがあります。

これがセキュリティの問題かどうか、つまりHTTPページからHTTPSページへのリンクがあるかどうか疑問に思いました。

私が考えることができる唯一の攻撃は、誰かが私のサイトに似たURLを持つ偽のサイトを指すようにリンクを変更する中間者攻撃がある場合です。

これは懸念事項ですか？どうすれば軽減できますか？通常のサイトをhttpsにする唯一の方法はありますか？

編集：私の質問は他の質問の重複ではありません-他の質問はhttp postログインへの切り替えについて尋ねます。私の質問はまったく異なります。同じサイトの2つの異なる部分についてです。1つはログインが必要で、もう1つは公開されています。最初の部分をhttps（ログインとポストログインの両方）のままにし、他の部分をhttpのままにしても問題ないかどうか尋ねています。

tlshttpman-in-the-middle
5
user93353

はい、それは安全ではありません。

攻撃する最も簡単な方法はsslstripです。これは、MitMを実行し、httpsリンクをhttpリンクに自動的に置き換えるツールです。

正しく行う唯一の安全な方法は、Webサイト全体にhttpsを設定し、HSTSをアクティブにすることです。

たとえば、サードパーティ（ISPなど）がユーザーの同意なしにWebサイトに広告を挿入するのを防ぐために、ログに記録されていないユーザーでもhttpsは便利です。

6
Tom

ここでの主な脅威は中間者攻撃です。

http://example.comからhttps://example.com/secure/loginに移動するユーザーは、 sslstrip であるか、フィッシングドメインhttps://example.orgにリダイレクトされる可能性があります。

これは、HSTSを使用してsslstripを軽減できないことも意味します。 HSTSは、ブラウザーがHTTPS経由で接続すると、ポリシーの有効期限が切れるまで、そのドメインへのプレーンなHTTP接続を確立できないことを保証します。 「そのドメイン」とは、実際のドメイン、またはサイトのプレーンHTTPバージョンになりすましたMITM制御ドメインのいずれかを意味することに注意してください。

安全なコンテンツが安全でないコンテンツと同じドメインにある場合、これは、すべての機密CookieにSecureフラグを設定している場合でも、CookieがMITMによって汚染される可能性があることを意味します。たとえば、セッション固定攻撃、CSRF二重送信Cookieコントロールへの攻撃、またはCookieを使用してページに生のコンテンツを表示している場合、XSS攻撃が可能である可能性があります。これは、http://example.comとhttps://example.comのいずれかに設定されたCookieは、サーバーに対して同じように見えるためです。Secureフラグは、サーバーがそれらを区別するために各HTTPリクエストで送信されないためです。

サイト全体でHTTPSを使用し、プリロード付きのHSTSポリシーを実装することをお勧めします。

1
SilverlightFox

あなたのサイトはhttpモードで参照できるので、機密性の高いコンテンツは含まれていないと思います。 HTTPとHTTPSのどちらを選択するかは、セキュリティをパフォーマンスと交換することの問題です。

  • hTTPで実行できることはすべてHTTPSでも実行でき、より高いセキュリティが得られます
  • HTTPSはより多くのリソースを消費します

経験則として、十分なリソースを提供できる場合はHTTPSを使用し、データの値が低い場合はHTTPを使用します。

提供される資格情報交換のような、通常のページにはHTTPを、機密ページにはHTTPSを混在させることが許容されます。

  • サーバーは安全なページへのHTTPリクエストを拒否します=> HTTPSリンクを含むページがHTTPリンクで書き換えられた場合、HTTPSページへのリダイレクトまたはエラーが発生します
  • サイトの全体的なセキュリティはHTTPレベルです
  • 機密性の高いページがサイトからのものであることをユーザーが制御できると確信している

注意する必要があるのは、セッションが安全でないCookie（HTTPモード）を使用するとすぐに、そのセッションを信頼して機密情報にアクセスするべきではないということです。

これは正しいです：HTTP相談=>ログイン用HTTPSへのリンク=>ログイン後の新しいセッション=> HTTP相談-セッションCookieは安全ではなく、資格情報のみを保護するため、全体的なセキュリティは中程度です

しかし、これは悪いことです：HTTPSログイン=>非機密ページのHTTPコンサルテーション=> HTTPSコンサルテーション/機密データの変更

ここでは、セッションのセキュリティレベルがHTTPに低下し、機密操作に使用されているためです。

最小値は次のとおりです。

... => HTTPオペレーション=>クレデンシャルまたはセキュアCookieのHTTPS制御=>新しいセッション=> HTTPSオペレーション...

ここでの最大のリスクは、ログインページが特別であること、および小さな南京錠が存在することをユーザーが制御する必要があることをユーザーに指示する必要があることですand URLは正しいドメインにあります。リスクはここにあります：

  • 攻撃者がなんとかしてログインページのコピーを取得した
  • それは彼が制御するページにあなたのユーザーの一人を送ることをどうにかして
  • ユーザーが資格情報を書き込む

=>攻撃者はユーザーに許可されたすべてのアクセス権を取得しました

TL/DR：サイトの一部のみ（ログインページを含む）をHTTPSで使用できるのは、次の場合のみです。

  • ログインページはHTTPSでのみアクセス可能で、新しいセッションを作成します
  • hTTPからHTTPSへの移行には、資格情報（または特別な安全なCookie）の制御が必要です
  • 資格情報を入力する前に、すべてのユーザーがログインページのURLが正しいことを制御します
0
Serge Ballesta