Cookie · XB 现场笔记

Cookie 标记约束支持它们的客户端

Thu, 17 Jun 2027 00:00:00 +0000

Secure、HttpOnly 和 SameSite 分别描述支持这些规则的浏览器如何限制 Cookie。服务端收到的是最终的名称与值，而不是一张证明这些限制已经执行的证书。浏览器行为与服务端授权必须分开：Cookie 完全可能被正确发送，但当前请求的业务动作仍然不被允许，不能把出现 Cookie 头当成全部安全条件已经满足。

分开看设置、发送与脚本读取

Secure 限制 Cookie 通过安全连接发送，通常就是 HTTPS。现代浏览器 Cookie 规则还会拒绝从不安全语境设置 Secure Cookie；localhost 等开发例外应在目标浏览器中核对，而不能推广为任意明文主机都可信。这不仅是发送阶段的标记。一次 HTTPS 重定向无法撤回此前明文请求已经泄露的令牌，因此应结合 HTTPS 与适当的 HSTS 策略，而不是让两者互相替代。

HttpOnly 阻止通过 document.cookie 等非 HTTP 脚本接口读取 Cookie，但不会禁止浏览器把它附到符合条件的脚本请求上。被注入的同源 JavaScript 即使读不到令牌，也仍可能以用户身份发起操作。因此必须单独预防和限制 XSS；HttpOnly 减少的是其中一条窃取路径，并不是把脚本注入漏洞消除了。

SameSite 增加请求语境限制。Strict 通常允许同站请求，Lax 还允许使用安全方法的跨站顶层导航。显式 Lax 不会仅因为某次跨站 POST 是从顶层页面发起，就让 Cookie 自动附上。None 去掉这一项限制，但在支持规则的浏览器中必须搭配 Secure。第三方 Cookie 阻止、存储分区以及 Fetch 的凭据模式，仍可能阻止发送，不能把 None 理解成任何请求都无条件携带。

站点与来源不是同一回事

对于普通 HTTPS 域名，相关的带协议站点边界由协议和可注册域构成。两个 HTTPS 兄弟子域可以同站，却仍然不同源。端口变化也会造成不同源，而未必改变站点。因此，Strict 不承诺排除所有跨源请求；同站兄弟应用被攻陷，仍然是评估 CSRF 防护时必须考虑的场景，不能只测试完全无关的外部域名。

省略或填写无效 SameSite，也不能可移植地等同于显式 Lax。规范允许针对最近创建、没有显式值的 Cookie 使用兼容模式，使部分不安全方法的顶层请求也携带它。常见的两分钟窗口是面向实现的兼容性限制，不是每一种浏览器都必须采用的保证。应写出预期值，并测试真正支持的浏览器版本，而不是依靠默认值的模糊印象。

坏掉的样子

会修改状态的 GET 在 Lax 下仍有危险，因为跨站顶层的安全方法导航可以携带 Cookie。修改状态应采用合适的方法和服务端 CSRF 防护。反过来，Strict 可能扣住跨站身份提供方回调所需的 Cookie。要检查真实的重定向链与回调方法；并非所有单点登录都会失败，而且单独打开一个书签，也不能证明发生了跨站重定向。

应使用身份库支持的关联校验与回调设计，而不是不加区分地放宽主要会话。Origin 或 Fetch Metadata 校验可以发挥作用，但需要明确处理头字段缺失、兼容客户端和合法跨站流程。非浏览器客户端可以伪造这些头，所以它们是浏览器语境信号，不是凭据。已经持有被盗会话令牌的客户端，需要认证和撤销机制来处理，不能指望再检查一次 SameSite 就把它识别出来。

快速验证

把代码保存为 cookie-flags.py，使用 Python 3.11 或更新版本执行 python3 cookie-flags.py。它使用真实标准库 CookieJar 与虚构响应元数据，不发送网络请求。目的在于展示这个 HTTP 客户端的 Cookie 政策与浏览器政策之间的差别，不是建立一个假的浏览器，再把模型结果冒充成真实浏览器行为。

from email.message import Message
from http.cookiejar import CookieJar
from http.cookies import SimpleCookie
from urllib.request import Request


class Response:
 def info(self):
 headers = Message()
 for value in [
 "secure_sid=synthetic; Path=/; Secure; HttpOnly; SameSite=Lax",
 "strict_pref=synthetic; Path=/; SameSite=Strict",
 "insecure_none=synthetic; Path=/; SameSite=None",
 ]:
 headers.add_header("Set-Cookie", value)
 return headers


jar = CookieJar()
jar.extract_cookies(Response(), Request("https://app.example.com/login"))


