HTTP 404が見つかりません。Set-Cookieディレクティブのレスポンスにキャッシュコントロールヘッダーが含まれています

Question

アプリケーションが404 Not Foundコードで応答する状況によっては、セッション識別子のSet-Cookieディレクティブも返されますが、プラグマディレクティブこれは、セッション識別子をブラウザキャッシュに格納できることを意味し、アプリケーションのセキュリティに影響しますか？ Set-Cookieのすべてのレスポンスにキャッシングディレクティブが含まれているかどうかはわかりません。

Answer 1

Cookieがブラウザに永続的に保存されているかどうかは、Expires and Max-Age propertiesによって制御されます。キャッシュ制御とプラグマヘッダーはページの内容にのみ影響します。だから私はあなたが明示的なキャッシュヘッダーがなくても、404ページでうまくいくと思います（*ただし、以下の編集を参照してください）。

セッションクッキーは、明示的な有効期限なしに設定する必要があります。この場合、セッションCookieは通常ディスクに保存されず、ユーザーがブラウザを終了すると削除されます。

（ユーザーが休止することを決定、またはコンピュータがメモリ不足と交換し始めたとき、メモリからそのようなデータはまだ例えばのように、ディスクに保存されますあなたのコントロールを超えた場合があることに注意してください。）

編集（コメントを参照してください）：クッキーを設定し、通常のページの場合は

、あなたは通常Cache-control: no-cache,no-store,must-revalidateなどの機密情報のキャッシュを防止するためのヘッダを持っています。私は本質的にはクッキーレスポンスをキャッシュしていないので、通常のページに明示的に設定する必要はありません。

したがって、404ページにどのようなCookieが設定されているのですか？認証されていないユーザーが404ページをダウンロードしてセッションCookieを取得した場合、そのCookieはセッション固定に対する脆弱性がないように（Cookie値はログオン時に変更される必要があるため）、攻撃者にとっては役に立ちません。認証されたユーザーの場合、アプリケーションがセッションCookieを再び設定するのはなぜですか404ページに？それがしても、キャッシュを防ぐためにヘッダーを送るべきです、それはSkipfishの良いキャッチです。 （実際には認証されていないユーザーに対してもこれを行うことができますが、そのリスクは非常に低いと評価します）。