C/C++教程

如何保障Cookie的信息安全

本文主要是介绍如何保障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)。它有三个可能的值:StrictLaxNone

  • 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 的生命周期的一些基本信息。

对于同源请求,浏览器会默认带上 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);

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请求,浏览器会在请求中自动包含凭据,但服务器必须指示浏览器返回响应,否则响应将被忽略。

浏览器层

每个浏览器对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
这篇关于如何保障Cookie的信息安全的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!