跳到主要内容

关于 cookie 那点事

  • name:

    cookie 的名称，cookie 一旦创建，名称就不能改

  • value:

    cookie 的值

  • maxAge:

    cookie 失效的时间，单位秒。如果为正数，则该 cookie 在 maxAge 秒之后失效。

    如果为负数，该 cookie 为临时 cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie。

    如果为 0，表示删除该 cookie。

    默认为-1。

  • secure:

    该 cookie 是否仅被使用安全协议传输。安全协议。安全协议有 HTTPS，SSL 等，在网络上传输数据之前先将数据加密。默认为 false

  • path: cookie 的使用路径。如果设置为/test/，则只有 contextPath 为/test 的程序可以访问该 cookie。

    如果设置为/，则本域名下 contextPath 都可以访问该 cookie。注意最后一个字符必须为/。

  • domain:

    可以访问该 cookie 的域名。如果设置为.github.io，则所有以 github.io 结尾的域名都可以访问该 cookie。注意第一个字符必须为.。

    关于 Secure 属性

    当设置为 true 时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证。但即便设置了 Secure 标记，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其固有的不安全性，Secure 标记也无法提供确实的安全保障。从 Chrome 52 和 Firefox 52 开始，不安全的站点（http:）无法使用 Cookie 的 Secure 标记。

    关于 HttpOnly 属性

    如果在 Cookie 中设置了 HttpOnly 属性，那么通过程序(JS 脚本、Applet 等)将无法读取到 Cookie 信息。

对于以上两个属性，

首先，Secure 属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly 属性的目的是防止程序获取 cookie 后进行攻击。但并不能解决 Cookie 在本机出现的信息泄漏的问题，毕竟 Chrome 也好 FireFox 也好，都可以直接看到 Cookie 的相关信息。

背景问题​

前一段时间做了一个业务上的修改，(以下均为举例) 原始在 violatangxl.github.io 下有个名为 XXX_id 的 cookie （生成机制，简单理解成一个带有时间戳的字段吧，每次生成结果都不一致），因为某些原因，想把该 cookie 的 domain 扩大到 github.io。

简单想着，嗨，就是一个把 cookie 的 domain 扩大的情况，应该不会有什么问题。结果 run 起来发现一个“意料之中”的情况: 因为之前的 cookie 没有清，导致不同域名下，有两个相同的名称的 cookie。因为不同的后端服务，读取到的 XXX_id 不同，导致线上崩了。

原因与收获​

回归主题，上面说出现了两个同名不同 domain 下的 cookie，然后不同的后端服务，读取 cookie 的顺序又不同，导致出现了 bug。 通过这次事故，这里有几个小点需要备注一下：

不同 domain 下，同名的 cookie，后端都会收到，不会说有什么 domain 的优先级，导致后端只收到“优先级高”的一个。

后端取到的，只有 cookie 的 name 与 value，所以拍脑袋想通过 domain 过滤出需要的 cookie 是不可取的

参考一下 RFC6265 HTTP State Management Mechanism 传递到后端的 cookie 顺序不一定。（原文意思是后端不应该依赖 cookie 的顺序）

但在 chrome 测试，发现后端收到 cookie 还是有一个稳定的顺序的：path 更长的 cookie 更靠前，path 相等的，更早创建的 cookie 更靠前

原文链接：https://violatangxl.github.io/2021/01/19/same-name-cookie/