すべてのCookieをhttponlyで安全に使用するように設定しない理由

Question

サイトが常にすべてのHTTPSを使用していると仮定すると（LBはポート80を443にリダイレクトします）、アプリケーションによって設定されたすべてのCookieがsecure AND httponlyの両方を使用することを強制しない理由はありますか？

現在、たとえば、PCIスキャンはjsessionidにsecure属性を使用しないものとしてのみフラグを立てますが、明日はもう1つになる可能性があるため、私はそれより先に進んでいます。

Jonathan · Accepted Answer

はい、HTTP ONLYまたはSECUREを使用したくない場合があります。

HTTPのみの場合は、JavaScriptがCookieと対話することをお勧めします。たぶん、あなたはCookieでページの状態を追跡し、JSでCookieに書き込み、そしてJSから読み込みます。また、httpだけではないcookieを使用して実装されたCSRFをよく目にします。

セキュアCookieの場合、次の2つの場合を除いて、Cookieがセキュア属性を持たないことを期待しません。

多くの場合、開発環境にはTLS証明書がないか、または必要です（おそらく必要です）
httpで発生したアクティビティを追跡する。ロードバランサーを使用して、リダイレクトを送り返す前に、安全でないcookieを設定することもできます。その後、アプリケーション分析は、どのURLがHTTPとして着信したかを追跡できます。

実際には、httpsサイトを実行している場合は、常に安全なcookieを設定します。JSの要件がわからない場合は、常にHTTPONLYが設定されている側のエラー。

アドレスコメントへの更新

本番環境でTLSを使用する必要があるかどうかについて多くの話があります。ここに質問を投稿しました：

TLSをオンまたはオフにして開発する必要がありますか？

Steffen Ullrich · Answer

httponlyについては、JavaScriptでCookieの読み取りまたは設定が必要なユースケースかどうかを本質的に尋ねています。通常、ユーザーインターフェイスの一部の設定（言語の選択...）はこの方法で保持されますが、Cookieがhttponlyの場合は無効になります。

secureと同様：あなたの説明によると、サイトは常にhttpsを使用しているため、すべてのcookieを保持しても害はありませんsecure。

Tony Thomas · Answer

セキュアフラグ

アプリケーションがHTTPSで実行されていること、つまりLBがすべてのポート80トラフィックを443にリダイレクトすることを考えると、次のシナリオに照らしてセキュアフラグを有効にする必要があります。

ハイパーリンクにHTTPS（たとえば http://example.com/some_page.php ）リンクが含まれている結果として発生した問題があると仮定します（例： https://example.com/some_page.php ）リンク。
セキュアフラグがないため、ブラウザはHTTP経由でWebリソースを要求し、それとともにCookieを送信します。
リクエストはLBに到達し、トラフィックがポート443に、つまりHTTPS経由でリダイレクトされます。
ブラウザはリクエストを再起動しますが、今回はHTTPS経由でcookie値を使用します。

したがって、LBはポート80の安全でないトラフィックをポート443の安全なトラフィックにリダイレクトするように構成されていますが、step 2でMiTM攻撃が成功し、機密性の高いCookieを盗むことでユーザーのなりすましが行われる可能性があります。さらに、ハイパーリンクとリダイレクトが適切にコード化されていることを確認することは、機密性の高いCookieでセキュアフラグを有効にすることよりも、比較的困難な作業です。結論として、リダイレクトはLBレベルで設定されていますが、安全なフラグがないために実りのあるMiTMが実行される可能性のあるシナリオが存在する可能性があります。

httponlyフラグ

これは、その重要性がトランスポート層セキュリティ（SSL/TLS）から独立しているフラグです。 httponlyフラグは、クロスサイトスクリプティング（XSS）攻撃が成功した場合に、JavaScriptがセッションCookieなどの機密Cookieにアクセスできないようにするために使用されます。 httponlyフラグがcookie値に設定されていない場合、アプリケーションレベルの欠陥によりアプリケーションに挿入された悪意のあるJavaScriptは、セッションCookieを読み取り、リモートサーバーに送信するなどして、ユーザーアカウントの機密性、整合性、および可用性を妨害する可能性があります。、それにより、正当なユーザーになりすますことに成功しました。したがって、httponlyフラグは常にすべてのCookieまたは少なくとも機密性の高いCookieに設定する必要があります。

Tschallacka · Answer

Httponlyでないcookieの実際的な例を紹介します。

訪問者が私のサイトにアクセスすると、2つのクッキーが喉に押し込まれます。

phpsession -> secure httponly samesite:lax cookie_law -> secure samesite:lax

cookie_lawには、cookie設定を格納する、base64エンコードされたjsonエンコードされたcookieオブジェクトが含まれています。

私のJavaScriptは、これらのCookieを読み取って、許可またはステータスに応じて、アナリティクスをロードすることを決定します。
私のJavaScriptもそのCookieを使用して、Cookie設定エディターを機能させます。

Cookieにhttponlyフラグを設定すると、JavaScriptはそれを読み取ることができません。また、キャッシュの複数のレイヤーがあるため、スクリプトをレンダリングするときにphpを使用してロードステータスを判断することはできません。それが、そのcookieからhttponlyを残すことにした理由です。

JavaScriptはそれを読むことができるようにアクセスを必要とします。

David Spillett · Answer

http-only：時には、ユーザー設定（フォントサイズ、テーマ、言語など）が設定され、クライアント側で実行されます。これは、httpのみを設定しないようにする必要がある最も一般的なケースです。

secure：サイト/アプリがHTTPSを要求するため、secureフラグを使用する理由はありません。サイト/アプリがHTTP経由のアクセスを提供する必要があり、暗号化された/コンテキストなしの間で渡す詳細が必要な場合（おそらくユーザーの表示設定を再度）、これをオフにする必要があります。

現在HTTPSアクセスを強制しているため問題ではないように見えるかもしれませんが、失敗を許容する必要があります：アプリが誤った設定で再デプロイされるか、ユーザーがMItM（悪意のあるまたは不適切に設定されたプロキシのいずれか）の対象となる場合があります）同様の効果があり、このフラグが設定されていると、安全ではない作業ではなく作業を停止することにより、（セキュリティの観点から）物事が安全に失敗します。

全般：セキュリティ対策であるため、どのように軽微に見えるかもしれませんが、特別な理由がない限り、常に両方とも設定してください。