如何保障Cookie的信息安全

一、支持策略

保障 Cookie 的安全性可以从以下几个方面进行：

1. 使用 HttpOnly 属性：设置 HttpOnly 属性可以防止JavaScript Document.cookie API 无法访问带有 HttpOnly 属性的 cookie；此类 Cookie 仅作用于服务器。例如，持久化服务器端会话的 Cookie 不需要对 JavaScript 可用，而应具有 HttpOnly 属性。此预防措施有助于缓解跨站点脚本（XSS） (en-US)攻击。

   Set-Cookie: id=value; HttpOnly
   

2. 使用 Secure 属性：设置 Secure 属性可以保证 Cookie 只在 HTTPS 连接中传输，防止在数据传输过程中被窃取。

   Set-Cookie: id=value; Secure
   

3. 设置 SameSite 属性：SameSite 属性可以防止跨站请求伪造（CSRF）攻击。它有三个值：Strict、Lax 和 None，默认值为Lax。如果设置为 Strict，Cookie 将只在同一站点请求中发送；如果设置为 Lax，Cookie 在导航到目标站点的 GET 请求中，或者在同一站点的请求中，Cookie 会被发送；如果设置为 None，Cookie 会在所有请求中发送，仅支持设置了 Secure 属性的HTTPS站点。注意：各浏览器处理策略可能不同

   Set-Cookie: id=value; SameSite=Strict
   

4. 设置正确的过期时间：默认的cookie生命周期为临时，仅会话期间存在，不应该设置过长的 Cookie 过期时间，以减少 Cookie 信息被盗用的风险。

5. 使用 Cookie 加密：对敏感信息，如 session ID，进行加密后再存储到 Cookie 中，即使 Cookie 信息被窃取，攻击者也无法获得真正的内容。

6. 限制 Cookie 的作用域：通过设置 Cookie 的 Domain 和 Path 属性，限制 Cookie 的作用域，防止其在其他子域或路径下被发送。

   Set-Cookie: id=value; Domain=example.com; Path=/blog
   
   # 支持一级泛域名
   Set-Cookie: id=value; Domain=.example.com 
   
   # 支持多个泛域名
   Set-Cookie: id=value; Domain=.example1.com
   Set-Cookie: id=value; Domain=.example2.com
   

以上都是保护 Cookie 安全的一些常见手段，但需要注意的是，这些措施并不能保证 100% 的安全，因为 Cookie 本质上是存在客户端的，其安全性始终无法得到完全保障。在设计系统时，应尽量减少对 Cookie 的依赖，或者使用其他更安全的技术，如 Token、JWT 等。

二、注意点

2.1 SameSite 和 域（Domain）有啥区别？

SameSite 和 域（Domain） 是 Cookie 的两个属性，它们在 Cookie 的工作方式和安全性方面起着重要的作用。下面是它们各自的定义和作用：

1. SameSite：

SameSite 是一个相对较新的 Cookie 属性，用于防止跨站点请求伪造（CSRF）。它有三个可能的值：Strict、Lax和None。

• Strict：Cookie 只有在同一个站点的请求中才会被发送。
• Lax：在导航到目标站点的 GET 请求中，或者在同一站点的请求中，Cookie 会被发送。
• None：Cookie 在所有请求中都会被发送，无论是跨站点还是同站点。

1. 域（Domain）：

Domain 属性定义了哪些网站可以接收 Cookie。如果没有指定，那么默认值就是创建 Cookie 的网页所在的站点。

• 如果设置了 Domain，那么所有的子域也都可以接收 Cookie。例如，如果设置了Domain=example.com，那么sub.example.com也可以接收 Cookie。
• 如果没有设置 Domain，那么只有创建 Cookie 的站点可以接收 Cookie。

所以，SameSite 和 Domain 在 Cookie 的安全性和可访问性方面起着重要作用，但它们的工作方式是不同的。SameSite 控制 Cookie 是否可以在跨站点请求中发送，而 Domain 控制哪些站点可以接收(读) Cookie。

2.2 cookie的生命周期

Cookie 的生命周期主要由其设置的过期时间决定。以下是 Cookie 生命周期的一些基本信息：

• 会话Cookie：如果不设置过期时间，或者设置的过期时间为0，那么这个 Cookie 就是会话 Cookie。会话 Cookie 是临时的，当用户关闭浏览器时，这个 Cookie 就会被删除。

Set-Cookie: id=a3fWa; Expires=0; Secure; HttpOnly