def outgoing(url):
 request = Request(url)
 jar.add_cookie_header(request)
 header = request.get_header("Cookie", "")
 parsed = SimpleCookie()
 parsed.load(header)
 assert "SameSite" not in header and "HttpOnly" not in header
 return set(parsed)


assert outgoing("http://app.example.com/") == {"strict_pref", "insecure_none"}
assert outgoing("https://app.example.com/") == {
 "secure_sid", "strict_pref", "insecure_none"
}
manual = Request("http://app.example.com/",
 headers={"Cookie": "secure_sid=synthetic"})
assert manual.get_header("Cookie") == "secure_sid=synthetic"
print("PASS: CookieJar filters Secure; it does not enforce SameSite")
print("PASS: request headers omit attributes; a manual header bypasses the jar")

CookieJar 在 HTTP 上扣住 secure_sid，在 HTTPS 上发送它，即使它带有 HttpOnly。与此同时，它接受 insecure_none，也会在没有建模页面同站语境的情况下发送 strict_pref。后两项结果展示的是这个客户端的局限，不是浏览器的预期。手动构造 Cookie 头还可以完全绕过 CookieJar。本实验没有建立任何服务端响应或浏览器结果，也没有验证真正的 CSRF 拒绝路径。

验收浏览器时，应使用隔离的同站与跨站测试页面、虚构取值，分别检查 Cookie 能否存入以及实际是否随请求发送。覆盖顶层 GET、POST 回调、嵌入式 fetch，以及应用使用的凭据模式。用 curl 伪造 Sec-Fetch-Site 头无法证明 SameSite 已被执行，一个任意 HTTP 状态码也不能证明 Cookie 被接受或业务动作已获授权；应收集与问题直接相关的两端证据。

来源

Cookie 规范草案第 22 版，存储、发送、SameSite 与可选兼容行为，已核验 2026-10-15。
Python CookieJar，客户端 Cookie 处理及其文档列明的协议范围，已核验 2026-10-15。
OWASP CSRF 防护，SameSite 局限、来源与 Fetch Metadata 防御，已核验 2026-10-15。

Cookie 作用域让会话留在该待的地方

Sun, 25 Oct 2026 00:00:00 +0000

Cookie 的主机与路径作用域，决定哪些目的地有资格收到它的名称和值。缩小这个集合有助于减少暴露，但作用域不是授权，而且 Cookie 并不采用浏览器完整的源边界。本文重点讨论 Domain 与 Path；传输方式、请求语境和浏览器策略还会增加其他限制，不能只凭一个属性就推断最终发送结果。

Domain 选择主机，不隔离端口

省略 Domain 会建立 host-only Cookie。从 app.example.com 设置的 Cookie 只匹配这个主机，不匹配 shop.example.com。加入 Domain=example.com，则允许父域与匹配的子域收到它，但仍受其他 Cookie 条件约束。属性处理会忽略一个前导点，它并不是另一种通配符功能。只有那些更宽的接收方确实需要这个值，才应扩大作用域。

设置 Cookie 的主机不能指定无关的兄弟域：app.example.com 不能设置 Domain=shop.example.com。浏览器还会应用公共后缀限制，因此仅检查字符串后缀并不是完整实现。下面模型只处理已知的示例主机名，明确不实现公共后缀查找、国际化域名转换与 IP 地址规则；不能把这个演示直接复制成认证系统的 Cookie 库。

端口不是 Cookie 边界。属于 app.example.com 的合格 Cookie 可以发送到该主机的另一个端口，即使端口变化意味着 Web 来源已经变化。因此，意料之外的端口服务也必须纳入信任评估。把不可信应用放在不同路径或端口，并不能获得真正分开 Cookie 主机所带来的隔离，host-only 也不等于完整的同源限制。

默认路径来自设置请求

Path 被省略或无效时，浏览器会根据设置请求的路径计算默认值。请求路径为 /account/login 时，默认值是 /account，不是 /；请求路径为 /login 时，默认值才是 /。因此，只移动登录端点而完全不改 Set-Cookie 字符串，也可能改变 Cookie 的隐式作用域。如果应用依赖稳定范围，就应明确写出所需 Path。

路径匹配还检查斜杠边界：/admin 匹配自身以及 /admin/users，但不匹配 /administrator。这不是文件系统权限。同源脚本可以与其他路径交互，因此不能依靠 Path 把彼此不可信的应用隔离开。较窄路径减少有资格附带 Cookie 的请求，却不能代替服务端检查，也不能阻止所有读取该值的方式。

坏掉的样子

