https - HSTS と安全な Cookie を使用した https のみ

Question

私のサイトが安全なセッション cookie を使用して https でサービスを提供していて、http url の試行を https にリダイレクトする場合、十分な保護になりますか?

このセットアップでは、HSTS ヘッダーを設定しないと生きていけない、どのような種類のセキュリティ ホールが公開される可能性がありますか?

Answer 1

この戦略は、攻撃者がユーザーをだまして SSL 以外のものを使用してサイトにアクセスすることを困難にすることで、受動的な盗聴から保護します。また、ユーザーが保存するすべてのブックマークが https URL を指していることもおそらく保証されます。これは良いことです。ただし、中間者攻撃が発生した場合でも、HSTS には利点があります。

HSTS が解決しようとしている問題の核心は、特定のサイトで SSL を使用する必要があるかどうかをブラウザーが認識できないことです。また、ほとんどのユーザーは最初に SSL を明示的に試しません。URL を入力すると、通常は最初に非 SSL http サイトに移動し、通常はリンクをたどるだけです。攻撃者が http URL 経由でユーザーをだましてサイトにアクセスさせ、ユーザーのトラフィックの真ん中に (たとえばワイヤレス AP として) 座ることができる場合、その攻撃者は中間者攻撃を仕掛けることができます。ユーザーのトラフィックをサイトにプロキシし、SSL を使用せずにサイトをユーザーに提示することにより、サイトに対して攻撃します (これは一種のダウングレード攻撃です)。ユーザーには SSL が表示されないため、攻撃者があなたのサイトに対して有効な証明書を持っていないこと、および彼らが あなたのサイトに直接接続していません。(より複雑な方法は、SSL トラフィックを傍受し、サイトに対して自己署名または無効な証明書を提示することですが、通常、これはブラウザーの警告になります。)

このシナリオでは、非 SSL ユーザーを SSL にリダイレクトしたり、Cookie にセキュア フラグを設定したりしても、実際にはあまり役に立ちません。中間者攻撃者はあなたの SSL サイトに接続し (そしてユーザーのアクションをそこにプロキシします)、ユーザーに渡すときに Cookie からセキュア フラグを削除するだけです。

もちろん、攻撃者は HSTS ヘッダーを削除することもできます。ただし、HSTS プロトコルのポイントは、ユーザーが過去にサイトに直接アクセスしたことがある場合、ブラウザーはサイトが HSTS を送信したことを記憶することです。後でサイトに接続して、SSL を使用していないか、ブラウザーが証明書を検証できないことが判明した場合、ブラウザーはエラーをスローし、続行を拒否します。これにより、ブラウザーが HSTS をサポートし、サイトが SSL を必要としていると記録されている場合、攻撃者がサイトを非 SSL にダウングレードするのを防ぐことができます。

ウィキペディアにはこれについてかなり良い議論があり、RFCでの議論よりもいくらか明確だと思います。