• 持久Cookie：如果在 Cookie 中设置了过期时间，那么这个 Cookie 就是持久 Cookie。即使用户关闭了浏览器，这个 Cookie 也会被保留，直到达到设置的过期时间，此后就会被浏览器删除。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly

• 删除Cookie：如果想要删除 Cookie，可以通过设置过期时间为过去的某一时间来达到删除的效果。

Set-Cookie: id=a3fWa; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly

以上就是 Cookie 的生命周期的一些基本信息。

2.3 XHR 请求中对 Cookie 的处理策略

对于同源请求，浏览器会默认带上 cookie，无法通过设置 withCredentials=false 来取消

在进行 AJAX 域请求时，如果你不想带上 cookie，你可以在创建 XMLHttpRequest 对象时，设置 withCredentials 属性为 false。这样，浏览器在发送 AJAX 请求时就不会带上 cookie。

以下是一个简单的示例：

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://www.example.com/', true);
xhr.withCredentials = false; // 不带 cookie，默认值即是false
xhr.send(null);

2.4 Fetch 请求中对 Cookie 的处理策略

fetch API 中 credentials 的默认值是 "same-origin"。

这意味着默认情况下，只有对同源的请求才会包含凭据（例如cookies，HTTP认证，客户端SSL证明等）。如果你想在请求中包含凭据，即使对于跨源请求，你可以设置 credentials 的值为 "include"。如果你不想在请求中包含凭据，你可以设置 credentials 的值为 "omit"。

以下是使用 fetch API 并设置 credentials 的示例：

fetch('https://example.com', {
  credentials: 'include' // 包含凭据，即使是跨源请求
})

fetch('https://example.com', {
  credentials: 'omit' // 不包含凭据
})

fetch('https://example.com', {
  credentials: 'same-origin' // 只有对同源的请求才包含凭据
})

注意：对于CORS请求，浏览器会在请求中自动包含凭据，但服务器必须指示浏览器返回响应，否则响应将被忽略。

2.4 Cookie 过大 可能引发的问题

浏览器层

每个浏览器对Cookie的大小都有限制，通常为4KB。如果Cookie的大小超过了这个限制，当 Cookie 的大小或数量超过浏览器的限制时，浏览器通常不会显示一个明确的错误。而是会按照其自身的策略处理这种情况，这可能包括拒绝存储新的 Cookie，删除旧的 Cookie 来腾出空间，或者将大的 Cookie 截断为小的 Cookie。

网络层

Cookie 是在每次 HTTP 请求中发送的，如果 Cookie 过大，那么网络传输的负载就会增大，这会影响网页加载的速度和服务器的响应速度。

服务端

Cookie 值过大，可能导致请求头超过 Tomcat 和 Nginx 等web服务器的大小限制，下面Tomcat 和 Nginx的配置信息及处理策略：

1. Tomcat：

在 Tomcat 中，可以通过 maxHttpHeaderSize 属性来限制 HTTP 请求头的大小。默认值为 8192 字节（8 KB）。你可以在 server.xml 文件中的 Connector 标签设置这个属性。例如：

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           maxHttpHeaderSize="8192" />

如果请求头的大小超过了 maxHttpHeaderSize 属性的值，Tomcat 会返回 HTTP 400 错误。

2. Nginx：

在 Nginx 中，可以通过 large_client_header_buffers 指令来限制 HTTP 请求头的大小。默认设置为 large_client_header_buffers 4 8k;，意味着 Nginx 可以接受最多4个8KB的请求头。

你可以在 nginx.conf 文件中的 http 或 server 或 location 块中设置这个指令。例如：

http {
    large_client_header_buffers 4 16k;
}

如果请求头的大小超过了 large_client_header_buffers 指令的值，Nginx 会返回 HTTP 414 错误（Request-URI Too Large）或者 HTTP 431 错误（Request Header Fields Too Large）。

三、总结

1. 默认情况下，Cookie 的生命周期为临时会话级，而在最新的浏览器中，SameSite 的默认值设为 Lax，已具备较高安全性。根据实际需求或请求协议，可将 Cookie 设置为 HttpOnly 或 Secure，以进一步提升安全级别。
2. 除非必要，否则不建议设置过期时间和作用域，以免无意间扩大 Cookie 的生命周期和作用范围。
3. 除非必要，否则不建议在 XHR 和 Fetch 请求中扩大 Cookie 的处理策略。

九、引文

• MDN-Cookies