HTTP cookie端口是否特定？

206

當前的cookie規範是RFC 6265，它取代了RFC 2109和RFC 2965（這兩個RFC現在都標記爲「歷史」），並且形式化了cookie的真實用途。它明確規定：

簡介

...

由於歷史的原因，餅乾含有一些安全和隱私infelicities的。例如，服務器可以指示給定的cookie旨在用於「安全」連接，但是安全屬性在活動網絡攻擊者不存在時不會提供完整性。 類似地，即使Web瀏覽器使用的通常「同源策略」隔離通過不同端口檢索到的內容，給定主機的Cookie也會在該主機的所有端口之間共享。

而且也：

8.5。弱保密

Cookie不提供隔離端口。如果一個端口上運行的服務可以讀取一個cookie，那麼這個cookie也可以被在同一臺服務器的另一個端口上運行的服務讀取。如果一個cookie可由一個端口上的服務寫入，則該cookie也可由在同一服務器的另一個端口上運行的服務寫入。出於這個原因，服務器不應該在同一主機的不同端口上運行互不信任的服務，並使用cookie來存儲安全敏感信息。

來源

2013-05-02 00:09:34

1

這是可選的。

該端口可能被指定，因此cookie可以是端口特定的。沒有必要，Web服務器/應用程序必須關心這一點。

來源：German Wikipedia article，RFC2109，第4.3.1

來源

2009-10-23 08:57:28 guerda

+2

[聽起來就像是在現實生活中比這更復雜。]（http://stackoverflow.com/questions/1612177/are-http-cookies-port-specific/4212964#4212964） – bzlm 2011-09-12 13:31:36

18

這是cookie的SOP（同源策略）大的灰色地帶。

理論上，您可以指定域中的端口號，並且cookie不會被共享。實際上，這不適用於多個瀏覽器，您將遇到其他問題。所以這隻有在您的網站不適合普通公衆且您可以控制使用哪些瀏覽器時纔可行。

更好的方法是爲同一個IP獲取2個域名，而不依賴於cookie的端口號。

來源

2009-10-23 14:15:46

+7

它不是灰色的地區了。 [RFC 6265]（http://tools.ietf.org/html/rfc6265）是目前的Cookie標準，通過簡單地消除在使用不同端口的相同主機上分離cookie的能力，消除了對此的任何混淆。替代RFC 2965的 – 2013-05-02 00:16:03

112

根據RFC2965 3.3.1（其可能或可能不被隨後的瀏覽器），除非該端口經由Set-Cookie報頭的參數port明確指定，餅乾可能會或可能不會被髮送到任何端口。

谷歌的Browser Security Handbook說：默認情況下，cookie作用域限於當前主機名上的所有URL--並且不綁定到端口或協議信息。和稍後的一些行沒有辦法將cookie限制爲單個DNS名稱，同樣，也沒有辦法將它們限制到特定的端口。（同樣，記住，IE瀏覽器沒有在所有因素端口號到它的同源策略）

因此，它似乎並不安全在這裏依靠任何良好定義的行爲。

來源

2010-11-18 08:41:39 Tgr

+51

[RFC 6265]（http://tools.ietf.org/html/rfc6265）消除了'Set-Cookie'頭部中的'Port'參數（因爲在實際中幾乎沒有人實際使用它），並明確指出同一主機上的cookie不再被端口區分。 – 2013-05-02 00:12:51

+4

如果域名中有一個端口，IE 9甚至不會將cookie發回給後續請求 – axk 2013-09-04 10:42:15

+2

是否有任何瀏覽器仍在考慮cookie的SOP端口？ – Bertuz 2016-05-28 10:32:55

14

解決問題的另一種方法是使會話cookie的名稱與端口相關。例如：在端口8080

mysession8000運行在服務器上的端口上運行

mysession8080爲服務器8000

您的代碼可以訪問的網絡服務器配置，找出哪個端口您的服務器使用並相應地命名該cookie。

請記住，您的應用程序將收到這兩個cookie，並且您需要請求與您的端口相對應的一個。

沒有必要在cookie名稱中包含確切的端口號，但這樣更方便。

通常，cookie名稱可以編碼特定於您使用的服務器實例的任何其他參數，因此它可以通過正確的上下文進行解碼。

來源

2011-09-20 09:47:05

9

在IE 8中，Cookie（僅針對本地主機驗證）在端口之間共享。在FF 10中，他們不是。

我已經發布了這個答案，以便讀者至少有一個測試每個場景的具體選項。

來源

2012-02-16 15:51:27 Jeb

42

這是一個非常古老的問題，但我想我會添加一個我使用的解決方法。

我有兩種服務在筆記本上運行（一個在端口3000上，另一個在4000上）。當我在（http://localhost:3000和http://localhost:4000）之間跳轉時，Chrome會傳入相同的Cookie，每個服務都無法理解Cookie並生成新的cookie。

我發現如果我訪問了http://localhost:3000和http://127.0.0.1:4000，問題就消失了，因爲Chrome爲本地主機保留了一個cookie，一個用於127.0.0.1。

再次，沒有人可能在這一點上，但它很容易和有助於我的情況。

來源

2013-05-01 23:57:39 Pat

+0

是的，因爲cookie與主機/域名相關聯，所以'localhost'上的cookie不能與127.0.0.1共享，反之亦然。但是，無論端口如何，相同主機/域上的cookie都是可共享的。 – 2013-05-02 00:20:25

+0

這可能只適用於Chrome瀏覽器，因爲大多數其他瀏覽器不發送cookie到「本地主機」（=沒有兩個點的字符串） – Max 2014-03-06 11:35:25

+3

當然他們這樣做。我（可能還有其他數百萬開發人員）始終使用localhost進行測試。除非添加的端口有所作爲：http：// localhost：8080/ – 2014-06-12 10:08:52

2

我在同一臺機器上運行（並試圖調試）兩個不同的Django應用程序時遇到了類似的問題。

我用這些命令運行它們：

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

當我在第一個沒有登錄，然後在第二個，我總是得到了註銷第一個，反之亦然。

我說這對我的/etc/hosts文件

127.0.0.1 app1 
127.0.0.1 app2

然後，我開始了兩個應用程序使用這些命令：

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

問題解決了:)

來源

2013-08-21 10:32:47

+3

你可以使用'127.0.0.1：8000'作爲第一個，'localhost：8000'作爲第二個，也可能使用':: 1：8000'（也許是'[1]：8080'）必須觸摸主機文件。 – Travis 2013-09-06 22:06:45

+0

你可以把它放在一行：''':: 1 app1 app2 app3 app4 app5 appN''' – aeroson 2016-10-25 15:54:38

HTTP cookie端口是否特定？

回答

相關問題