最初に301リダイレクトのシナリオを見てみましょう。被害者はhttp://example.comにリクエストを送信します（コメントで指摘されているように、これはSSLStripまたはユーザーがURLバーにexample.comを入力したためであり、ブラウザはデフォルトでHTTPになっています）。 MitM攻撃がない場合、301応答が返され、https://example.comにリダイレクトされます。しかし、MitMがある場合、攻撃者は301を送信しないことを選択するだけでなく、HTTP経由でサイトの（変更された可能性がある）コピーを提供できます。
ここでの弱点は、最初のHTTP接続（TLSなし）が行われ、攻撃者がそのトラフィックを変更できることです。ただし、HSTSを使用した場合、ブラウザは（被害者が以前にサイトを訪問したと仮定して）ページが常にHTTPS経由で提供されることを認識します-HTTPリクエストは送信されず、ブラウザはリクエストを送信するだけです。 https://example.com。攻撃者はTLS接続をMitMできないため、攻撃は阻止されます。
（ブラウザーが301応答をキャッシュするという事実により、これは実際には少し複雑になります。その詳細については、 bonsaivikingの素晴らしい答え または この質問 を参照してください。キャッシュされている301は少し役立つかもしれませんが、HSTSが行うようにあなたを完全に連れて行くわけではありません。）
HTTP Strict Transport Security（HSTS）はセキュリティのために設計されています。HTTP301 Moved PermanentlyはURLリダイレクトに使用されます。
301リダイレクトは、HTTPS Webサイトの展開の重要な部分です。 HTTPプロトコルの一部として、HSTSよりも多くのブラウザーでサポートされています。これは、プレーンテキスト接続をHTTPSにアップグレードし、検索インデックスを更新し、リンクの腐敗を回避するための主要な手段として機能します。
多くの場合、これらの2つの方法には同じ弱点があります。ユーザーがブラウザで「example.com」と入力したときの初期リクエストはプレーンテキストで送信されます。最初の要求がアクティブな中間者（MITM）のある敵対的なネットワークで行われた場合、応答が傍受される可能性があり、接続は安全な接続にアップグレードされません。
ただし、HSTSが重要であり、標準の301リダイレクトに比べてセキュリティが大幅に向上する理由は数多くあります。
- HSTSはドメイン全体をカバーします。 301リダイレクトは特定のURIパスのみをカバーします。ユーザーが
example.com/にリダイレクトされた場合、example.com/somepageへの以降のリクエストは最初はまだHTTPを使用するため、再度リダイレクトする必要があります。 HSTSを使用するサイトは、サイト全体をカバーするために1つの要求のみを必要とします。 - HSTSは最初のHTTPS接続でも機能します。 301リダイレクトはプレーンテキストURIをHTTPSの1つにマップするだけなので、HTTPSに直接アクセスすると、以降のアクセスは保護されません。
- HSTSは個別のキャッシュを使用します個別のタイムアウト。多くの場合、301キャッシュは、パフォーマンスを目的として設計されたブラウザのリクエストキャッシュに関連付けられています。しばらくページにアクセスしないと、頻繁にアクセスするサイトを優先するために、キャッシュからクリアされる可能性があります。このキャッシュには、数週間または数か月の最大経過時間が存在する場合もあります。 「サイトが機能しない」の一般的な修正は、ユーザーに「キャッシュをクリアする」ように伝えることです。これらはすべて、ユーザーをMITM脅威にさらすことになります。 HSTSタイムアウトは通常、数か月から数年のオーダーであり、キャッシュは通常別々であるため、簡単にまたは誤ってクリアすることはできません。
- HSTSは、ブラウザでプリロードできるである。 Googleはこれを、ChromeブラウザがWebクロール中に検出され、プログラムに直接送信されたヘッダーに基づいて）で行います。プリロードされたサイトの場合、ブラウザはそもそもプレーンテキストでアクセスする必要はありません。常にHTTPSのみであると想定されます。
まず、一部の古いブラウザはHSTSをサポートしていないため、HTTPをHTTPSにリダイレクトしたり、すべてのCookieにsecureフラグを設定したりする必要があります。
上記の細かい理由に加えて、SSLStripタイプの攻撃を無効にすることはHSTSの主な目的の1つであるため、HSTSが防御する別の攻撃がありますが、単純なリダイレクトはそれを行いません。
サイトが完全にHTTPSでアクセスされているとしましょう。ユーザーは本当に注意深く、HTTPS経由でのみこのサイトを要求します。リダイレクトは必要ありません。 HSTSはありませんが、セキュリティで保護されていないHTTPを介したサイトへのリンクもないため、サイトへのトラフィックはすべて暗号化されます。
ただし、サイトに特定のCookie（存在する場合）を適切にエスケープせずにページに反映するセキュリティの脆弱性があるとします（CookieベースのXSS、まれですがほとんど聞こえません）。攻撃者は実際にはHTTPSトラフィックを読み取ることはできません（変更はほとんどありません）が、実際にはそのHTTPSサイトのユーザーのセッションにアクセスする必要があります。したがって、ユーザーがHTTP経由でotherサイトにアクセスするのを待ち、そのサイトからの応答を変更して、目に見えない要求（おそらくスクリプトsrc）を含めます）からhttp://securesite.com/（HTTPSのみのサイトですが、代わりにHTTP経由）。次は何が起こる：
- サイトのブラウザーにアクティブなHSTSポリシーがある場合、ブラウザーは自動的に要求を
https://securesite.com/に書き換え、攻撃者はトラフィックを読み取ったり変更したりできません。 - 攻撃者が改ざんを行わないがサイトにHSTSがない場合、リクエストは送信され、
https://securesite.com/への301が取得され、リクエストはHTTPS経由で再び送信されます。- ただし、securesite.comの
secureフラグが付いていないCookieは、最初の非セキュアリクエストに含まれます。攻撃者は、その時点で受動的な盗聴を行っても、それらを読み取ることができます。これは悪いことです（これは、たとえサイトにアクセスする必要がない場合でも機密性の高いcookieに常にsecureフラグを設定する必要がある理由です（-===-）安全でない接続を介して）。
- ただし、securesite.comの
- ただし、すべてのCookieが
secureの場合、この攻撃は無意味になります。攻撃者は改ざんする必要があります。安全でない要求への応答を偽造または変更できます。この特定のケースでは、攻撃者はSet-Cookieヘッダーを応答に追加し、ユーザーのブラウザにcookieを配置して、HTTPまたはHTTPSを介して、securesite.comへの今後のリクエストで送信されます。
仮説に基づいたCookieベースのXSSベクトル（またはCookieを植える攻撃が害を及ぼす可能性のあるその他の要素）では、ユーザーがHTTPSを介してのみアクセスするように非常に注意していたサイトへの攻撃が成功しています HSTSを使用しておらず、セキュリティで保護されていない接続なしでは悪用できない脆弱性があったためです。
注意すべき重要な点は、 Cookieの同じ生成元ポリシー が他の場所の同じ生成元ポリシーよりも緩いことです。つまり、Cookieの安全なチャネルは1つではなく、それらは同じオリジンです。
Client ----Plain HTTP----> Server
Client ---------HTTPS----> Server
もちろん、セキュアフラグを設定できるので、Cookie値はHTTPS経由でのみ転送するように設定できます。
例えば.
Set-Cookie: foo=bar; secure
Client --> HTTP (no cookies) --> Server
Client --> HTTPS (Cookie: foo=bar) --> Server
ただし、サーバーがCookieがセキュアフラグで設定されたかどうかを知る方法はありません。
例えばプレーンHTTP経由
Set-Cookie: foo=bar
Client --> HTTPS (Cookie: foo=bar) --> Server
サーバーは次の状況になります。
したがって、HTTPSを介してサーバーによって設定されたCookieは探知できませんが、MITMは独自の値を「安全な」セッションに挿入できます。これは、プレーンなHTTPサービスがない場合にも当てはまります。
Client ----Plain HTTP----> No service
Client ---------HTTPS----> Server
... MITMは引き続きドメインへのプレーンなHTTPリクエストを生成し、Cookieを挿入できるためです。
Client ----Plain HTTP----> MITM --> No service
Client ---------HTTPS-------------> Server
これは、サイトに他の方法では悪用できない可能性があるいくつかの脆弱性がある場合、攻撃につながる可能性があります。
- セッションの固定： 非セキュアまたは非HTTPのみのCookieがHSTS Webサイトのセキュリティにどのように影響しますか？
- XSS Cookieポイズニング： Flash cookie and man-in-the-middle
上記と同様に、HSTSなしで ssltrip スタイルの攻撃を実行できます。 sslstripは、ユーザーがHTTPSでないことに気付かない程度に依存しています。
this answer も参照してください。