【科普】关于Cookie的一点知识

1. Cookie的传输方式

Cookie是通过HTTP（超文本传输协议）和HTTPS（安全超文本传输协议）头部在服务器和客户端之间传输的。当服务器想要在客户端（通常是网页浏览器）上存储信息时，它会在HTTP响应头中包含一个Set-Cookie头部，这个头部包含了cookie的名称、值以及其他可选属性（如Expires、Max-Age、Domain、Path、Secure、HttpOnly和SameSite等）。然后，浏览器会存储这些信息，并在之后对该服务器的每次请求中通过HTTP请求头中的Cookie头部将其回传给服务器。

这是一个服务器响应示例，设置了一个cookie：

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value; Expires=Wed, 09 Jun 2021 10:18:14 GMT

而这是之后客户端请求服务器时，浏览器自动添加的请求头示例，包含之前设置的cookie：

GET /index.html HTTP/1.1
Host: www.example.com
Cookie: name=value

如果网站通过HTTPS运行，使用Secure属性的cookie将通过加密的方式传输，增加了数据传输过程中的安全性。此外，HttpOnly属性可以用来限制cookie仅通过HTTP(S)请求被传输，而不能通过客户端脚本访问，这有助于减少跨站脚本攻击（XSS）的风险。

2. 不设置Domain时的默认逻辑

当设置Cookie时，如果没有为Domain属性指定值，默认行为是将Cookie与设置它的服务器的完全限定域名(FQDN)关联。这意味着，如果没有明确设置Domain属性，Cookie仅会被发送到原始服务器而不会被发送到其他任何子域。

例如，如果您的服务器位于example.com，并且在设置Cookie时没有指定Domain属性：

Set-Cookie: name=value; Path=/

那么这个Cookie将只对来自example.com的请求可见。它不会对任何子域（如sub.example.com）可见。

然而，如果您设置了Domain属性为.example.com（注意域名前的点）：

Set-Cookie: name=value; Domain=.example.com; Path=/

这个Cookie则对example.com及其所有子域（如sub.example.com、another.sub.example.com等）可见。这种方式可以让Cookie跨多个子域共享。

需要注意的是，出于安全考虑，浏览器通常不允许将Cookie设置为顶级域名之外的域。例如，如果您尝试从example.com设置一个属于anotherdomain.com的Cookie，这种设置将会被忽略。此外，一些现代浏览器对第三方Cookie（来自不同于当前网页域的Cookie）有更严格的限制，这也需要在设计Cookie策略时考虑。

3. SameSite设置为None的风险

将Cookie的SameSite属性设置为None以允许跨站点请求发送Cookie确实带来了一些安全风险。SameSite属性是用来防止跨站点请求伪造（CSRF）攻击的，它允许服务器指定某个Cookie不应该随着来自第三方网站的请求被发送。当SameSite设置为None时，Cookie将在所有的请求中被发送，包括跨站点请求，这就增加了下列风险：

1. 跨站点请求伪造（CSRF）：如果Cookie不受到适当的保护（例如，没有使用CSRF令牌），那么攻击者可能会利用用户的登录态发起恶意请求。例如，如果用户登录了银行网站，然后访问了一个恶意网站，那么这个恶意网站可以在不知情的情况下发起跨站点请求，如尝试转账操作。

2. 跨站脚本攻击（XSS）：虽然SameSite=None本身不直接导致XSS攻击，但如果配合Secure属性未被设置（因为SameSite=None需要与Secure一起使用），在非HTTPS环境下，Cookie更容易被拦截。如果攻击者能够注入恶意脚本到网页上，他们可能利用这个漏洞窃取用户的Cookie。

3. 隐私泄露：由于Cookie将在所有的请求中被发送，用户的一些隐私信息可能会无意中泄露给第三方网站。这可能包括跟踪用户行为的Cookie，从而允许第三方创建用户的详细行为轮廓。

为了缓解这些风险，网站开发者应该：

• 只在确实需要跨站点Cookie时设置SameSite=None，并始终与Secure属性一起使用，确保Cookie仅通过安全的HTTPS连接被发送。
• 实施其他安全措施，比如使用CSRF令牌和XSS过滤，以进一步保护网站免受攻击。
• 审慎考虑哪些信息存储在Cookie中，避免存储敏感信息。

4. 通过IP访问时如何设置Cookie

通过IP地址访问网站时设置Cookie的方式与通过域名访问时相同。在HTTP响应头中使用Set-Cookie字段来设置Cookie。以下是一个设置Cookie的HTTP响应示例：

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionId=abc123; Path=/; Expires=Wed, 09 Jun 2021 10:18:14 GMT

在客户端，无论是通过域名还是IP地址访问，浏览器都会处理并存储服务器发送的Cookie，并在随后的请求中返回给服务器。

但是，需要注意几个重要的限制和最佳实践：

1. 安全性：如果您设置了Secure属性，意味着Cookie只能通过HTTPS协议发送。这意味着您的服务器必须配置SSL/TLS，即使是通过IP地址访问。

2. 作用域：通常，Cookie会与特定的域名关联。如果您通过IP地址设置Cookie，那么Cookie的Domain属性可能无法使用或者其行为可能与期望不同。在这种情况下，Cookie将默认与完全匹配的IP地址关联。

3. 跨域请求：如果您的网站使用了跨域资源共享（CORS）策略，并且您希望通过IP地址访问时也能发送Cookie，那么您需要确保CORS策略中包含了相应的IP地址，并且请求中包含credentials标志。

4. SameSite属性：如之前讨论的，SameSite属性可以控制Cookie的跨站点请求行为。SameSite=None; Secure将允许Cookie在跨站点请求中发送，但这通常用于具有明确域名的网站。通过IP地址访问时，依然可以设置这个属性，但实际上跨站点的概念可能不适用于纯IP访问的情况。

在实际部署时，出于安全和兼容性的考虑，推荐使用域名而不是裸IP地址来服务网站，并通过HTTPS提供服务。如果您必须通过IP地址设置和管理Cookie，那么您可能需要格外注意安全配置和测试，以确保一切按预期工作。