父域会话 Cookie 可能抵达一个被遗忘的兄弟服务，而该服务恰好记录了请求 Cookie。HttpOnly 无法阻止接收服务器读取自己收到的请求头。相反，默认路径过窄会让已经成功的登录在另一条路由上看起来丢失。诊断这两类问题，都要同时记录设置 URL 和属性，但不要把真实会话值打印到日志、截图或支持工单中。

同名 Cookie 还可能因作用域不同而同时存在。Cookie 请求头只包含名称和值，不包含 Domain 与 Path，应用不能从这个头恢复每一枚 Cookie 的原始范围。应避免含混的重复会话名称，并在迁移时使用匹配作用域使旧 Cookie 过期。删除另一路径上的同名 Cookie，不会删除原本那一枚；仅检查当前登录响应也不足以发现旧存储状态。

支持前缀规则的浏览器要求 __Host- Cookie 来自安全设置语境、带 Secure、明确使用 Path=/，且没有 Domain。兄弟子域因而不能用这个前缀名称植入父域 Cookie。但它仍然不隔离端口，也无法修复已被攻陷的设置主机。认证后仍须重新生成会话标识，不能把前缀当成会话固定问题的全部解法。

快速验证

把下面代码保存为 cookie-scope.py，使用 Python 3.11 或更新版本执行 python3 cookie-scope.py。它不打开任何网络套接字，只使用虚构 URL。断言验证刻意限定的域名与路径模型，不验证浏览器存储、SameSite、过期、名前缀或第三方 Cookie 政策。函数名字只是为了帮助阅读，不代表它们实现了完整用户代理。

from urllib.parse import urlsplit


def default_path(request_path):
 if not request_path.startswith("/") or request_path.count("/") <= 1:
 return "/"
 return request_path.rsplit("/", 1)[0]


def domain_match(host, domain):
 return host == domain or host.endswith("." + domain)


def path_match(request_path, cookie_path):
 return request_path == cookie_path or (
 request_path.startswith(cookie_path)
 and (cookie_path.endswith("/")
 or request_path[len(cookie_path):].startswith("/"))
 )


def scoped_cookie(setting_url, domain=None, path=None):
 setting = urlsplit(setting_url)
 host = setting.hostname
 selected = host if domain is None else domain.removeprefix(".").lower()
 if domain is not None and not domain_match(host, selected):
 raise ValueError("Domain does not match the setting host")
 return selected, domain is None, (
 path if path and path.startswith("/") else default_path(setting.path)
 )


def matches(cookie, request_url):
 domain, host_only, path = cookie
 request = urlsplit(request_url)
 host_ok = (request.hostname == domain if host_only
 else domain_match(request.hostname, domain))
 return host_ok and path_match(request.path or "/", path)


setting = "https://app.example.com/account/login"
host_only = scoped_cookie(setting)
broad = scoped_cookie(setting, domain=".example.com", path="/")
assert host_only == ("app.example.com", True, "/account")
assert broad == scoped_cookie(setting, domain="example.com", path="/")
assert matches(host_only, "https://app.example.com/account/profile")
assert not matches(host_only, "https://app.example.com/dashboard")
assert not matches(host_only, "https://shop.example.com/account/profile")
assert matches(broad, "https://shop.example.com/")
assert not matches(broad, "https://example.com.attacker.invalid/")
assert matches(host_only, "https://app.example.com:8443/account/profile")
for path, expected in [("/admin", True), ("/admin/", True),
 ("/admin/users", True), ("/adminx", False),
 ("/administrator", False)]:
 assert path_match(path, "/admin") == expected
try:
 scoped_cookie(setting, domain="shop.example.com")
except ValueError:
 pass
else:
 raise AssertionError("unrelated Domain accepted")
print("PASS: default path, host-only, domain, path boundary, and port cases")

成功行确认了由请求计算的 /account 默认值、host-only 对兄弟域的排除、父域扩大后的匹配、斜杠边界，以及端口独立性。指定兄弟 Domain 会抛出 ValueError。这些都是明确列出的样本结果，并不是浏览器协议一致性认证，也不能据此宣称任意域名输入都得到正确处理。

部署验收时，应在浏览器开发工具中查看隐藏值后的属性，并用虚构账号测试预期路由矩阵。同时检查 Cookie 存储和实际出站请求，因为缺失 Cookie 头可能来自设置被拒绝、过期、作用域或其他浏览器政策。不要为了演示作用域太宽，就把生产会话值发往不可信主机；属性检查和安全测试账号已经可以提供所需证据。

来源

RFC 6265：匹配算法，域匹配、默认路径与路径匹配，已核验 2026-10-15。
RFC 6265：安全注意事项，路径及端口的隔离限制，已核验 2026-10-15。
Cookie 规范草案第 22 版，__Host- 要求与仍然存在的端口边界，已核验 2026-10-15。