web-dev-qa-db-ja.com

HTTP応答本文内のセッションCookieの送信

セッションCookieを設定する安全な方法は、SecureフラグとHttpOnlyフラグを指定したSet-Cookieヘッダーを使用することです。しかし、HTTP応答（および要求）本体内でのCookieの送信にセキュリティ上の問題はありますか？たとえば、次のように：

HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 09:23:37 GMT
.........
.........
.........

sessioncookie=abcdefgh

また、Set-cookieを使用してCookieを設定し、同じHTTP応答でHTTP応答の本文も送信すると、セキュリティが低下しますか？

web-applicationcookiessession-management
6
ChildinTime

本文にCookieを設定する

cookies を応答の本文に設定することはできません（ブラウザーはCookieをそこから探しません）。また、ブラウザーは要求の本文にCookieを表示することもできません（サーバーはそこを探しません）。定義により、CookieはHTTPヘッダーで伝達されます（ RFC 6265 を参照）。

安全なデータを本文に入れる

リクエストまたはレスポンスの本文で他のセッションデータやトークンを送信することはできますが（例： CSRFトークン を本文で渡すのが一般的です）、そうする場合はCookieではありません。これが良いアイデアかどうかは別の問題です。

ほとんどのデータは本文では問題ありませんが、結局それはユーザーが表示できる唯一の部分であり、ユーザーには機密データを表示する必要がある場合があります。

ただし、一部のデータは本文で問題があります。たとえば、XSS攻撃で利用できないようにしたいものは、本文に含めることはできず、 Http-only cookie にのみ含める必要があります。 [〜＃〜] dom [〜＃〜] 。

とはいえ、一部のデータは本文の方が適しています。たとえば、デフォルトで表示したくないものIISログは本文に配置する必要があります。偽装リクエスト（CSRFとも呼ばれる）に乗るセッションに含めたくないものは、本体ではなく、クッキーとして含まれています。

両方にデータを設定する

Cookieと本文の両方にトークンを設定することは、必ずしもセキュリティ上の問題ではありません。実際、これは Double Submit Cookie CSRF緩和策 で必要なパターンとまったく同じです。

一方、本体のセッションIDを渡すだけで、それが HttpOnly cookie の複製である場合は、HttpOnlyを使用する利点をすべて無効にしています。同じ値をDOMから読み取ることができるため。

また、これは本当に楽しいものです：サイトがサーバー側からHttpOnly Cookieを設定し、同じCookie値がページ本体を介して渡され、クライアントスクリプトを介して設定された場合、ブラウザーは同じ名前の2つのCookieで終わります！この場合、どのCookieを提示する必要があるかを示すHTTP仕様がなく、ブラウザの動作が異なるため、この状態は回避する必要があります。

3
John Wu