Cookie的工作原理主要涉及到HTTP协议中的状态管理。HTTP协议本身是无状态的,这意味着每次请求都是独立的,服务器不会保留之前的请求信息。为了在无状态的HTTP协议上实现有状态的会话,引入了Cookie机制。
1. Cookie定义
Cookie,也称为HTTP cookie、web cookie、互联网cookie或浏览器cookie,是一种用于在用户浏览网站时识别用户并为其准备网页的小型数据片段。它允许Web服务器跟踪用户的浏览历史并响应之前披露的偏好。可以增强用户体验,并基于过去的行为启用个性化内容。
Cookie通常以键值对的形式存储在用户的硬盘上,是一个二进制的Sqlite文件,Windows系统中Chrome浏览器的Cookie默认位置一般为C:\Users\me\AppData\Local\Google\Chrome\User Data\Default\Network
。
Cookie有多种类型,包括会话cookie和持久cookie。
- 会话cookie仅在访问网站期间处理,用户退出浏览器会话cookie就被删除了;
- 持久cookie则在网站会话结束后处理,存储在访问者的设备上,每次访问网站时都会激活。
2. Cookie的工作原理
默认情况下,每个请求都被视为新请求。通过在响应中添加Cookie来实现Cookie技术,从而将Cookie存储在浏览器缓存中。下次浏览器向该站点发送请求时,它会查找来自该域的cookie,如果找到,Cookie会被添加到该请求中。具体工作原理如下:
1) 客户端首次请求
当用户首次访问一个网站时,服务器会生成一个唯一的标识符(通常是一个随机的字符串),并通过HTTP响应头中的Set-Cookie字段将这个标识符发送给客户端。
2)客户端存储Cookie
客户端接收到这个Cookie后,会将其存储在本地的sqlite文件中。这个Cookie通常包含了一些信息,如过期时间、域名、路径等。
用sql连接工具可以导出cookies的DDL语句,具体如下
create table cookies
(
creation_utc INTEGER not null,
host_key TEXT not null,
top_frame_site_key TEXT not null,
name TEXT not null,
value TEXT not null,
encrypted_value BLOB not null,
path TEXT not null,
expires_utc INTEGER not null,
is_secure INTEGER not null,
is_httponly INTEGER not null,
last_access_utc INTEGER not null,
has_expires INTEGER not null,
is_persistent INTEGER not null,
priority INTEGER not null,
samesite INTEGER not null,
source_scheme INTEGER not null,
source_port INTEGER not null,
last_update_utc INTEGER not null,
source_type INTEGER not null,
has_cross_site_ancestor INTEGER not null
);
create unique index cookies_unique_index
on cookies (host_key, top_frame_site_key, has_cross_site_ancestor, name, path, source_scheme, source_port);
3) 客户端后续请求
之后,每当客户端向同一个服务器发送请求时,都会自动在HTTP请求头中包含这个Cookie。这样,服务器就能识别出这个请求是来自哪个客户端,从而实现会话管理。
4)服务器处理Cookie
服务器接收到包含Cookie的请求后,会解析这个Cookie,并根据其中的信息来处理请求。例如,服务器可以根据Cookie中的标识符来查找对应的会话数据,从而实现用户认证、个性化内容展示等功能。
3. Cookie的安全性问题及防护
为了保护用户隐私和数据安全,Cookies可以设置一些安全属性,如HttpOnly(防止JavaScript访问)、Secure(只在HTTPS连接中传输)等。此外,一些现代浏览器和操作系统也提供了额外的隐私保护机制,如隐私沙盒,来限制第三方Cookies的使用。
Cookie 的安全性主要涉及以下六点:
-
1. 安全性级别:
-
HTTP Only:这种属性可以防止JavaScript访问Cookie,从而阻止XSS(跨站脚本)攻击时利用Cookie获取敏感信息。
若想了解XSS攻击的原理和防护可以参阅博主前期文章《「 典型安全漏洞系列 」01.跨站脚本攻击XSS详解》
-
Secure:标记为Secure的Cookie只能通过HTTPS协议传输,避免了在HTTP协议下传输Cookie时可能被中间人攻击截获的风险。
-
SameSite:用于限制Cookie的跨站点请求访问。分为
SameSite=None
和SameSite=Lax
两种,前者在任何情况下都不会通过跨站点请求发送Cookie,后者则在非直接请求时不会发送Cookie,可以有效防止CSRF(跨站请求伪造)攻击。若想了解CSRF攻击的原理和防护可以参阅博主前期文章《「 典型安全漏洞系列 」03.跨站请求伪造CSRF详解》
-
-
2. 生命周期:Cookie的生命周期由其过期时间决定。默认情况下,Cookie会在浏览器关闭时失效。开发者可以通过设置Max-Age或Expires属性来延长Cookie的生命周期,但这也增加了被窃取的风险。
-
3. 内容加密:为了保护Cookie内容不被窃取,可以对Cookie内容进行加密。这种方法需要客户端和服务器端共享密钥,以确保数据在传输过程中的安全性。
-
4. 会话管理:使用Cookie进行会话管理时,需要确保Cookie的名称、值、过期时间等设置得当,避免使用过于明显的名称或容易猜测的值,防止被猜测或重放攻击。
-
5. 第三方Cookie:第三方Cookie(由当前网站之外的其他网站设置的Cookie)增加了隐私风险。为了保护用户隐私,现代浏览器开始限制第三方Cookie的使用,如Chrome浏览器的“隐私沙盒”计划。
-
6. 同源策略(SOP):浏览器的同源策略限制了不同来源的网站之间不能共享Cookie信息,除非通过特定的HTTP头部(如Access-Control-Allow-Credentials)允许。这有助于保护用户隐私和数据安全。
若想了解同源的原理和防护可以参阅博主前期文章《同源策略SOP详解》
4. 总结
Cookie通过在用户的浏览器和Web服务器之间传递小段数据来工作,允许服务器识别用户并为其准备个性化的网页内容。Cookie在提供连续的用户体验和跟踪用户偏好方面起着关键作用。
Cookie的安全性需要通过合理的配置和管理来保障。开发者应根据实际应用场景选择合适的设置,以保护用户数据安全。