最初にHTTP経由でCookieデータを送信しないようにするにはどうすればよいですか？
HSTSを使用して、ブラウザにfutureリクエストで常にHTTPSを使用するように指示できます。
今後はHTTPS経由でのみCookieを送信するCookieセキュアフラグを使用できます。
DNSベースのリダイレクトを使用できますが、HTTPリクエストがそこに到達した後でのみです。
私の質問は、ユーザーが常にHTTPSとしてサイトにアクセスし、初めてでもHTTP経由でデータを送信しないようにする方法です。
編集：
これに対する解決策の欠如を考えると、ブラウザはデフォルトで最初にhttpsリクエストを自動的に送信するはずであり、それは機能せず、ダウングレードすると思います。
コメントの要約で（そして私の以前の回答を置き換えることで）：sslstripが可能である限り、攻撃者はブラウザがユーザーがセッションを制御していると考えている間、ユーザーを偽装してセッションを制御することができます。 HSTSのみがsslstripを防止でき、HSTSプリロードのみが最初の要求（HSTSヘッダーを取得する前）でsslstripを防止できます。
したがって、HSTSプリロードは Benoit Esnardによる回答 で正しく指摘されているように進むべき道です。
問題は、更新されたリストは新しいバージョンのブラウザー（少なくともGoogle Chromeの場合）でのみ出荷されるため、HSTSプリロードが新しいドメインで利用可能になるまでに数か月かかることがあります。
つまり、短期間で実装できるソリューションはありません。
HSTSプリロードリスト にWebサイトを送信します。
HSTSプリロードリストは、ブラウザに埋め込まれたホスト名のリストであり、HTTPSとしてのみクロールする必要があるWebサイトを知ることができるため、HTTPS以外の要求を防止できます。
あなたが説明しているものは Session Fixation Attack（Wikipedia link） と呼ばれます。
要するに、問題は攻撃者があなたにセッション識別子Cookieを与えることができるということです。このCookieを使用してログインすると、サーバーがユーザーのIDをこのCookieに関連付けます。
攻撃者はまだあなたのセッションID Cookieを知っており、サーバーを装っているふりをすることができます。攻撃完了。
これを防ぐには、誰かがログインしたときにサーバーがセッションID Cookieを変更する必要があります。攻撃者は古い価値のないCookieを残され、何もできません。
すべてのWebフレームワークでセッションCookieを変更できるわけではありません。これが問題である場合は、この目的で別のCookieを使用できます。これは、フレームワークが認識していない別の「認証済みCookie」です。このCookieもログインごとに変更する必要があります。
クライアントがHTTPに接続しようとするのを完全に止める方法はありませんが、おそらくcookieを使用しているとしたら...私たちの課題は、発生する頻度を減らす方法を見つけることです。
1つのアプローチは、HTTPをまったくサポートしないことです。 HTTPリクエストがタイムアウトするようにします（リダイレクトなし、何もしない）。これにより、他のサイトがHTTPアドレスにリンクする可能性が低くなります。そのようなリンクは機能しないためです。今後、サイトにリンクするすべての人がHTTPSに直接リンクすることを期待しています。
Cookieが最初にHTTP経由で送信されるのを防ぐことはできませんが、これによって発生する可能性のある損害を最小限に抑えるための対策を講じることができます。基本原則は、HTTP経由で送信されたものを決して尊重することは決してなく、クリアテキストで機密情報を受信する場合は常に、その情報を危険にさらしたものとして扱います。
HTTPからHTTPSにリダイレクトするようにサイトを設定し、Strict-Transport-Securityヘッダーの送信を開始します。 （準備が整うまではプリロードに行く必要はありません。これから説明しようとしていることは関係なく機能します。）
次に、クリアテキストHTTP経由で送信されたCookieを確認するたびに、サーバー側でそれらのCookieをすべて無効にします。いくつかの理由で動作することが保証されていないため、この時点ではブラウザのCookie jarからそれらを追い出そうとしないでください（クリアテキストのHTTP応答は、セキュアとタグ付けされたCookieを操作できないため、古いブラウザはmax-age = 0を無視する可能性があります、中間者は、被害者が侵害されたCookieを使用し続けるためにSet-Cookieを完全に削除する場合があります。ただし、それらが後続のHTTPSリクエストに表示されるときにそれらを尊重しないでください。その時点で（つまり、セキュリティで保護されたチャネルが確立されている場合のみ）、新しいセッショントークンを発行し、ユーザーに再度ログインするように要求します。
同様に、ログインフォームがクリアテキストで送信されているのを確認した場合は、セッションCookieを無効にしないでくださいlockアカウント。 アカウントの復旧、ログイン、または登録フォームをHTTPからHTTPSにリダイレクトしないでください。代わりに、人間に手動でURLを修正するように指示するエラーメッセージを発行します（キャプチャのようですが、sslstripでURLの書き換えをバイパスするためです;-)。また、クリアテキストを介してアクセスした場合、ログインしたユーザーだけがアクセスできる必要があるページは、HTTPS自体ではなく、フロントページにリダイレクトする必要があります。
さらに、セッションCookieがunforgeableとmeaninglessの両方であることを確認してください。最近、ほとんどのWebフレームワークがこれを自動的に行いますが、これがない場合、機能する最も単純な構成は、各セッションCookieが大きい（64ビットで十分、128で十分）乱数が生成されることです 暗号的に安全なRNG に加えて、さらに メッセージ認証コード がその番号に署名します。これには対称MACを使用できます。これは、CookieはMACを発行したのと同じエンティティであるサイトによって認証される必要があるだけなので、どちらも同じ秘密を知っているためです。 Cookieに無効なMACが含まれている場合は、取得方法に関係なく、無視してください。まったく取得されていないふりをします。 （これは、HTTP経由で着信するCookieの無効化に関するルールにも優先します。攻撃者がリクエストを偽造することで強制的にログアウトできないようにする必要があります。）ただし、MACが有効な場合は、乱数をユーザーセッションに関連する実際の情報すべてを記録するデータベーステーブルのキー。
また、誰かがログインを試みるまでCookieをまったく発行しないこともベストプラクティスです。これにより、MITMが有効なCookieを入手することが非常に難しくなり、GDPRへの準拠が容易になります。
他の回答に関するディスカッションを読んだ後、私はOPが非常に特定のシナリオに関係していることに気づきました：サイトへの新しいユーザーは非常にアクセスしますHTTPSを終了し、HSTSを取り除いてすべてのリンクを書き換え、架空の新しいユーザーにサイトを暗号化せずに中継している中間者を介して初めて。これに対して、実際に役立つ可能性があるのはHSTSプリロードだけです。 HSTSプリロードが存在しない場合、新しいユーザーのアカウントは本来のように「危険にさらされて生まれ」、攻撃者はそれについてすべてを知っています。セッションCookieだけですが、ユーザー名とパスワード、アカウントの回復に使用されるメールアドレス、および被害者が入力したあらゆる個人情報です。これは厄介で、悲しいことに、あなたが思っているよりももっともらしいです。
しかし、積極的に改ざんされていないチャネルを介してユーザーとやり取りする機会が1つしかない場合は、HSTSをプッシュしてセッションCookieを保護できます。上記のアドバイスはすべて役に立ちます。