HTTP Cookieはポート固有ですか?


355

1台のマシンで2つのHTTPサービスを実行しています。Cookieを共有しているかどうか、またはブラウザが2つのサーバーソケットを区別しているかどうかを知りたいだけです。

回答:


329

現在のCookieの仕様はRFC 6265であり、RFC 2109RFC 2965(両方のRFCが「Historic」としてマークされるようになりました)に取って代わり、実際のCookieの使用に関する構文を正式化しています。それは明確に述べています:

  1. 前書き

...

歴史的な理由から、Cookieにはセキュリティとプライバシーの問題が多数含まれています。たとえば、サーバーは指定されたCookieが「安全な」接続を対象としていることを示すことができますが、Secure属性はアクティブなネットワーク攻撃者が存在する場合の整合性を提供しません。 同様に、特定のホストのCookieは、そのホストのすべてのポートで共有されます。ただし、Webブラウザーで使用される通常の「同じ生成元のポリシー」は、異なるポート経由で取得したコンテンツを分離します。

そしてまた:

8.5。機密性が弱い

Cookieはポートによる分離を提供しません。あるポートで実行されているサービスがCookieを読み取ることができる場合、同じサーバーの別のポートで実行されているサービスもCookieを読み取ることができます。Cookieが1つのポートのサービスによって書き込み可能である場合、Cookieは同じサーバーの別のポートで実行されているサービスによっても書き込み可能です。このため、サーバーは、同じホストの異なるポート上で相互に信頼できないサービスを実行してはならず、Cookieを使用してセキュリティの機密情報を保存するべきではありません。


129

よるRFC2965ポートが明示で指定されない限り(またはブラウザが続いていない場合があります)3.3.1、portのパラメータSet-Cookieヘッダ、クッキーを、または任意のポートに送信されない場合があります。

Googleのブラウザセキュリティハンドブックによると、デフォルトでは、Cookieのスコープは現在のホスト名のすべてのURLに限定され、ポートやプロトコル情報にバインドされていません。いくつかの行以降Cookieを単一のDNS名のみに制限する方法はありません[...]同様に、Cookieを特定のポートに制限する方法はありません。(また、IEはポート番号を同じ生成元のポリシーに一切含めないことに注意してください。)

したがって、ここで明確に定義された動作に依存するのは安全ではないようです。


75
RFC 2965に取って代わるRFC 6265Portは、Set-Cookieヘッダー内のパラメーターを排除し(実際にはほとんど誰も使用していないため)、同じホスト上のCookieがポートによって区別できないことを非常に明確にしています。
レミールボー・

5
IE 9は、ドメインにポートがある場合、後続のリクエストでCookieを送り返すことさえしません
axk

3
CookieのSOPでまだポートを検討しているブラウザーはありますか?
Bertuz、2016年

5
ドメインにポートがある場合、ChromeはCookieを設定しません。
Pim Heijden 2017

76

これは本当に古い質問ですが、使用した回避策を追加したいと思いました。

ラップトップで2つのサービスを実行しています(1つはポート3000、もう1つは4000)。(http://localhost:3000http://localhost:4000)の間をジャンプすると、Chromeは同じCookieを渡し、各サービスはCookieを理解せず、新しいCookieを生成します。

http://localhost:3000and にアクセスするとhttp://127.0.0.1:4000、Chromeがlocalhostと127.0.0.1のCookieを保持しているため、問題は解消されました。

繰り返しますが、この時点では誰も気にしないかもしれませんが、それは簡単で私の状況に役立ちました。


1
はい。Cookieはホスト/ドメイン名に関連付けられているため、Cookieはとlocalhost共有できず127.0.0.1、その逆も同様です。ただし、ポートに関係なく、同じホスト/ドメイン上のCookieは共有可能です。
レミールボー2013年

3
もちろんそうです。私(そしておそらく他の何百万人もの開発者)は常にlocalhostをテストに使用しています。追加されたポートに違いがない限り:localhost:8080
DavidBalažicJun

53
また、127.0.0.1、127.0.0.2、127.0.0.3などを使用できます。これらはすべてローカルホストを意味します。
DavidBalažic2014年

3
質問に答えないので、これに賛成することはできませんが、それは素晴らしいヒントです、ありがとう!
マーティンT.

2
hostsファイル(UNIXでは/ etc / hosts)を編集する場合は、localhostに好きなだけ意味のある名前を付けることができます。
Silas S. Brown

20

これは、Cookie SOP(Same Origin Policy)の大きな灰色の領域です。

理論的には、ドメインでポート番号を指定でき、Cookieは共有されません。実際には、これはいくつかのブラウザーでは機能せず、他の問題に遭遇します。したがって、これは、サイトが一般向けではなく、使用するブラウザを制御できる場合にのみ実現可能です。

より良いアプローチは、同じIPに対して2つのドメイン名を取得し、Cookieのポート番号に依存しないことです。


9
もはや灰色の領域ではありません。現在のCookie標準であるRFC 6265は、異なるポートを使用して同じホスト上のCookieを分離する機能を単に排除することにより、それに関する混乱を排除します。
レミールボー2013年

18

問題を回避する別の方法は、セッションCookieの名前をポートに関連させることです。例えば:

  • ポート8080で実行されているサーバーのmysession8080
  • ポート8000​​で実行されているサーバーのmysession8000

コードはWebサーバー構成にアクセスして、サーバーが使用するポートを見つけ、それに応じてCookieに名前を付けることができます。

アプリケーションは両方のCookieを受け取り、ポートに対応するCookieをリクエストする必要があることに注意してください。

Cookie名に正確なポート番号を含める必要はありませんが、これはより便利です。

一般に、Cookie名は、使用するサーバーインスタンスに固有のその他のパラメーターをエンコードできるため、適切なコンテキストでデコードできます。


9

IE 8では、cookie(localhostに対してのみ検証)はポート間で共有されます。FF 10では、そうではありません。

読者が各シナリオをテストするための少なくとも1つの具体的なオプションを持つように、この回答を投稿しました。


4

同じマシン上で2つの異なるDjangoアプリケーションを実行している(そしてデバッグしようとしている)同様の問題が発生していました。

私はこれらのコマンドでそれらを実行していました:

./manage.py runserver 8000
./manage.py runserver 8001

最初のログインでログインしてから2番目のログインでログインすると、常に最初のログインからログアウトし、その逆もありました。

これを私の/ etc / hostsに追加しました

127.0.0.1    app1
127.0.0.1    app2

次に、これらのコマンドで2つのアプリを起動しました。

./manage.py runserver app1:8000
./manage.py runserver app2:8001

問題が解決しました :)


4
おそらく127.0.0.1:80001つ、1 localhost:8000秒、おそらく::1:8000(たぶん[::1]:8080)3回目は、hostsファイルを変更する必要なく使用できます。
Travis Watson

1
あなたはそれを一行に入れることができます:::1 app1 app2 app3 app4 app5 appN
aeroson '25 / 10/25

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.