HTTP cookies是否特定于端口?

当前的cookie规范是 RFC 6265 ,替换 RFC 2109 和 RFC 2965 (这两个RFC现在都被标记为“历史性的”)并将cookie的实际用法的语法形式化。它清楚地说明:

1. 介绍

…

出于历史原因,cookies包含许多安全和隐私不合法的行为。例如,服务器可以指示给定的cookie用于“安全”连接,但安全属性在存在活动网络攻击者时不提供完整性。 同样,给定主机的cookie在该主机上的所有端口之间共享,即使Web浏览器使用的常规“相同源站策略”隔离了通过不同端口检索的内容。

还有:

8.5。保密性差

cookie不提供端口隔离 .如果在一个端口上运行的服务可以读取cookie,那么在同一服务器的另一个端口上运行的服务也可以读取cookie。如果一个cookie可由一个端口上的服务写入,则该cookie也可由在同一服务器的另一个端口上运行的服务写入。因此,服务器不应在同一主机的不同端口上运行相互不信任的服务,也不应使用cookie存储安全敏感信息。

根据 RFC2965 3.3.1(浏览器可能会或可能不会跟随浏览器),除非通过 port 的参数 Set-Cookie 头、cookie可能会或可能不会发送到任何端口。

谷歌的 Browser Security Handbook 说: 默认情况下,cookie作用域仅限于当前主机名上的所有URL,而不绑定到端口或协议信息。 以后还有几句台词 没有办法只将cookie限制为一个DNS名称[…],同样,也没有办法将cookie限制为一个特定的端口。 (另外,请记住,IE不将端口号考虑到其相同的来源策略中 完全 。)

因此,在这里依靠任何明确的行为似乎都是不安全的。

这是一个非常古老的问题,但我想我会添加一个我使用的解决方案。

我在笔记本电脑上运行两个服务(一个在3000端口,另一个在4000端口)。 当我跳到( http://localhost:3000 和 http://localhost:4000 ,chrome将传入同一个cookie,每个服务将无法理解该cookie并生成新的cookie。

我发现如果我进入 网址:http://localhost:3000 和 http://127.0.0.1:4000 因为chrome为localhost保存了一个cookie,为127.0.0.1保存了一个cookie,所以问题就消失了。

再说一次,在这一点上没有人会在意,但这对我的处境很容易也很有帮助。

这是cookie sop(同一来源政策)中的一个大灰色区域。

理论上,您可以在域中指定端口号,cookie将不会被共享。实际上,这在多个浏览器中不起作用,您会遇到其他问题。因此,只有当你的网站不面向公众,你可以控制使用什么浏览器时,这才是可行的。

更好的方法是为相同的IP获取2个域名,而不依赖cookie的端口号。

解决这个问题的另一种方法是使会话cookie的名称与端口相关。例如:

• MyScript 8080 对于在端口8080上运行的服务器
• MyScript 8000 对于在端口8000上运行的服务器

您的代码可以访问Web服务器配置,找出服务器使用的端口,并相应地命名cookie。

请记住,您的应用程序将同时接收两个cookie,您需要请求与您的端口对应的cookie。

不需要在cookie名称中有确切的端口号,但这样更方便。

通常,cookie名称可以编码特定于您所使用的服务器实例的任何其他参数,因此可以通过正确的上下文对其进行解码。

在IE 8中,cookie(仅针对localhost验证)在端口之间共享。在FF 10中,它们不是。

我已经发布了这个答案,这样读者至少可以有一个具体的选项来测试每个场景。

我在同一台机器上运行(并尝试调试)两个不同的Django应用程序时遇到了类似的问题。

我用这些命令运行它们:

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

当我在第一个登录,然后在第二个登录时,我总是先注销第一个和维切弗萨。

我在我的 /ETC/主机

127.0.0.1    app1
127.0.0.1    app2

然后我用以下命令启动了这两个应用程序:

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

问题已解决:)

这是可选的。

可以指定端口,以便cookie可以是特定于端口的。没有必要,Web服务器/应用程序必须注意这一点。

来源: German Wikipedia article , RFC2109 第4.3.1章