安全でないCookie接続を安全でないHTTP接続から設定できますか？もしそうなら、なぜそれは許可されていますか？
私が読んだいくつかのセキュリティペーパーを参照して、セキュアフラグが設定されたCookieは、HTTPではなくHTTPSを使用している接続を介してのみクライアントから送信できるが、Cookie自体はサーバーからセキュアに設定できることがわかりました安全でないHTTP接続からのフラグ。なぜ許可されるのですか？
安全なCookieは、安全でないチャネル（HTTPなど）を介して設定できます RFC 6265のセクション4.1.2.5 。セキュアフラグが設定されたCookieは依然としてセキュアでないチャネルから設定され、以前に設定された値を（セキュアチャネルなどを介して）上書きできるため、セキュアフラグは機密性のみを提供し、整合性は提供しないことを明確に述べています。
Secure属性は、Cookieの範囲を「セキュア」チャネルに限定します（「セキュア」はユーザーエージェントによって定義されます）。 CookieにSecure属性が設定されている場合、ユーザーエージェントは、要求がセキュリティで保護されたチャネル（通常はHTTP over Transport Layer Security（TLS）[RFC2818]）経由で送信される場合にのみ、HTTP要求にCookieを含めます。
Secure属性は、アクティブなネットワーク攻撃者からCookieを保護するのに役立つように見えますが、Cookieの機密性のみを保護します。アクティブなネットワーク攻撃者は、安全でないチャネルからセキュアCookieを上書きして、整合性を破壊する可能性があります（詳細については、セクション8.6を参照）。
セクション8.6 はいくつかの例を示していますが、セクションの長さが長いため、ここにはコピーアンドペーストしません。
理由については、私が認識している明確なユースケースはありません。 RFCは、機密性を保護するという目的onlyを持ち、したがってHTTP経由で設定されたときに安全なフラグ付きCookieが受け入れられないようにするという観点から記述されたと思いますその目標にとって不必要な制限でした。私の推測では、理論的根拠は「この機能を提供する場合、Cookieの整合性はSecureフラグによって保護されていると思われる可能性があり、そのような想定を望まない」というものでした。
とはいえ、データが安全でないチャネルを介して設定できるという事実は、安全なチャネルを介してCookie値のみを送信するという概念をある程度否定するため、決定の感度は議論の余地があります。 RFCは、これを行うと機密性が失われることを少なくとも述べています。
引用 rfc2965 多項式が言及した rfc6265 によって廃止されました：
安全
オプション。 Secure属性（値なし）は、ユーザーエージェントに対して、（指定されていない）安全な手段のみを使用して、このCookieを送り返すときに常にOriginサーバーに接続し、Cookie内の情報の機密性と信頼性を保護するように指示します。
ユーザーエージェント（おそらくユーザーインタラクションを伴う）は、「安全な」Cookieに適切と見なすセキュリティのレベルを決定できます（MAY）。 Secure属性は、サーバーからユーザーエージェントへのセキュリティアドバイスと考える必要があります。これは、Cookieの内容を保護することがセッションの利益になることを示しています。 「安全な」Cookieをサーバーに送信する場合、ユーザーエージェントは、サーバーからCookieを受信したときに使用したものと同じレベルのセキュリティ以上を使用する必要があります。
（強調鉱山）
私の解釈では、クライアントに向かう途中でサーバーがセキュリティを処理し、クライアントにも同じようにする必要があることを伝える方法が必要でした。
実際、多項式の回答で述べたように、結果は疑わしいものです。
このドキュメントがRFCのどこにあるかという質問は十分に回答されています。
しかし、なぜ？
他のセキュリティ機能と同様に、この特定の機能（「安全なCookie」）には、傍観者/傍受者がCookieを取得しないようにするという1つの目標しかありません。
これは、あらゆる種類のCookie攻撃に対する万能薬であることを意味するのではなく、次の非常に特殊な攻撃のみを対象としています。
- ブラウザーは、サーバーにいくつかの資格情報を（安全な接続を介して）提示します。
- サーバーはセッションを作成し、Cookieを（安全な接続を介して）引き渡します。
- ブラウザは、さらに安全な接続を介して、リクエストを送信してセッションCookieを送り返します。
- 攻撃者はどういうわけか、元のサーバーへの安全でない接続をブラウザーに行わせることができます。
- 攻撃者はHTTPリクエストを傍受し、Cookieを入手します。
1.、2、3は4./5よりも攻撃が難しいと想定できます。
ブラウザによっては、ログインフォームにHTTPS URLとURLの横に「緑の旗」が表示されることを確認するようにユーザーがトレーニングされている場合があります。資格情報を入力するときに、賢明なユーザーは最近、URLに注意を払うことを合理的に期待できます。 （これが通常のメールスパム攻撃の仕組みです。だまされて、任意のURL（別の日のトピック）でユーザー名/ pwを入力します。）
サーバーにバグがない限り、攻撃するのは非常に困難です。サーバーは、接続がHTTPかHTTPSかを完全に把握しているため、HTTPS経由の場合にのみセッションを作成します。本当に重要なシステムは、とにかくHTTPをリッスンしない方がよいでしょう。
通常のリクエストを攻撃する必要はありません。彼らは安全なHTTPS接続を介して行き、すべてがうまくいくでしょう。
ブラウザを任意のURLに接続するのは非常に簡単です。タグをどこかに配置するか、可能であれば発射してくださいAJAX可能であれば。サーバーによっては、静的画像などを安全でない接続にオフロードして保存してもかまいませんCPUなので、攻撃者は何もする必要はありません。
したがって、このシナリオは安全なCookieによって回避されます。 CookieはHTTPS経由でのみ送信されるため、攻撃者はCookieを盗聴することはできません。
もちろん、まだCookieを取得する他の攻撃ベクトルはたくさんあります（HTTPSに対する中間者。代わりにJavaScriptでそれを読み取ります（ "httponly"フラグによって防止されます）。緩やかなCookieを使用する攻撃者（Same-OriginポリシーまたはCookieドメインをサーバー側に正しく設定することで防止されたなど）。
4から保護するのは難しいことに注意してください。ブラウザが任意のURLを要求するのは非常に簡単です。 valid URLを実際に要求する必要はないことに注意してください。ブラウザに必要なのは、HTTP要求（Cookieを含む）を送信することだけです。結果を気にしなくても、HTTPをまったくリッスンしないこと、つまりTCP/IPポートを開かないことを除いて、サーバーがブラウザが安全でないリクエストを最初から送信するのを防ぐことは不可能です。しかし、これでも十分ではありません。ユーザーがプロキシ（企業のイントラネットでは一般的）を経由する場合、ブラウザは引き続きプロキシに（HTTPを介して）HTTP要求を送信し、ブラウザとプロキシの間を盗聴する攻撃者は、たとえ実際のサーバーはTCP/IP接続を受け入れませんでした。
TL; DR
「安全な」クッキーは、さもなければ保護することが不可能である非常に特定の問題から保護することを意図しています。
そもそも、安全でないチャネルを介してCookieを送信する、バグの多い、遅延した、または誤って構成されたサーバーから保護することを意図したものではありません。
このようにすること（つまり、特定の攻撃に対する1つの機能）は良いことであり、それがほとんどのセキュリティ機能が行うことです。このような機能がどのような種類の攻撃を行うかについて推論することが期待されますnot防御;機能の範囲が限られているため、この推論はかなり簡単です。
現在、Web上では、多くのブラウザーとそのユーザーが通常、セキュリティで保護されていない（HTTP）接続を介してWebリソースにアクセスしようとすることを受け入れなければなりません。
そのため、Secure cookieフラグを設定したcookieをいつ設定できるかに関して、 RFC に多少の余裕があります。具体的には、はい。HTTP接続を介して設定している場合でも、Secureフラグを使用してCookieを設定することが許可されています。
セキュアフラグはセキュリティを強化するためにのみ機能するため、技術的またはセキュリティの観点からこれが機能しないようにする理由はありませんが、これを行うのは良い考えではありません。効率の観点からは、必要な認証情報（Secureフラグ付きのCookie内）でログインリクエストに応答し、新しい認証Cookieが実際に送信されるHTTPSにユーザーをリダイレクトするのが妥当です。
この時点で、HSTSヘッダーも送信された可能性があるため、ブラウザーは今後HTTPの使用を再試行せず、将来のCookie上書き攻撃を軽減します。
この時点で、攻撃者が最初のCookieデータを傍受し、それを使用してユーザーになりすます可能性があると考えるのは当然です。これは理想的ではありません。ただし、HTTPを介してサイトに接続し、攻撃者がこのヘッダーを改ざん/削除せずにHSTSヘッダーを受信するユーザーに依存します。そのため、HSTSをプリロードしています。このため、Cookieセキュアフラグのプリロードは興味深いコンセプトです。
Cookieを設定した後、ネットワーク攻撃に関するユーザーへの唯一のリスクは、問題のドメインに対するHSTS指示がないことです。次に、攻撃者はユーザーに認証解除を強制し（おそらくSSLトラフィックをブロックし、ユーザーがHTTP接続を開始する可能性が最も高い場所にアドレスを新たに入力するのを待つ）、認証資格情報またはトークンを傍受し、安全なフラグを立てて、HTTPSリダイレクトがクライアントで発生しないようにします（必要に応じて、サーバーにそれをネゴシエートする可能性があります）。
これは、基本的にHTTPS暗号化の不足が原因でインターネット接続が改ざんされた場合など、特定の状況でのセキュリティに役立ちます。ただし、ほとんどの場合、Cookieインジェクションは、他の危険にさらされた機能と比較して、懸念のリストに載っていません。
現在、HTTPプロトコルは、クライアントがCookieに関するメタデータを提供する方法を提供していません。
たとえば、Cookieがpath=/で設定され、後でpath=/narrow-scopeで設定された場合、サイトにアクセスして/narrow-scope URLにアクセスすると、両方のCookieが送信されます：Cookie: name=valueA, name=valueB。
サーバーは、各Cookieに使用された特定のパスを特定できません。それらの間のメタデータが異なることだけが異なります。そうでない場合、それらは同じCookieと見なされます（同じnameを持つ）
同様に、CookieがSecureフラグが設定されているかHttpOnlyであるかをマークする方法はありません。メタデータはクライアントからサーバーに渡されません。
HTTPページが安全なCookieを設定しないようにするには、2つの可能性があります。
HTTPSページにアクセスすると、HTTPが提供するすべてのCookieにアクセスできなくなります。これは互換性の重大な中断となるでしょう。
Orメタデータがクライアント提供の
Cookie値に追加されるため、サーバーはそれについていくつかのことを知ることができます。たとえば、サーバーはJavaScriptを介して設定されたCookieを区別したい場合があります。または、あなたが言うように、それがHTTPSまたはHTTP内で設定されたかどうか。これは大きな変化であり、それほどの需要はありません。また、ほとんどの場合、セキュリティ機能とは異なります。
最終的に正しい解決策は ユーザーにHTTPS接続を使用することを強制する です。