安全 · XB 现场笔记

ssh agent 传递密钥而不暴露

Wed, 09 Feb 2028 00:00:00 +0000

agent 转发并不等于 agent。转发是请远端主机上的 sshd 自己开一个套接字，并把那边的 SSH_AUTH_SOCK 指过去，于是那台机器上的程序可以回头找你家里的 agent 签名。远程自始至终没有拿到密钥，它也根本不需要拿到：它拿到的是这份能力的完整使用权。

这是穿过堡垒机抵达内网机器的常规做法，同时也意味着路径上每一跳都分到了这份能力。多数伸手去拿 -A 的人，真正想要的是 ProxyJump——它只转发 TCP，把 agent 留在本机。

两者容易被混为一谈，是因为它们用的是同一套协议、同一个 SSH_AUTH_SOCK 变量，区别只在于那只套接字落在哪台机器上。agent 留在本机，它就是你的私钥保险箱；套接字出现在远端，它就是一张那台机器上任何程序都能使用的通行证。

远程拿到的是套接字，不是密钥

ssh_config(5) 对这笔交易毫不含糊。ForwardAgent 接受 yes、no（默认值）、一个明确的套接字路径，或某个环境变量的名字；手册警告说，能够在远端绕过该 agent 套接字文件权限的用户，可以经由这条转发连接访问你本地的 agent。更要紧的是紧接着的那句：攻击者无法从 agent 取得密钥材料，但可以对密钥执行操作，从而用已装载的身份完成认证。

本文的实测正好呈现了这个形状。一个只拿到 SSH_AUTH_SOCK、既没有密钥文件也没有口令的第三方进程，列出了身份并拿到了一枚 88 字节的签名。这就是转发交给某一跳的全部能力。

转发是逐跳选择的

能签名的机器集合，恰好就是那些以启用转发的方式运行 ssh 的跳数。ssh -A bastion 把 agent 暴露给 bastion；从那里再 ssh -A build-box，build-box 也一并拿到；而 ssh build-box 不带 -A，链条就止步于 bastion。没有任何一跳会意外地级联下去，但也没有任何东西会提醒你。

这一点值得反复强调：转发不是连接本身的属性，而是一个按次传入的开关。你在哪一条命令上写了 -A，就在哪一段链路上开了口子；没写的那一段，agent 不会自己跟过去。因此「这条链路谁能用我的身份」这个问题，答案就是那串命令里出现过几次 -A。

ProxyJump 是更安全的形状。ssh_config(5) 对它的描述是：先与指定的跳板主机建立一条 ssh 连接，再从那里向最终目标建立 TCP 转发，以此连上目标主机。跳板机转发的是数据包而不是签名，所以 agent 从不离开工作站；ssh -G 也确认，-o ProxyJump=bastion 之后 forwardagent 仍然是 no。

服务端能管和管不了的事

在服务端，配置里什么都不写时 sshd -T 会报 allowagentforwarding yes，写上 AllowAgentForwarding no 才会变成 no。手册在这里补了一句值得读两遍的警告：除非同时禁止用户获得 shell 访问，否则关掉 agent 转发并不能提升安全性，因为他们总可以自己装一个转发器。把它当成卫生习惯，而不是一道边界。

真正有效的是把身份收窄。ssh-add -c 要求每次使用都确认，而一次没有 tty 可以回答提示的签名请求被拒绝了。ssh-add -h 'bastion>prod-db' 把密钥约束到特定的来源与目的主机对上，并把整条路径（含转发）逐跳拿去比对。ssh-add -t 则限定了这一切还能持续多久。

坏掉的样子

最经典的一种是堡垒机被攻陷。谁占住那台机器，谁就继承了你的身份，时限等于 agent 还装着这把钥匙的时间：他们可以用它登录这把钥匙能开的每一台主机，还可以借这条转发继续摸到你从未打算开放的下游机器。在磁盘上轮换密钥打断不了它，因为 agent 内存里那份还是旧的，而且照样在签。要判断自己是否处在这种风险里，只需问一句：路径上有没有哪台机器的管理员权限不在我手里？只要有，这条链路上的 agent 转发就应当被当作已经泄露来对待。

更安静的一种是把转发全局打开。一条 Host * 配 ForwardAgent yes，会把每一次连接都变成一次授权，包括连到同事测试机的那一次；而出现在远端的那只套接字归你在那边的账户所有，同时那台机器上的 root 也能访问。转发应当是按主机做的决定，而且不该比需要它的那项任务活得更久。

快速验证

先弄清楚你到底授权出去了什么：

ssh -G prod-db | grep -iE '^(forwardagent|proxyjump)'
grep -rin forwardagent ~/.ssh/config
ssh-add -l
ssh -o ForwardAgent=no -J bastion,build-box prod-db
sshd -T | grep -i allowagentforwarding

第一行打印的是生效后的取值，所以在一台你并不掌控的主机上看到 forwardagent yes，就是本次要查的问题；最后一条在服务端执行，用来看服务端到底允不允许转发。ssh-add -l 里应当只列出这项任务需要的身份，因为装载进去的每一个都会随转发一起被授权出去。

来源

OpenBSD：ssh_config，ForwardAgent 及其警告，以及 ProxyJump 从跳板机做 TCP 转发的语义，已核验 2026-09-16。
OpenBSD：sshd_config，AllowAgentForwarding 的默认值，以及为何关掉它并不构成边界，已核验 2026-09-16。
OpenBSD：ssh-add，-c 逐次确认、-t 存活期，以及针对转发密钥的 -h 目的主机约束，已核验 2026-09-16。

OCSP Staple 免去一段往返校验

Mon, 06 Dec 2027 00:00:00 +0000

把核验交给服务器能省掉一整段往返与一次独立请求;就算没有 Staple,客户端也仍可兜底去查。

服务器只取一次

OCSP stapling 是让「验证」这件事不拖慢握手：客户端本要通过一次额外往返，去 CA 的那台应答服务器（OCSP）查询「这张证书有没有被吊销」。开启 stapling 后，这个查询改成由服务端自己做，然后把查询结果（CA 签过名的那条）放进 TLS 握手一起发过去。浏览器就不用再单独发一次查询了，握手因此更快，也少了一层对 OCSP 提供方是否在线的依赖。

客户端免去一次查询

Staple 的机制是把「每次握手由客户端查」改成「每隔一段时间由服务端查」：服务端以缓存一份带 CA 签名的 OCSP 响应，在窗口内对所有客户端重复“贴”出同一条。每次握手几乎零成本。但 OCSP 响应本身会过期，一般以分钟或天为单位计量；太久、或被 CA 拒签、或验证不过的 staple，会让服务端退回旧路径——干脆不贴。打开的开关在 nginx 里很直白：在 nginx 里把 ssl_stapling 打开，并配置 ssl_stapling_verify 与完整证书链（中间证书）即可。

是 Staple,不是绝对保证

要摆正一个重要认识：stapling 是针对 OCSP 的优化，不是安全边界。它并没有把「吊销检查」做得比不发全程更硬，反而只是把检查挪到了服务器上并缓存。staleness 不影响握手成败——一条过期 staple 更可能让检查退回请求 CA，而不是让 TLS 失败。所以，信任应该建立在 CA 签名与整条证书链之上，而不是 stapling 本身。它真正可度量的收益是省下那一次往返，也消除了 OCSP 提供商宕机时客户端被拖慢的那一层影响。能开就开，几乎没有任何理由不开。

坏掉的样子

最常见的故障是装订响应过期却没有及时续取。服务端一直在握手里重复发送同一份缓存，一旦超过 next_update，客户端就会判定过期而丢弃，于是每次握手又退回直连证书颁发机构查询，延迟立刻回升。应当把缓存年龄与后台续取错误分开监控：续取失败时先表现为延迟上涨，而不是直接中断。续取失败往往先写错误日志，监控应当同时观察日志与装订年龄。冷启动时缓存为空，症状相同，上线前应当先预热再接受流量。

must-staple 把上述软失败变成硬失败。没有该标记时，缺失的装订只会降级为普通在线查询，可用性得以保留，但能剥离 certificate_status 扩展的中间人，就可以隐藏吊销信息。有了该标记，剥离会直接导致握手失败；代价是应答抖动、链缺失中间证书、缓存中断都会让所有握手失败。公众站点通常保留软失败，只有吊销遗漏代价远大于中断的高保障接口，才值得开启硬失败。

时钟偏斜是另一类隐蔽诱因。每份响应都带有 this_update 与 next_update，客户端时钟快了几小时，就会把新鲜装订误判为过期；时钟慢了，则可能继续信任旧装订。链不完整结果相同：装订按时到达，却因缺失中间证书无法验证，只能被丢弃。排查时先核对两端时间与下发链，再怀疑应答服务，同时保留拒绝原因与缓存时间戳以便对照。若时间与证书链都没有问题，再去检查应答服务是否限流或者更换签名密钥。

快速验证

把下面程序保存为 stapling_probe.py，运行 python3 stapling_probe.py。它只用标准库模拟服务端缓存与客户端决策，不做网络请求与验签。每份响应都包含 this_update 与 next_update，缓存只在新鲜且可验证时才贴出；客户端再按是否存在装订、是否过期、是否必须装订，决定接受、回退直查还是直接失败。

from datetime import datetime, timedelta, timezone


def make_response(this_update, lifetime_hours=48, status="good", sig_valid=True):
 return {
 "status": status,
 "sig_valid": sig_valid,
 "this_update": this_update,
 "next_update": this_update + timedelta(hours=lifetime_hours),
 }


class StapleCache:
 """Server-side cache: only a fresh, verifiable response may be stapled."""

 def __init__(self):
 self._cached = None

 def store(self, response):
 self._cached = response

 def staple_for_handshake(self, now):
 resp = self._cached
 if resp is None:
 return None
 if not resp["sig_valid"]:
 return None
 if not (resp["this_update"] <= now <= resp["next_update"]):
 return None
 return resp


def client_decide(staple, now, must_staple=False, ocsp_reachable=True):
 """Return the client decision for one handshake."""
 if staple is not None:
 fresh = staple["this_update"] <= now <= staple["next_update"]
 if staple["sig_valid"] and fresh:
 if staple["status"] == "good":
 return "accept-staple"
 if staple["status"] == "revoked":
 return "reject-revoked"
 if must_staple:
 return "hard-fail"
 if ocsp_reachable:
 return "soft-fail-fetch"
 return "soft-fail-no-revocation"


def check(ok, message):
 if not ok:
 raise AssertionError(message)


def main():
 now = datetime(2026, 6, 2, 12, 0, 0, tzinfo=timezone.utc)
 cache = StapleCache()
 check(cache.staple_for_handshake(now) is None, "empty cache must staple nothing")
 check(client_decide(None, now, must_staple=False) == "soft-fail-fetch",
 "missing staple without must-staple must fall back to a direct fetch")
 check(client_decide(None, now, must_staple=True) == "hard-fail",
 "missing staple with must-staple must fail closed")

 fresh = make_response(now - timedelta(hours=1))
 cache.store(fresh)
 check(cache.staple_for_handshake(now) is fresh, "fresh response must be stapled")
 check(client_decide(cache.staple_for_handshake(now), now) == "accept-staple",
 "fresh good staple must be accepted")

 expired = make_response(now - timedelta(hours=72))
 cache.store(expired)
 check(cache.staple_for_handshake(now) is None, "expired response must not be stapled")
 check(client_decide(cache.staple_for_handshake(now), now, must_staple=False) == "soft-fail-fetch",
 "expired staple must fall back to a direct fetch")
 check(client_decide(None, now, must_staple=True) == "hard-fail",
 "expired staple with must-staple must fail closed")

 bad_sig = make_response(now - timedelta(hours=1), sig_valid=False)
 cache.store(bad_sig)
 check(cache.staple_for_handshake(now) is None, "unverifiable response must not be stapled")

 cache.store(fresh)
 skewed = now + timedelta(hours=72)
 check(cache.staple_for_handshake(skewed) is None,
 "a clock running far ahead must see the staple as expired")
 check(client_decide(cache.staple_for_handshake(skewed), skewed, must_staple=False) == "soft-fail-fetch",
 "skewed client must take the soft-fail path")
 check(client_decide(None, skewed, must_staple=False, ocsp_reachable=False) == "soft-fail-no-revocation",
 "stripped staple with unreachable responder leaves no revocation signal")

 revoked = make_response(now - timedelta(hours=1), status="revoked")
 cache.store(revoked)
 check(client_decide(cache.staple_for_handshake(now), now) == "reject-revoked",
 "fresh revoked staple must reject the certificate")

 print("PASS: fresh accepted; expired, bad-signature, stripped, and skewed clocks fall back or fail closed as configured")


if __name__ == "__main__":
 main()

程序覆盖六组断言：新鲜接受；过期拒绝并回退直查；剥离后无标记回退、有标记硬失败；签名无效拒绝贴出；时钟超前视为过期；应答不可达时标记无吊销信号。预期只有一行 PASS 结论。若断言失败，程序直接抛异常并指出环节，便于定位是过期、签名还是决策分支问题。

模型刻意简化现实：没有真实抓取颁发机构，没有验证签名，没有协商握手，也没有模拟并发续取与多机共享缓存。它只讲清缓存语义与软失败决策，线上仍需用 openssl s_client 查看真实装订，并对 next_update 到期单独监控，避免把实验当成生产依据，发布前务必复核真实握手与续取状态。

来源

RFC 6961：TLS 多证书状态请求扩展，多装订扩展与响应新鲜度规则，已核验 2026-06-02。
Mozilla 服务器端 TLS，OCSP 装订配置与运维指导，已核验 2026-06-02。
Cloudflare：什么是 OCSP 装订，装订响应如何省去客户端往返，已核验 2026-06-02。

安全上下文需要运行时证据来验证

Sat, 20 Nov 2027 00:00:00 +0000

Kubernetes 的 securityContext 配置进程身份及部分操作系统约束，可以缩小被攻陷应用允许执行的操作，但本身不会建立完整安全边界。应先确定应用实际需要什么操作，再配置对应字段，并在最终容器中同时测试允许与拒绝的行为。只有一份看起来严格的清单，还不能说明运行中的进程已经按预期受到限制，也不能代替应用本身的权限设计。

把设置放在正确层级

Pod 级配置可以提供用户和组身份、共享卷的组权限行为，以及 seccomp 配置。容器级字段可以覆盖适用的默认值，并设置 capabilities、权限提升和只读根文件系统。需要核对字段真实 API 范围，把熟悉的名称写在错误位置，并不会获得等价约束。相同的 securityContext 名称之下，不代表所有字段都能互换放置。

runAsUser 选择数值用户身份，runAsNonRoot 则要求容器符合非 root 策略。这些设置补充镜像元数据，不能仅凭一个用户名看起来普通，就信任实际权限。卷权限也必须允许所选身份完成必要工作。下面的 emptyDir 通过 fsGroup 提供组访问，使应用能够写入指定工作目录，而不必因此获得对整个根文件系统的写权限。

Linux capabilities 把传统上广泛关联于 root 的权限拆成不同能力。删除 ALL 会移除容器配置中的这些能力。普通容器默认并不继承全部 Linux 能力，而容器内以 root 运行，也不等于已经成功逃逸到宿主机。应审阅真实有效权限，避免用这两种过度简化替代证据。减少权限很有价值，但其效果需要准确描述。

坏掉的样子

allowPrivilegeEscalation false 会为进程设置 no_new_privs，限制通过执行程序获取新权限，例如 set-user-ID 或文件能力引起的身份与权限提升。它不会撤销进程已经拥有的全部权限，也不代替业务授权。应检查实际进程标志和有效能力，不能把每一次被拒绝的操作都归因于这个字段，否则可能误解其他身份或文件权限设置的作用。

readOnlyRootFilesystem 让容器根文件系统只读，其他挂载仍可能可写，包括明确提供的工作卷。这并不是全面禁止执行代码：解释器仍可以读取并运行可写卷中的程序。它也不会阻止网络请求，或撤销对已经挂载数据的读取。只读存储约束的是一类操作，不能直接证明攻击无法继续，更不能把“不能改根目录”扩写成“不能写入任何内容”。

Seccomp 过滤系统调用，但 RuntimeDefault 取决于运行时提供的默认配置。进程报告过滤模式，说明存在实际过滤机制，不证明所有不期望的调用和攻击路径都被阻断。普通 Linux 容器运行时也能执行这些字段，不是必须采用特殊沙箱它们才生效。更强隔离有独立设计要求，应按威胁模型讨论，不能把是否有效与某一个产品名称绑定。

互相冲突的身份设置可能通过 API 准入，却阻止容器启动。镜像也可能原本需要在根文件系统中写缓存或临时文件。应检查启动状态和被拒绝路径，只提供实际所需工作存储，不要用恢复 root、允许权限提升或打开整个根文件系统来处理所有权限报错。必要写入与过大权限需要通过真实调用区分。

快速验证

准备临时 Linux Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 security-context.py，执行 python3 security-context.py KUBECONFIG_PATH CONTEXT，明确指定测试集群。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，使用 kind 的标准运行时配置，所有对象均属于本次临时实验。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-security-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 probe = '''from pathlib import Path
import errno,json,os,subprocess,time
status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
try:
 Path('/tmp/forbidden-write').write_text('x')
 raise AssertionError('root filesystem unexpectedly writable')
except OSError as error:
 assert error.errno==errno.EROFS
try:
 os.setuid(0)
 raise AssertionError('unexpected UID escalation')
except OSError as error:
 assert error.errno==errno.EPERM
work=Path('/work'); (work/'data').write_text('writable')
(work/'example.py').write_text("print('interpreted from the writable volume')")
ran=subprocess.check_output(['python3',str(work/'example.py')],text=True).strip()
result={'uid':os.getuid(),'gid':os.getgid(),'cap_eff':int(status['CapEff'].strip(),16),
 'no_new_privs':int(status['NoNewPrivs']),'seccomp':int(status['Seccomp']),
 'root_write_errno':errno.EROFS,'uid_zero_denied':True,
 'volume_value':(work/'data').read_text(),'writable_volume_code':ran}
assert result['uid']==result['gid']==10001
assert result['cap_eff']==0 and result['no_new_privs']==1 and result['seccomp']==2
print(json.dumps(result),flush=True); time.sleep(600)
'''
 podspec = spec(probe)
 podspec['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 10001,
 'runAsGroup': 10001, 'fsGroup': 10001, 'seccompProfile': {'type': 'RuntimeDefault'}}
 podspec['volumes'] = [{'name': 'work', 'emptyDir': {}}]
 c = podspec['containers'][0]
 c['securityContext'] = {'allowPrivilegeEscalation': False, 'readOnlyRootFilesystem': True,
 'capabilities': {'drop': ['ALL']}}
 c['volumeMounts'] = [{'name': 'work', 'mountPath': '/work'}]
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'restricted'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'restricted'), pod_ready)
 observed = json.loads(wait_for(lambda: k('logs', '-n', namespace, 'restricted').stdout.strip(), bool))
 conflicting = spec()
 conflicting['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 0}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'conflict'}, 'spec': conflicting})
 refused = wait_for(lambda: obj(namespace, 'pod', 'conflict'), lambda p:
 any(c.get('state', {}).get('waiting', {}).get('reason') == 'CreateContainerConfigError'
 for c in p.get('status', {}).get('containerStatuses', [])))
 waiting = refused['status']['containerStatuses'][0]
 assert 'runAsUser breaks non-root policy' in waiting['state']['waiting']['message']
 assert waiting['restartCount'] == 0
 print(json.dumps({'runtime_observation': observed,
 'conflicting_uid_accepted_by_api_but_container_start_refused': True,
 'container_escape_resistance_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

受约束 Pod 报告 UID 和 GID 均为 10001，有效能力为零，NoNewPrivs 为一，seccomp 模式为二。在根文件系统的 /tmp 下写入返回 EROFS，尝试切换到零号用户返回 EPERM。这些结果反映组合身份和权限设置的效果，不能单独归因为其中某个标志，也没有逐一隔离测量每个字段的独立贡献。

进程成功写入 /work 中的数值，并调用 Python 执行刚写在该卷里的文件。这个允许操作刻意展示工作卷仍然可用，以及只读根声明的边界。第二个 Pod 同时声明 runAsNonRoot 和 runAsUser 零，API 接受对象，但 kubelet 在容器启动前报告 CreateContainerConfigError，说明对象保存成功和进程成功启动是不同阶段。

全部断言通过，命名空间随后删除。实验验证这些具体运行时约束和启动失败，没有测试容器逃逸抵抗能力、每一条 seccomp 规则、敌对多租户隔离或应用授权模型。真实交付需要将这些设置与对应访问需求一起审阅，并保留允许与拒绝操作各自的实际证据。

来源

Kubernetes: Security Context，Pod 与容器安全字段及运行时效果，已核验 2026-09-13。
Linux: No New Privileges Flag，通过执行程序获取新权限的限制，已核验 2026-09-13。
Linux: capabilities(7)，独立能力权限与进程能力集合，已核验 2026-09-13。

证书透明度是一本台账，不是机密

Wed, 03 Nov 2027 00:00:00 +0000

证书透明度 CT 让公开 TLS 证书的签发变得可观察，但它不判断域名持有者是否授权了某次签发，不代替证书链验证，也不保证世界上所有证书都已经进入日志。一张错误签发的证书也可能带有有效的透明度证据。真正的价值是留下公共线索，供监控方和受影响的持有者调查。

承诺不等于包含证明

SCT 即签名证书时间戳，是日志对已提交证书或预证书作出的签名承诺：在最大合并延迟 MMD 以内把它纳入树中。SCT 不是另一张证书，也不是证明条目已经存在于树中的包含证明。它的时间戳记录日志作出声明的时刻，不一定就是证书实际签发的精确时刻。

默克尔包含证明把某个已经序列化的叶节点，连接到特定大小的树及其根哈希。验证者需要通过相应的已签名日志声明和可信日志公钥认证这个根。如果无条件接受不可信证明一起附带的根，攻击者完全可以自己构造另一棵树；计算结果相同，也没有建立任何有用的外部事实。

一致性证明回答的是另一个问题：后来的树是否在保持既有前缀不变的情况下扩展了早先的树。一次包含证明不能说明全部历史。签名检查点、一致性验证，以及独立观察者之间对不同视图的比较，有助于发现日志向不同人讲述不同历史。哈希让修改可以被这些检查发现，不是物理上禁止运营者改写数据。

Chrome 对公开受信任的 TLS 证书执行自己的 CT 策略，考虑 SCT 的交付方式、日志状态、数量与运营者多样性。这不是每次打开页面都到公共日志里搜索，也不是判断持有者是否申请过证书。RFC 9162 定义了第二版协议并废止 RFC 6962，但规范发布并不能直接证明某个已部署日志实际支持哪一版。

坏掉的样子

SCT 的签名即使有效，如果对应日志不被接受、数量不足或交付方式不符合目标客户端策略，仍然可能无法通过检查。反过来，符合 CT 也修复不了过期、不受信任或名称不匹配的证书。普通 TLS 验证、CT 合规和签发是否获准，是需要分别确认的三个决定。

域名监控也需要结合业务背景解释。新记录可能来自获准接入的 CDN、通配符证书或正常续签；升级告警之前应核对签发者、名称、指纹与内部签发清单。无法解释的签发应进入调查和纠正流程，不能假定“已经写进日志”就代表它被阻止或被确认合法。

公开日志可能暴露证书中的名称，因此不应仅为做实验就提交私有证书或敏感内部命名。监控覆盖不全、数据过旧，也不能证明某次签发不存在。运营上的监控要声明范围和更新时间，不能把一次空搜索结果当成所有日志、所有时间都没有相关证书的保证。

快速验证

保存为 ct_probe.go，使用 Go 1.23 或更新版本运行 go run ct_probe.go。程序离线使用 RFC 6962 的 SHA-256 默克尔构造，输入是三个合成字符串，不是真实证书，也不是已经按 CT 协议序列化的叶节点。它只验证这个固定三叶树中下标为一的中间叶节点，不是通用验证器。

package main

import (
 "crypto/sha256"
 "fmt"
 "runtime"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func leaf(data string) [32]byte {
 return sha256.Sum256(append([]byte{0}, []byte(data)...))
}

func branch(left, right [32]byte) [32]byte {
 var data [65]byte
 data[0] = 1
 copy(data[1:33], left[:])
 copy(data[33:], right[:])
 return sha256.Sum256(data[:])
}

// Only verifies index 1 of a three-leaf fixture; not a general CT verifier.
func middleOfThree(data string, proof [][32]byte, root [32]byte) bool {
 return len(proof) == 2 && branch(branch(proof[0], leaf(data)), proof[1]) == root
}

func main() {
 a, b, c := leaf("fixture-A"), leaf("fixture-B"), leaf("fixture-C")
 root := branch(branch(a, b), c)
 check(fmt.Sprintf("%x", root) == "111b905d16e9388f6e9079aaec820ab176d649b9daecabcdb3aca45fe4b6b646", "root differs from independent fixture vector")
 check(fmt.Sprintf("%x", leaf("")) == "6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d", "empty leaf vector differs")
 check(leaf("") != sha256.Sum256(nil), "an empty tree and an empty leaf are different")
 proof := [][32]byte{a, c}
 check(middleOfThree("fixture-B", proof, root), "correct inclusion proof must pass")
 check(!middleOfThree("fixture-X", proof, root), "altered entry must fail")
 badProof := append([][32]byte(nil), proof...)
 badProof[0][0] ^= 1
 check(!middleOfThree("fixture-B", badProof, root), "altered sibling must fail")
 check(!middleOfThree("fixture-B", [][32]byte{c, a}, root), "sibling order matters")
 check(!middleOfThree("fixture-B", proof[:1], root), "short proof must fail")
 check(!middleOfThree("fixture-B", append(proof, b), root), "extra proof element must fail")
 badRoot := root
 badRoot[0] ^= 1
 check(!middleOfThree("fixture-B", proof, badRoot), "wrong trusted root must fail")
 nextRoot := branch(branch(a, b), branch(c, leaf("fixture-D")))
 check(nextRoot != root, "appending an entry changes this fixture root")
 check(!middleOfThree("fixture-B", proof, nextRoot), "old proof must not verify against the new root")
 fmt.Println("correct proof accepted; altered entry, sibling, order, length, and root rejected")
 fmt.Println("empty tree differs from empty leaf; fourth entry changes root; old proof fails")
 fmt.Printf("three-leaf fixture root: %x\n", root)
 fmt.Println(runtime.Version())
}

叶子哈希先放值为 0 的前缀字节，再放数据；内部节点先放值为 1 的前缀字节，再连接左右子节点哈希。这些前缀把两类输入分开。三个叶节点时，左子树包含 A 与 B，右边单独放 C，不需要把它补成四个节点。空树和只有一个空叶节点的树，也应得到不同哈希。

正确证明只需要 A 与 C 的哈希。把它们与 B 重新组合，会得到预期根；该固定结果还用 Python hashlib 独立交叉核验过。修改 B、相邻节点、证明顺序、长度或预期根，都必须失败。追加 D 会改变本例的树根，旧的三叶树证明也不能再用来匹配这个新根。

已核验的 macOS、Go 1.27.0 运行通过全部断言。硬编码测试根只在本例中代表已经可信的三叶检查点，程序没有实现 SCT 签名、真实日志公钥验证、证书编码、网络查询、通用包含证明或一致性证明。特别是，观察到根变化本身不能证明日志只追加；浏览器策略执行与在线错误签发监控，仍是没有在本例中验证的独立操作。

来源

RFC 6962：证书透明度，第一版默克尔哈希、SCT 承诺与不同证明，已核验 2026-09-09。
RFC 9162：第二版证书透明度，协议范围、错误签发边界与版本沿革，已核验 2026-09-09。
Chrome 证书透明度策略，客户端特定的 SCT 与日志接受条件，已核验 2026-09-09。

SYN Cookie 在队列溢出时作答

Sat, 30 Oct 2027 00:00:00 +0000

监听套接字维护的是两个队列，不是一个。半开连接先待在 SYN 队列里，直到客户端的最后一个 ACK 到达；握手完成的连接随后进入 accept 队列，等着应用调用 accept()。两者各有各的上限，而究竟是哪一个溢出，决定了客户端体验到什么。

SYN Cookie 是为第一个队列准备的。它满了以后，服务器不再分配状态，转而把稍后需要的东西编进序号里，于是握手在零内存占用下完成。这确实是一次救援，同时也是一次降级：被救下来的那条连接，比正常情况下本该建立的那条更差。

两个队列，两种症状

一个 SYN 会分配一个 request socket，把连接推进 SYN_RECV 并回一个 SYN-ACK。客户端的 ACK 再把它移进 accept 队列、状态变成 ESTABLISHED。SYN 队列由 tcp_max_syn_backlog 按监听套接字限流——最小值 128，随内存放大，每个表项大约占 304 字节。accept 队列的上限来自 somaxconn（当前内核默认 4096，Linux 5.4 之前是 128），再与应用程序传给 listen() 的 backlog 共同起作用。

两种溢出长得完全不一样。SYN 队列溢出正是 syncookie 为之而生的场景：连接照样能完成。accept 队列溢出更糟也更安静——在 tcp_abort_on_overflow 取默认值 0 的情况下，服务器直接忽略那个最后的 ACK，于是 connect() 返回成功，客户端把请求发出去，然后再也等不到任何回应。实测：backlog 设为 1、客户端 400 个，400 个全都以为自己连上了，服务器实际只能接受 3 个，另外 397 个在两端都没有任何报错的情况下丢掉了。

tcp_syncookies 取默认值 1 时，SYN backlog 一溢出，内核就发 cookie。它不再分配 request socket，而是把初始序号算成「高 8 位放计数器、低 24 位放截断哈希」，哈希覆盖两端地址、两个端口、计数器和一个服务端密钥。计数器每 64 秒前进一格，所以同一个四元组在每一格上算出的 cookie 都不同。

校验过程就是把它倒过来。ACK 的确认号高 8 位带着计数器，服务器拿它和自己的当前格、上一格比对，再按四元组重算哈希并比较低 24 位。复现这套构造的结果是：刚发出的 ACK 校验通过；70 秒后重放的 ACK——也就是往前一格——依然通过；200 秒和 600 秒之后则被判为过期。把源端口或源地址改动一个，立刻被拒，所以 cookie 被绑死在这条连接上，无法搬到别处使用。盲猜的成功概率是 1677 万分之一，整个安全论证就靠这个数字。

带 cookie 的 SYN-ACK 不携带任何选项。内核文档说得毫不客气：syncookie「严重违反 TCP 协议，不允许使用 TCP 扩展，可能导致某些服务严重劣化」。代价最贵的是窗口缩放——没有它，接收窗口上限是 65535 字节，而不是缩放因子 7 下的 8388480 字节。在 100 毫秒的路径上，这就是 5.2 Mbit/s 对 671.1 Mbit/s，128 倍的差距，只因为少了一个选项。SACK 同样没了，于是一个窗口里丢了好几个段的发送方，只能靠累积确认一次恢复一个。

MSS 算是部分救回来了：cookie 路径偷走三个哈希位去索引一张小 MSS 表，而这是唯一活下来的选项。时间戳、SACK、窗口缩放则干脆不存在。所以处于 cookie 模式的服务器不只是少收了几条连接，它收下的那些连接本身是慢的，而这种慢看起来像网络问题，不像握手问题。

坏掉的样子

第一种失败，是 cookie 把真实的洪泛从监控视野里藏了起来。SyncookiesSent 上涨就是信号，但按设计，洪泛在应用层是隐形的：没有半开队列可告警、没有失败连接、没有错误日志，只有一个计数器。建立在错误率或 SYN_RECV 深度上的看板，会在服务器正被持续攻击时显示一切健康。要盯的是 cookie 计数器及其与新建连接数的比值，不是应用本身。

第二种失败，是 accept 队列照样溢出，而 cookie 对此毫无办法。ListenOverflows 上涨，客户端在第一个请求上超时，瓶颈在 accept() 而不在 SYN 队列——实测 400 条里丢掉 397 条，而每个客户端都以为自己连上了。解法是让应用接受得更快、加 worker、抬高 somaxconn 和 listen backlog，而不是去调 syncookie。要记住 cookie 只在 SYN 队列溢出时才启用：瓶颈若在 accept 队列，把它打开或关掉都不会改变任何数字。

快速验证

同时看两个队列和计数器：

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn
nstat -az | grep -E 'Syncookies|ListenOverflow|ListenDrops'
ss -lnt

健康的服务器上三个计数器都读 0，ss -lnt 里的 Send-Q 与配置的 backlog 一致，Recv-Q 为 0。SyncookiesSent 上涨说明 SYN 队列溢出过；ListenOverflows 上涨说明 accept 队列溢出过，而那一个不是 cookie 能修的。如果监听套接字的 Recv-Q 长期大于零，说明已建立的连接正在等一个调用 accept() 不够快的应用。

来源

RFC 4987 TCP SYN 洪泛缓解，cookie 的构造方式及其取舍，已核验 2026-09-16。
RFC 9293 TCP，三次握手与 backlog 的概念，已核验 2026-09-16。
Linux 内核 ip-sysctl，tcp_syncookies、tcp_max_syn_backlog、somaxconn 与 tcp_abort_on_overflow，已核验 2026-09-16。

TLS ECDHE 保证前向保密

Wed, 27 Oct 2027 00:00:00 +0000

前向保密限制的是长期认证密钥日后泄露造成的影响。对于经过正确认证的临时 Diffie-Hellman 交换，攻击者仅取得长期认证私钥，不能据此恢复先前的会话机密。前提是临时机密没有一起被获取；它不会让已经被攻破的端点、导出的密钥日志或保存下来的明文突然变得安全。

两类密钥承担不同职责

ECDHE 中，双方分别生成临时私钥并交换公开份额。每一方把本地私钥与对方公开份额组合，得到相同的共享机密。旁观者虽然能看到公开份额，但在算法的安全假设成立时，缺少重现计算所需的私有值。新鲜的交换材料并不是双方在网络上公开商量出的一段秘密口令。

TLS 也不会把原始 ECDH 输出直接当成应用加密密钥。密钥调度还会派生不同的握手与应用流量机密，绑定握手上下文，并区分方向和用途。临时交换只提供其中一项关键材料，不能用“双方算出相同字节”替代整个传输协议，也不能略过后续派生和认证步骤。

证书按照信任规则把身份绑定到公钥，实际签署握手材料的是对应的私钥，不是证书这个数据对象自己在签名。TLS 1.3 的证书认证路径通过 CertificateVerify 认证握手记录。如果没有身份认证，主动中间人可以替换公开份额，分别和两端建立自己的共享机密；仅仅看到加密正常，并不能排除这种攻击。

RSA 或 Ed25519 认证密钥可以与临时交换并存，签名算法和密钥交换组是不同选择。TLS 1.3 还定义了仅使用 PSK 的恢复模式，后者不具备 DHE 带来的这项前向保密；PSK 配合 DHE 则会加入新的交换材料。可选 early data 的保证更弱，因此不能单凭 TLS 版本或证书算法标签，就推断所有阶段的流量都有相同保护。

坏掉的样子

长期重复使用同一个交换私钥，会削弱原本希望建立的泄露边界。随机数不足、临时私有值暴露、崩溃转储或 TLS 密钥日志，都可能泄露前向保密假设中不能被攻击者取得的材料。日后泄露流量机密，与日后泄露证书签名私钥，不是同一个威胁场景，不能混用结论。

会话进行时攻破端点，可能直接取得明文。长期认证私钥失窃后，能够拦截未来连接的攻击者也可能冒充服务器。前向保密保护的是特定的历史录制流量场景，并不会撤销泄露凭据，也不会修复仍在持续的入侵；这些问题仍需要独立的凭据轮换与事件处置。

机密销毁更是实现层面的问题，不能仅靠一句“用完就丢弃”来保证。把 Go 变量设为 nil，不证明内存、交换空间或诊断材料中的所有副本都已消失。应避免把机密写进日志，并把凭据失窃的处置与历史流量是否仍受保护的判断分开，不能用概念上的前向保密替代真实的数据暴露调查。

快速验证

保存为 ecdhe_probe.go，使用 Go 1.23 或更新版本运行 go run ecdhe_probe.go。程序在内存中调用标准库的 X25519 与 Ed25519。签名公钥在这个实验里代表已经可信的身份；被签署的消息明确不是 TLS 握手记录。这是一项密码原语层面的实验，不是另一套 TLS 实现，也不能作为上线加密通道的配方。

package main

import (
 "bytes"
 "crypto/ecdh"
 "crypto/ed25519"
 "crypto/rand"
 "fmt"
 "runtime"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 identity, signingKey, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 curve := ecdh.X25519()
 var previous []byte
 for round := 1; round <= 2; round++ {
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 server, err := curve.GenerateKey(rand.Reader)
 must(err)
 message := []byte("ECDH learning probe; not a TLS transcript\x00")
 message = append(message, client.PublicKey().Bytes()...)
 message = append(message, server.PublicKey().Bytes()...)
 signature := ed25519.Sign(signingKey, message)
 check(ed25519.Verify(identity, message, signature), "trusted signature must verify")
 altered := append([]byte(nil), message...)
 altered[len(altered)-1] ^= 1
 check(!ed25519.Verify(identity, altered, signature), "altered share must fail authentication")

 clientSecret, err := client.ECDH(server.PublicKey())
 must(err)
 serverSecret, err := server.ECDH(client.PublicKey())
 must(err)
 check(bytes.Equal(clientSecret, serverSecret), "peers must agree")
 if previous != nil {
 check(!bytes.Equal(previous, clientSecret), "fresh exchange must produce a different observed secret")
 }
 previous = clientSecret
 fmt.Println("round", round, "agrees; altered share fails signature verification")
 }
 _, err = curve.NewPublicKey(make([]byte, 31))
 check(err != nil, "wrong-length X25519 key must fail parsing")
 zero, err := curve.NewPublicKey(make([]byte, 32))
 must(err)
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 _, err = client.ECDH(zero)
 check(err != nil, "all-zero shared result must be rejected")
 fmt.Println("two fresh exchanges differ with one signing identity; malformed and low-order inputs rejected")
 fmt.Println(runtime.Version())
}

每一轮中，双方计算出的共享机密必须相同；两轮都生成新的交换密钥，因此本次观察到的两个共享结果必须不同，而认证签名始终使用同一对身份密钥。篡改已签署公开份额消息中的一个字节，会使签名验证失败，说明交换材料与身份认证不能各做各的、互不关联。

反向测试还覆盖了公钥输入边界：三十一字节的 X25519 公钥在解析时就被拒绝；长度正确但全零的输入可以通过长度检查，却会在 ECDH 阶段因全零结果而失败。不能把“公钥对象创建成功”当成共享机密一定可用，后续算法调用的错误仍然需要检查和处理。

已核验的 macOS、Go 1.27.0 运行通过全部断言，只输出结果标签。程序为了对照，刻意保留了前一轮共享机密，所以它没有证明安全擦除，也没有通过穷举证明密码学难度。比较观察到的两组结果，不能扩大成对所有随机输出永不重复的数学承诺。

实验分别观察了密钥协商、一轮一换、签名认证和非法输入处理，但没有执行真实 TLS 握手记录、证书链验证、流量密钥派生、报文加密、会话恢复或生产密钥销毁。实际通信应交给持续维护的 TLS 实现，并核验协商模式；把这些原语拼到一起，还不足以构成安全的传输协议。

来源

RFC 8446：TLS 1.3，CertificateVerify、密钥调度、PSK 模式与前向保密边界，已核验 2026-09-09。
Go crypto/ecdh，X25519 协商与非法公钥行为，已核验 2026-09-09。
Go crypto/ed25519，签名与验证操作，已核验 2026-09-09。

内核把设备噪声转成密钥

Fri, 22 Oct 2027 00:00:00 +0000

即便一台很安静的服务器，在真正需要随机数之前也早就完成了播种，所以今天还会出问题的随机性事件几乎都不是「熵不够」，而是「状态被重放」：镜像里烤死的种子、被恢复的快照、回滚到上一次重播种之前的状态。内核并不朝你一滴一滴地滴熵；它把一点点设备噪声浓缩成一个生成器，然后无限地吐密钥流。

这个反转正是为什么围绕熵的大部分运维经验已经失效。盯着 entropy_avail、为取密钥去读 /dev/random、装一个补熵守护进程，这三件事针对的都是内核早已不再存在的稀缺；而真正会毁掉密钥的那件事——两台机器拿到同一个种子——在这些习惯里一个都看不出来。

熵池是输入，生成器是产物

内核把物理噪声混进来：中断时序抖动、设备延迟、平台自带的硬件随机数发生器，以及基于 CPU 的 jitterentropy；再用 BLAKE2s 把它们抽取进熵池。熵池给一组 ChaCha20 CRNG 播种，真正产出字节的是这些 CRNG。播种之后收集仍在继续，生成器也会被周期性重播种，但你已经吐出去的每一个字节，其强度由它出生时的那个状态决定，之后再发生什么都改不了。

一旦初始化完成，输出就是密钥流，而不是有限资源。entropy_avail 稳定在 256 位，也就是一个 ChaCha20 密钥的长度，而且你读它它也不会掉；读走 1 MiB 不消耗任何池内配额。random(4) 至今仍把 entropy_avail 描述成 0 到 4096 之间的取值、把 poolsize 描述成 Linux 2.6 之后固定 4096 位——正是这类文档让一条过期的告警一直活着。

/dev/random 不再是「更谨慎」的选择

从 Linux 5.6 起，/dev/random 在早期启动之外不再阻塞，其上的 O_NONBLOCK 也被忽略。那个独立的阻塞池已经消失，剩下的只是同一个生成器顶着历史名字。getrandom(2)（Linux 3.17 引入）默认从 urandom 源取数，只在那个源尚未初始化时阻塞；GRND_NONBLOCK 把这种阻塞变成 EAGAIN，GRND_RANDOM 则改为选择 random 源，也就是那个仍然可能无限期阻塞的源。

random(7) 把话说得很直：除非你在做长期密钥生成，而且多半连那种场景也不必，否则不要读 /dev/random，也不要传 GRND_RANDOM。初始化完成后，一次不超过 256 字节的读取总是完整返回，也不会被信号打断。所谓「更安全」的接口，代价是一次可能永久挂住的调用。

真正要紧的窗口只有启动那一小段

真正的故障发生在初始化完成之前，内核会用一行 crng init done 宣告它结束。没有种子文件的机器只能从设备噪声里慢慢攒；有种子文件、有 virtio-rng 设备或 RDRAND 的机器则立刻就有。random(4) 给的办法仍然最便宜：关机时从 /dev/urandom 用 dd 取 512 字节写进权限 600 的种子文件，开机时在任何东西索要密钥之前把它 cat 回 /dev/urandom。

差距非常悬殊：一个 32 字节的种子文件，或者一次 virtio-rng 读取，立刻就能跨过 256 位的初始化门槛；纯靠中断的启动则要先攒够成千上万个样本。所以「密钥是在 crng init done 之前还是之后生成」是一个配置问题，而不是运气问题。

坏掉的样子

第一种故障是首次启动取密钥时卡住。某个单元在第一次启动时就生成 TLS 密钥或 token 密钥，可能在初始化完成前调用 getrandom()，然后就那么挂着，日志里一句有用的话都没有。无盘机器、小型路由器、从冻结文件系统恢复的虚拟机，以及没有熵设备的容器，是常见的受害者。把密钥文件的 mtime 和那行 crng init done 对比一下：比它更早的密钥，就是从没初始化的生成器里出来的。

第二种故障是无声的，因为没有任何东西阻塞，所有看板都很健康。给虚拟机做快照、回滚，或者用同一个黄金镜像批量开出十台云主机，每一份副本都会带着同一个生成器状态和同一个种子文件继续跑。于是它们吐出完全相同的 SSH 主机密钥、来自 /proc/sys/kernel/random/uuid 的重复 UUID，以及互相重叠的 TLS 会话票据；谁拿到其中一台的输出，就能预测它的兄弟们。共享同一个烤死种子的十份克隆只产生了一个不同指纹，重新播种的十份则产生了十个。要从镜像里删掉种子，并在首次启动时重新生成主机身份。

快速验证

按顺序执行这四条命令：

dmesg | grep -i "crng init done"
cat /proc/sys/kernel/random/entropy_avail /proc/sys/kernel/random/poolsize
python3 -c 'import os; print(os.getrandom(8, os.GRND_NONBLOCK).hex())'
stat -c '%y %n' /etc/ssh/ssh_host_ed25519_key /var/lib/random-seed

在现代内核上，计数器读数是 256，poolsize 读数是 4096：第一个数字是密钥长度，不是油表，所以读数偏低并不需要去修。getrandom 那一条应当立刻返回八个十六进制字节；如果抛 BlockingIOError，说明这个源还没初始化，而一次阻塞调用会就此停住。stat 的输出才是真正的检查——如果主机密钥的时间戳早于 crng init done 那一行，这把密钥就来自未初始化的生成器，应当轮换。

来源

Linux random(4) 设备，/dev/random 与 /dev/urandom 语义、entropy_avail 与 poolsize，以及种子文件的写法，已核验 2026-09-16。
Linux getrandom(2)，GRND_NONBLOCK 与 GRND_RANDOM，以及 urandom 源未初始化时的阻塞行为，已核验 2026-09-16。
Linux random(7)，三种接口的对比表，以及何时不该用 GRND_RANDOM，已核验 2026-09-16。
ArchWiki：随机数生成，用 BLAKE2s 抽取并为 ChaCha20 CRNG 播种，以及 entropy_avail 为何停在 256，已核验 2026-09-16。

签名镜像可以证来源

Thu, 21 Oct 2027 00:00:00 +0000

容器镜像的引用是一个可变指针，摘要则不可变。签名把摘要和一把密钥绑在一起，于是校验方能在运行之前先问：这些字节出自谁手。这正是 registry 与清单层回答不了的问题——它们只能告诉你字节从哪里来，不能告诉你谁做的。

张力在于：签名只有在被校验时才是一项控制，而校验只有在信任根被管理好时才有意义。签名只是流水线里的几行；决定哪些密钥算数、一把密钥退役之后怎么办，才是真正的工程。

摘要是身份，标签是指针

摘要是对精确清单字节的哈希，镜像一变摘要就变。对摘要签名，就是把签名绑在内容上而不是名字上。用 EC P-256 密钥对、真实的 SHA-256 摘要和一份 cosign 形状的载荷，openssl dgst -verify 返回成功；把产物翻转一个字节，摘要随之改变，同一次校验返回失败。

标签的行为不同。三个标签指向同一个已签名摘要，全都能通过校验，因为标签从来不在被签名的载荷里。这正是设计：标签是指向摘要的指针，改指向是常规的 registry 操作。把标签挪到一个从未被签名的摘要上，对解析后摘要的校验就会失败——但前提是校验方先去解析标签，而不是直接相信你手上那个可变的引用。

对标签签名绑不住任何东西

如果签的是字符串 app:v2 而不是摘要，校验就会永远成功，因为这个字符串永远不变。把那个标签指向一个完全不同的镜像，签名照样通过：它对一个字符串说了真话，而这个字符串对字节什么都没说。所以签名必须签在摘要上，校验必须先解析标签再比对。

信任根是另一半。签名只证明「持有私钥的人产出了它」；公钥，或者一张由 Fulcio 签发、并配有一条 Rekor 日志条目的证书，才把它变成「这个身份构建了它」。分发和轮换这个锚点就是安全边界，而它完全在签名之外。

校验才是控制，签名不是

流水线签完名就直接部署、不做校验，买到的只是装饰。实测对比很直白：被篡改的产物在部署步骤做校验时被挡住；同一条产物在部署步骤只记录来源信息时顺利上线——而那份来源记录从此写着被篡改的摘要。强制点应该在准入，或者部署前的一道闸门，让未签名的镜像根本到不了节点。准入控制器在这里的价值，是它不依赖流水线的自觉：策略在对象进入集群的那一刻求值，跳过签名不是「忘了做」，而是直接失败。

撤销是签名内部完全没有答案的那部分。签名没有有效期、没有吊销列表：在它的密钥下永远有效。轮换密钥并不能撤销任何东西——旧签名在新密钥下被拒，在旧密钥下依旧被接受——所以任何持有已退役密钥的人都能继续产出可通过校验的产物。解法是配短时效证书和透明日志的信任根，再加上钉住身份的策略，而不只是检查「存在某个签名」。

坏掉的样子

最经典的是策略引擎从未检查过的未签名镜像。流水线签名，部署步骤按标签拉取并运行，而这个缺口在有人往同一标签推入不同字节之前一直不可见。审计记录从此为一份没人校验过的镜像声称来源，这比完全没有来源记录更糟。

第二种是签名能通过、但签名所用的密钥你已经不再信任。因为签名内部没有撤销机制，泄露或已退役的密钥会继续签出可接受的产物，而爆炸半径是那把密钥签过的每一个产物，且是回溯性的。在策略里钉住签名身份，让证书保持短时效，并把签名记进透明日志，这样一把意料之外的密钥会以一条日志条目出现，而不是一次无声通过。

快速验证

校验摘要，再确认标签仍然指向它：

cosign verify --key cosign.pub registry.example.com/app@sha256:9ab5a134...
cosign tree registry.example.com/app@sha256:9ab5a134...
skopeo inspect --format '{{.Digest}}' docker://registry.example.com/app:latest

cosign verify 必须打印出被校验的身份并以 0 退出，cosign tree 应列出挂在该摘要上的签名与证明。skopeo inspect 必须打印出你刚校验过的同一个摘要。错误的结果是：verify 报找不到匹配的签名，或者 verify 成功而 skopeo 报出另一个摘要——那意味着标签现在指向从未被签名的字节。

来源

Sigstore：用 cosign 校验签名，基于密钥与无密钥的摘要校验，已核验 2026-09-16。
SLSA v1.0 规范，来源信息、摘要，以及签名到底在证明什么，已核验 2026-09-16。
Sigstore policy-controller，在准入阶段强制签名与身份策略，已核验 2026-09-16。

OAuth 授权码用码换令牌

Wed, 20 Oct 2027 00:00:00 +0000

让令牌只留在后端、只把短命的一次性 code 交给浏览器，能从很大程度上缩掉令牌在 URL 与日志里被偷走的地盘。

浏览器只拿 code

access token 不该出现在浏览器里，这正是授权码流程存在的理由。浏览器跳转到授权端点、看到确认页，然后带着一个短命的一次性 code 回到回调地址——它从头到尾拿不到 token 本身。因为真正拿 token 的是后端：后端拿着 code，配上自己的 client secret，去 token 端点换。这个分工——浏览器只搬运 code，后端才掌握 secret——就是整个流程的意义所在。

后端负责兑换

交换发生在服务端，意味着 access token 只落在后端手里：浏览器既不会把它记进历史，客户端一次脚本 bug 也不会把它泄漏出去。后端构造 code + client_secret + redirect_uri 发给 token 端点，换回一个 JSON 的 access token（可选地还有 refresh）。这也解释了为什么没有 client secret 的单页应用（SPA）与原生应用，在这里总是敏感目标：它们没有 secret，所以需要哪「authorization code + PKCE」的组合，而不是普通 code flow。code flow 用一次后端的往返，换来 token 不经过浏览器这份安全。

code 一次性且短命

一次性、短时效，是 code 与生俱来的两重防线：一个已经用过一次的 code 无法被重放，一个放着不用的 code 也会在很短的存活窗口里自己过期。要把它收得更紧，就把 code 严格绑定到发起请求时的 redirect_uri——配合 PKCE 的 code_verifier，即便 code 被拦截，没有客户端持有的 verifier，攻击者也无法兑换。要真正防住这类「魔法」，就把它设计成只能换一次、且只在发起时的现场兑换，一次用完即作废。

坏掉的样子

泄露的授权码在存活期内等同于口令。典型症状是回调地址带着授权码被记进访问日志、浏览器历史、来源头或者崩溃报告，多因服务端打印完整地址，或者回调仍走明文传输。允许重复兑换或把有效期放宽到十分钟，等于把一次拦截变成一次成功的兑换。对策是硬规则：回调使用加密传输，日志不记完整地址，有效期压缩到分钟级，首次兑换成功即作废。

校验宽松的重定向地址会把授权码亲手送给攻击者。故障表现是授权端点接受前缀匹配、多余斜杠或者从未登记的主机，攻击者用相似域名也能收到受害者的授权码，随后在自己的站点完成兑换。正确做法看起来笨拙却有效：上线前逐条预登记回调地址，授权请求与兑换请求携带的地址必须逐字相等，任何不一致都要直接拒绝，而不是尝试容错或者自动修正。

缺失证明密钥的公共客户端最先受伤。单页应用与移动应用没有密钥可保管，一旦授权请求缺少挑战值，拦截者拿走授权码就能抢先兑换。排查时可见授权地址根本没有挑战参数，或服务端仍兼容较弱的明文方式，而未强制哈希挑战。每次授权都应生成高熵随机串，只传输其哈希值，兑换时重新计算并比对，不一致就拒绝。

长期不变的刷新令牌会把一次失守拖成持久入侵。缺少轮转时，一枚被盗的刷新令牌可以无限续出新的访问令牌；缺少重用检测时，同一枚令牌在两个位置先后使用，服务端也毫无察觉。线索是令牌端点多次返回相同的刷新令牌，或者并发刷新居然全部成功。每次刷新都应签发新令牌并把新旧串联成链，一旦作废令牌再次出现，就吊销整条链。

快速验证

把下面程序保存为临时目录里的对照实验，运行即可验证一次性与挑战校验两条契约。整个模型只用标准库里的哈希、随机数与编码模块，在内存里扮演一个授权服务端，不依赖网络账号，也不会向外发送任何请求。脚本先签发一枚绑定回调地址与哈希挑战的授权码，然后依次演练正常兑换、重放、错误校验串与错误回调地址四种情形。

import base64
import hashlib
import secrets


def make_challenge(verifier: str) -> str:
 digest = hashlib.sha256(verifier.encode("utf-8")).digest()
 return base64.urlsafe_b64encode(digest).rstrip(b"=").decode("ascii")


CODES: dict[str, dict] = {}


def authorize(code: str, challenge: str, redirect_uri: str) -> None:
 CODES[code] = {"challenge": challenge, "redirect_uri": redirect_uri, "used": False}


def exchange(code: str, verifier: str, redirect_uri: str) -> str:
 entry = CODES.get(code)
 if entry is None:
 raise AssertionError("unknown code")
 if entry["used"]:
 raise ValueError("code already used")
 if redirect_uri != entry["redirect_uri"]:
 raise ValueError("redirect_uri mismatch")
 if make_challenge(verifier) != entry["challenge"]:
 raise ValueError("PKCE verifier mismatch")
 entry["used"] = True
 return "access-token-" + secrets.token_hex(4)


verifier = secrets.token_urlsafe(32)
challenge = make_challenge(verifier)
redirect = "https://app.example/callback"
authorize("code-one", challenge, redirect)
token = exchange("code-one", verifier, redirect)
assert token.startswith("access-token-")

try:
 exchange("code-one", verifier, redirect)
 raise AssertionError("replay should have been rejected")
except ValueError as exc:
 assert str(exc) == "code already used"

authorize("code-two", challenge, redirect)
try:
 exchange("code-two", "wrong-verifier", redirect)
 raise AssertionError("wrong verifier should have been rejected")
except ValueError as exc:
 assert str(exc) == "PKCE verifier mismatch"

try:
 exchange("code-two", verifier, "https://evil.example/callback")
 raise AssertionError("wrong redirect should have been rejected")
except ValueError as exc:
 assert str(exc) == "redirect_uri mismatch"

print("PASS: one-time code, S256 PKCE, and exact redirect_uri all enforced; replay refused")

第一次携带正确校验串与一致回调地址兑换会成功并返回令牌。同一枚授权码第二次兑换必然失败，因为服务端已把它标记为已使用；校验串错误或回调地址不一致同样会被拒绝。断言把这份契约写死，全部通过后最后一行会打印成功字样。演示省略客户端认证、过期时钟与持久化存储，上线前仍需对照真实配置逐项复核。

来源

RFC 6749 授权码流程，定义授权码流程，已核验 2026-03-02。
RFC 7636 公共客户端证明密钥，校验串与哈希挑战，已核验 2026-03-02。
OWASP OAuth2 备忘单，重定向校验、证明密钥与令牌存储建议，已核验 2026-03-02。

请求走私把代理链路带偏

Tue, 19 Oct 2027 00:00:00 +0000

一条 HTTP/1.1 请求并不会自己说明它在哪里结束。它的边界是算出来的——靠 Content-Length，或者靠 chunked 传输编码——而链路上的每一跳都在各自独立地算。请求走私，就是两跳从同一串字节里算出了不同答案时发生的事。

RFC 9112 后来把规则写明了：Transfer-Encoding 压过 Content-Length；服务端可以拒绝同时带两者的报文；无论怎么选，之后都必须关闭连接。这在纸面上堵住了缝。真实的链路里仍然有早于这条规则的一跳、下游只会说 HTTP/1.0 的一跳，以及一个在入口终结 HTTP/2、再向内重新按 HTTP/1.1 组帧的边缘层。攻击就住在这些分歧里。

两个解析器，一条消息边界

组帧规则是有优先级的。若存在 Transfer-Encoding 且 chunked 是最后一个编码，报文体一直读到那个长度为 0 的终止块为止；否则一个合法的 Content-Length 给出字节数；两者都没有的请求没有报文体。当两个头同时出现，规范说 Transfer-Encoding 胜出——但只读 Content-Length 的那一跳会提前停下、把余下的字节转发出去，而那些余下的字节就是攻击。

实验把两者放在真实的 socket 上：前端按 Content-Length 组帧、原样转发字节，后端按 Transfer-Encoding 组帧。攻击者的 POST 同时声明 Content-Length: 57 与 Transfer-Encoding: chunked，报文体是 0\r\n\r\n 再加一条完整的请求。对前端来说那是一个 57 字节的报文体；对后端来说，chunked 报文体是零字节，后面那条请求是一条新报文。一条请求变成了两条，而前端从未见过后一条。

分歧的四种形状

CL.TE 就是实验里的情形：前端数字节，后端信 chunked。TE.CL 是镜像：前端解 chunked，后端数字节，于是攻击者把一条请求藏进后端读作 chunk 的那段内容里。TE.TE 是两跳都尊重 Transfer-Encoding，却对头是否合法意见不一：Transfer-Encoding: chunked 对上 Transfer-Encoding: xchunked、重复的头、或者 obs-fold 折行续行。其中一跳拒绝解码，chunked 的那串字节就变成了一条请求。CL.CL 是两个互相矛盾的 Content-Length 值，而两跳各挑了不同的那个。

每一种变体都是同一个失败换了套衣服：这条报文有一种以上说得通的解释，而链路没有就「用哪一种」达成一致。这就是为什么「把头部规范化」是个错的心智模型：你没法把一个你不掌控的解析器规范化，只能拒绝转发有歧义的报文。实验里那个严格的前端正是这么做的——同时带两个头的请求拿到 400、根本不会被转发——后端于是始终保持同步。

连接上的下一条请求才是载荷

走私进来的那条请求本身什么也做不了。它躺在后端的接收缓冲区里，直到同一连接上来了下一条请求，后端这才去回答那条走私请求，而受害者拿到的是那份响应。实验里受害者请求 /home，收到的却是走私出去的 GET /admin 的响应。攻击者从未认证、从未通过前端的路由规则，也从来不需要知道受害者是谁。

这就是它比一个解析器 bug 更麻烦的地方。前端的 ACL、限流、WAF 规则与审计日志描述的都是它解析出来的那条请求，而走私的那条不是它。它还会毒化这条连接上随后到来的一切：请求落在走私请求之后的用户，可能收到别人的响应，于是一次失步变成了会话数据泄漏。只修一跳不够——失步需要两个解析器，但它们只要差一个字节就够了。

坏掉的样子

特征就是两份对不上的访问日志。前端记下两条请求，后端记下三条，多出来的那条就是异常：后端日志里有一个 URL 在前端找不到对应条目、一条边缘层从未路由过的路径、或者只有其中一层吐出的 400。诊断方式是拿同一时间窗内各层的请求数与路径做 diff，并且直接去测组帧规则，而不是相信厂商文档。

第二种失败是只覆盖一跳的防御。在边缘层加一个头部检查，对下游那个把 HTTP/2 重新组帧成 HTTP/1.1 的一跳毫无作用，因为歧义是在检查之后才被制造出来的。优先做到端到端的 HTTP/2——它没有 chunked 编码，也禁止那些连接专用字段——若降级不可避免，就让边缘层拒绝有歧义的组帧，并且绝不让一条连接跨越信任边界复用。只加固前端而后端依旧宽容，改变的只是攻击者会挑哪一跳。

快速验证

发出那条有歧义的报文，然后数响应的条数：

printf 'POST / HTTP/1.1\r\nHost: edge.example.com\r\nContent-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /admin HTTP/1.1\r\nHost: edge.example.com\r\n\r\n' | nc -q1 edge.example.com 80 | tee /tmp/smuggle.out
grep -c '^HTTP/1.1' /tmp/smuggle.out
curl -s -o /dev/null -w 'h2 -> %{http_code} %{http_version}\n' https://edge.example.com/

加固过的边缘层只会给出一个状态行——针对这条有歧义报文的 400，或者只针对那个 POST 的 200——绝不会为 /admin 再回一条响应。出现两个状态行，或者出现了回答走私路径的响应体，就说明两层不一致。第三条命令应当报出 2：如果边缘层在内部降级到 HTTP/1.1，那么无论客户端协商出什么，组帧规则依旧在生效。

来源

RFC 9112：HTTP/1.1，报文体长度的判定，以及对有歧义组帧必须拒绝或关闭连接的要求，已核验 2026-09-16。
PortSwigger：HTTP 请求走私，CL.TE 与 TE.CL 两类形态及其影响，已核验 2026-09-16。
RFC 9113：HTTP/2，为何 chunked 编码与连接专用字段在 HTTP/2 中不存在，已核验 2026-09-16。

JWT 带着签名与寿命

Mon, 18 Oct 2027 00:00:00 +0000

把载荷当成公开信息，用签名保证其完整，一旦看见过期时间已过去就果断拒绝，别让一枚重放令牌活得比它该活的更久。

编码不加密

JWT 不是靠藏来保证安全的;它由 header、claims 与签名三段用 base64url 编码,用点连起来。任何拿到令牌的人都能反解出编码,逐条读出全部 claims。这是刻意为之,却也带来一条硬规矩:里面绝不允许放任何秘密——不能放密钥、不能放只有服务端才该看的会话数据。凡是你不会写进公开日志的东西,就别塞进 claim;需要回查的值用 jti 去查表,而不是直接放在载荷里。编码只是为了便于携带,不构成任何层面的保密。

签名先行为先

令牌只有在消费方先验证后才可信。正确的顺序是:先用信任、且认得出是签发者在握的那把钥匙去验签名,然后再去读 claims、核 audience。跳过签名、或是信 header 里 alg 的验签器,是最经典的失守姿势,因为伪造者只要把 alg 改成 none,或者把自己的公钥交出去,就能被当成真货。所以应把算法白名单钉死,核对签发者,不接受陌生方,绝不让令牌自己告诉你要用哪把钥匙。密钥与链路是信任的根基,要由可配置的密钥管理来决定,而不是由 token 自己说了算。

过期即契约

签名证明的是谁写了这枚令牌,而不是它多活到什么时候。exp 是它的寿命边界,必须强制执行:哪怕签名还新鲜,exp 一旦过去也该被拒绝。真实系统会留一点有界的时钟偏差,让刚签发出来的令牌别被 NTP 的几秒时钟偏差误杀,但绝不能盖过令牌本身的生命期。凡涉及敏感数据,都要配合基于 iat 的短租期,因为否则这枚状态无关、无法单点吊销的令牌会一路活到结束。过期即契约,也是唯一能让一枚被偷或重放的令牌不活过自己窗口的保障。

坏掉的样子

最典型的失守是验签器信任令牌自带的算法头。攻击者复制一份合法载荷,把头部改成无签名算法,去掉第三段签名,跳过验签的服务端就会直接放行。这不是载荷写错,而是验签路径被令牌劫持。对策是服务端钉死算法白名单,只接受一种算法家族,直接拒绝无签名算法,不根据头部切换逻辑,可接受算法写在配置里。

第二类经典故障是公钥与对称密钥之间的混淆。当同一个验签器同时接受非对称与对称算法,攻击者就能把本就公开的公钥拿来当作对称密钥,用它签发伪造令牌。验签器用同一份公开值去计算校验值,结果恰好能对上,伪造令牌就被当成真货。防范办法是每个签发者只允许一种算法家族,两类密钥分开存放,标识只做本地查表键,不指向文件路径或外部地址。

缺时间戳的故障最安静。没有过期时间的令牌永远不会过期,偷走之后可以一直用到密钥轮换;没有签发时间就没有锚点,时钟偏差检查与寿命审计都无从谈起。即使两者都有,若寿命动辄数天,一次泄露就等于长期会话。对策是签发时必带过期与签发时间,验签时强制检查,敏感接口只给几分钟租期,时钟容忍只给几十秒。

无状态带来的注销难题必须提前承认。服务端不存会话,就无法单独吊销某一枚令牌,登出时要么等它自然过期,要么维护标识黑名单。生产做法是短过期配合黑名单,登出即拉黑,敏感操作再回查服务端。同时牢记载荷只是编码,人人可读,不放口令与敏感信息,保密值只放引用标识,内容留在服务端按需查询。

快速验证

把下面代码存为验证脚本,用命令运行。全程只用标准库手写签发与验签,让签名比对过期检查与篡改拒绝都看得见。不依赖第三方包,不联网,用负寿命模拟过期,用改动载荷首字符模拟篡改。

import base64
import hashlib
import hmac
import json
import time

SECRET = b"demo-secret-key-change-me"


def b64url_encode(raw: bytes) -> str:
 return base64.urlsafe_b64encode(raw).rstrip(b"=").decode("ascii")


def b64url_decode(data: str) -> bytes:
 padding = "=" * (-len(data) % 4)
 return base64.urlsafe_b64decode(data + padding)


def issue(subject: str, lifetime: int = 600) -> str:
 header = b64url_encode(
 json.dumps({"alg": "HS256", "typ": "JWT"}, separators=(",", ":")).encode()
 )
 now = int(time.time())
 payload = b64url_encode(
 json.dumps(
 {"sub": subject, "iat": now, "exp": now + lifetime},
 separators=(",", ":"),
 ).encode()
 )
 signature = b64url_encode(
 hmac.new(SECRET, f"{header}.{payload}".encode(), hashlib.sha256).digest()
 )
 return f"{header}.{payload}.{signature}"


def verify(token: str) -> dict:
 header_b64, payload_b64, signature_b64 = token.split(".")
 header = json.loads(b64url_decode(header_b64))
 assert header.get("alg") == "HS256", f"unexpected alg: {header.get('alg')}"
 expected = b64url_encode(
 hmac.new(SECRET, f"{header_b64}.{payload_b64}".encode(), hashlib.sha256).digest()
 )
 assert hmac.compare_digest(expected, signature_b64), "bad signature"
 claims = json.loads(b64url_decode(payload_b64))
 assert "exp" in claims and "iat" in claims, "missing exp/iat"
 assert int(time.time()) < int(claims["exp"]), "token expired"
 return claims


token = issue("demo-user")
claims = verify(token)
assert claims["sub"] == "demo-user"
print(f"valid: sub={claims['sub']}")

stale = issue("demo-user", lifetime=-10)
try:
 verify(stale)
 raise AssertionError("expired token must not verify")
except AssertionError as exc:
 assert str(exc) == "token expired", exc
 print("expired correctly rejected: token expired")

head, pay, sig = token.split(".")
tampered_pay = ("A" if pay[0] != "A" else "B") + pay[1:]
try:
 verify(f"{head}.{tampered_pay}.{sig}")
 raise AssertionError("tampered token must not verify")
except AssertionError as exc:
 assert str(exc) == "bad signature", exc
 print("tampered correctly rejected: bad signature")

print("PASS: valid accepted; expired and tampered rejected")

脚本先签发正常令牌并验签通过,证明正常路径畅通。再用负寿命签发过期令牌,确认以过期原因拒绝。最后篡改载荷首字符,确认以签名不匹配拒绝。三组断言覆盖正常过期与伪造三种行为。预期输出共四行,分别是主体一行两行拒绝原因与一行汇总。

valid: sub=demo-user
expired correctly rejected: token expired
tampered correctly rejected: bad signature
PASS: valid accepted; expired and tampered rejected

来源

RFC 7519：JSON Web Token，令牌结构、头部与注册声明，已核验 2026-02-27。
RFC 8725：JWT 最佳实践，算法钉死、密钥混淆与寿命建议，已核验 2026-02-27。
OWASP JSON Web Token 速查表，无签名算法、密钥管理与验签清单，已核验 2026-02-27。

预备语句把取值与 SQL 结构分开

Sat, 16 Oct 2027 00:00:00 +0000

参数绑定为数据库中的取值提供一个明确位置。姓名里即使带有引号或分号，也仍然只是值，不会因此变成另一段查询条件。复用命名预备语句则是另一项优化：服务端能够在同一个会话内，跨多次执行保留语句信息。安全地绑定数据，并不要求应用为每一条查询都显式建立一个命名语句，也不要求先证明查询会频繁重复。

坏掉的样子

在 Psycopg 中，占位符 %s 属于驱动接口，不是让程序使用 Python 字符串格式化。值应作为 execute 的第二个参数传入，占位符不要加引号，只有一个位置参数时也需要单元素元组。如果先把值插入字符串，再调用一个支持参数化的接口，原本希望保护的边界早就已经被越过；接口名称本身不会替程序补救这次拼接。

占位符代表值，不代表表名、列名或关键字。动态标识符需要明确的结构选择：先用白名单限制支持的列，再用驱动的标识符组合功能正确引用选中的列名。升降序关键字也应由应用控制。分页的数量与偏移量可以直接绑定，同时仍须按产品要求验证范围。能在语法上接收一个整数，不代表允许请求任意大的页面或无限制消耗资源。

预备语句不会把第一次的执行计划永久钉死。PostgreSQL 区分根据本次参数生成的定制计划，以及跨不同参数复用的通用计划；自动选择时会考虑规划开销与估算执行成本。模式或统计信息变化也可能触发重新规划。因此，语句保持参数化时，访问路径仍可以变化。是否复用某种计划，与输入能否变成 SQL 语法，是不同的性质，不能混为一谈。

快速验证

准备安装了 Psycopg 3 的 Python 环境，把 PG_DSN 设置为可丢弃的 PostgreSQL 数据库连接。连接配置沿用已有安全提供方式。实测版本为 Psycopg 3.3.5 与 PostgreSQL 18.6。将下面代码保存为 Python 文件，在已设置该环境变量的终端执行。使用的是临时表，连接关闭后会自动消失：

import os
import psycopg
from psycopg import sql

with psycopg.connect(os.environ['PG_DSN'], autocommit=True,
 prepare_threshold=5) as conn:
 conn.execute('CREATE TEMP TABLE people (id integer PRIMARY KEY, label text NOT NULL)')
 conn.execute("INSERT INTO people VALUES (1,'alice'),(2,'bob')")
 query = 'SELECT id FROM people WHERE label=%s ORDER BY id LIMIT %s'
 hostile = "' OR true --"
 assert conn.execute(query, (hostile, 10), prepare=False).fetchall() == []
 count = conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone()[0]
 assert count == 0
 print('bound without named preparation:', count, 'named statements; no match')
 for value in ("O'Reilly", r'a\b', 'x; DROP TABLE people; --'):
 assert conn.execute('SELECT %s::text', (value,), prepare=False).fetchone() == (value,)
 for label, expected in (('alice', [(1,)]), ('bob', [(2,)])):
 assert conn.execute(query, (label, 10), prepare=True).fetchall() == expected
 assert conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone() == (1,)
 print('named preparation reused: alice=1, bob=2')

 def ordered(column, limit):
 if column not in {'id', 'label'}:
 raise ValueError('unsupported sort column')
 if type(limit) is not int or not 1 <= limit <= 100:
 raise ValueError('limit must be an integer from 1 through 100')
 statement = sql.SQL('SELECT id FROM people ORDER BY {} LIMIT %s').format(
 sql.Identifier(column))
 return conn.execute(statement, (limit,), prepare=False).fetchall()

 assert ordered('label', 1) == [(1,)]
 for column, limit in [('label; DROP TABLE people', 1), ('id', 0), ('id', 101)]:
 try:
 ordered(column, limit)
 except ValueError:
 pass
 else:
 raise AssertionError('invalid request accepted')
 print('identifier allow-list and bound LIMIT checked')

 conn.execute('PREPARE plan_lab(text) AS SELECT id FROM people WHERE label=$1')
 conn.execute('SET plan_cache_mode=force_custom_plan')
 assert conn.execute("EXECUTE plan_lab('alice')").fetchall() == [(1,)]
 counters = "SELECT generic_plans,custom_plans FROM pg_prepared_statements WHERE name='plan_lab'"
 assert conn.execute(counters).fetchone() == (0, 1)
 conn.execute('SET plan_cache_mode=force_generic_plan')
 assert conn.execute("EXECUTE plan_lab('bob')").fetchall() == [(2,)]
 assert conn.execute(counters).fetchone() == (1, 1)
 print('same prepared statement: custom=1, generic=1')
 conn.execute('RESET plan_cache_mode')
 conn.execute('DEALLOCATE plan_lab')

第一项输出显示命名语句数量为零，而且看起来像注入的输入没有匹配任何记录。这次调用明确关闭命名预备，却保留参数绑定，证明安全边界在语句复用之前就存在。随后包含引号、反斜杠、分号的文本都原样返回，表仍可被后面的查询继续使用，字符串里写着删除命令也没有获得执行机会。

接下来两次显式预备调用复用了同一个命名语句，分别返回爱丽丝的编号一和鲍勃的编号二。连接的阈值配置允许显式预备。在本次驱动版本里，如果把 prepare_threshold 设为 None，命名预备整体被禁用，连显式请求也不会创建它。这个设置不等于关闭绑定，不能根据看不到命名语句就断言查询不安全。

排序函数对受支持的列和绑定上限返回一条结果；对不支持的列，以及一至一百之外的页大小，在发送 SQL 前拒绝。标识符引用负责保持语法正确，白名单负责说明这个入口究竟支持哪些合法结构。这两项职责不能交给任意请求文本决定，尤其不能以为加好了引号，就应该允许所有真实存在的列被外部选择。

最后，同一条 SQL 预备语句分别在强制定制计划与强制通用计划下执行。计数从通用零次、定制一次变成两种各一次，两次也都返回正确行。强制设置只是让差异能够稳定观察，并未测量自动模式面对真实倾斜数据会选择什么，更不是建议把整个服务永久改成某一种强制模式。退出前恢复设置并释放命名语句。

在真实部署中观察复用

PostgreSQL 默认的自动策略先用定制计划执行带参数语句，之后再比较通用方案。是否适合复用，需要结合真实参数分布和执行计划判断。这个只有两行数据的实验没有测量延迟，也没有统计协议往返次数；驱动如何批量发送协议消息、连接建立成本与查询本身开销，都会影响最终测量，不能从“预备”二字推导一个固定网络代价。

命名语句属于服务端会话，连接池和事务级代理必须正确处理这段生命周期。部署环境需要明确支持相应的预备语句行为，或者在不支持时关闭命名复用。即使只执行一次查询，也应默认绑定数据。租户过滤、对象授权和结果大小限制仍须单独成立：一条完全参数化的 SQL，也可能因为缺少业务权限条件而返回调用者无权查看的信息。

来源

Psycopg 参数接口，绑定语法与标识符组合，已核验 2026-09-12。
Psycopg 预备语句，阈值、显式预备和会话生命周期，已核验 2026-09-12。
PostgreSQL 18 PREPARE，定制计划、通用计划和自动选择，已核验 2026-09-10。

Setuid 已属主身份运行

Sat, 02 Oct 2027 00:00:00 +0000

setuid 二进制以文件属主的身份运行，而不是以启动它的人的身份。内核在 exec 时刻替换凭据，passwd 因此能在普通用户并不拥有 /etc/shadow 写权限的情况下改写它。这个位属于文件，而它交出去的是属主的整个身份，不是某一项窄权限。

故意做这种交换是件奇怪的事：你等于把一整个账户托付给一个程序，于是程序里任何一处缺陷都会变成提权缺陷。何况这套机制会在好几种有据可查的情况下静默失效，而 capabilities、用户命名空间与 socket 激活，今天已经覆盖了 setuid 原本的大部分用途。真正值得问的，往往不是「怎么把这个程序写对」，而是「这件事能不能不要 setuid」。

身份跟着文件走

execve(2) 把规则写得很直白：若程序文件上设置了 set-user-ID 位，调用进程的有效用户 ID 就变为该文件属主的 ID。真实 UID 与真实 GID 保持不变，新的有效 UID 随后被复制进 saved set-user-ID。真实、有效、保存这三份凭据，就是这套机制的全部。

这些位在程序跑起来之前就能看到：stat 显示 /usr/bin/sudo 的模式是 4511（-r-s--x--x）、/usr/bin/su 是 4755，两者属主都是 uid 0，而 /usr/bin/passwd 只是普通的 0755。哪些二进制带这个位，是每台机器各自的部署事实，只能去读，不能假设。

该位失效的四种情况

execve(2) 列出了跳过身份切换的几种条件：调用线程设置了 no_new_privs、文件系统以 nosuid 挂载、或进程正在被 ptrace。对于 nosuid 挂载，手册明确警告行为随内核版本而变——有的内核直接以 EPERM 拒绝执行，有的内核干脆忽略这两个位照常运行。文件 capability 在上述同样条件下也会被一并忽略。

脚本是第四种，也是最出人意料的一种：「Linux（以及大多数其他现代 UNIX 系统）会忽略脚本上的 set-user-ID 与 set-group-ID 位。」于是一个 shell 脚本可以永远显示为 -rwsr-xr-x 却什么也提不了，因为 #! 把控制权交给了解释器，只有解释器自身的位才算数。想让脚本真正提权，只能去动解释器自己的位或它的文件 capability，而解释器通常恰恰是最不该带这些东西的程序。在这台 macOS 上，以属主身份执行 chmod 4755 返回 EPERM，而 chmod 1755 能成功设置 sticky 位。

降权并不对称

setuid(2) 这个系统调用不是文件上的那个位。持有 CAP_SETUID 的特权调用者会把真实、有效、保存三者一起改掉，所以一个 set-user-ID-root 程序调用 setuid(1000) 之后三者都是 1000——此时想再取回 root 会得到 EPERM，因为 0 既不再是真实 UID，也不再是 saved set-user-ID。手册的结论很直接：这样的程序只能用 seteuid(2)，不能用 setuid(2) 先降后升。

seteuid(2) 只移动有效 UID，且非特权调用者只能把有效 UID 指向真实 UID、当前有效 UID 或 saved set-user-ID。于是 saved UID 成了一条刻意留出的退路：同一个进程可以先 seteuid 降到 1000，之后再升回 0。永久降权要用 setuid(2)，可逆降权要用 seteuid(2)，差别就在 saved UID 上。

更窄的替代方案

capability 把一份身份拆成大约四十项具名权力。setcap cap_net_bind_service=+ep /usr/bin/webserver 让该二进制能绑定 80 端口，既没有 setuid 位，也读不了 /etc/shadow。capabilities(7) 指出，执行 set-user-ID-root 程序后，整个 capability 集合仍会被视为全部打开——这正是更窄的授权所要避开的那片爆炸半径。用户命名空间把 uid 0 映射成调用者自身，在命名空间之外毫无权力；socket 激活则让监听套接字归 PID 1 所有，服务本身以非特权身份运行。

坏掉的样子

最经典的一种是 setuid 脚本：有人把辅助程序改写成 shell 或 Python，模式位照旧留着，工具就悄悄丢掉了它需要的那点权限。列表里那个 s 还在，审计照样会把它标出来，可什么也没提升。要证明提权，只能在程序内部打印 id -u，绝不能看模式字符串。把 find / -perm -4000 的结果与实际会提权的程序对一遍，这类僵尸条目立刻现形。

更危险的一种是 setuid 二进制里的 shell 逃逸。C 库会清掉 LD_PRELOAD 这类变量，但应用层的输入仍然只能由你自己把关：没清理过的 PATH 会把 system("thumbnail ...") 指向攻击者的二进制，用户可控的配置路径则会把文件读取引向别处。由于整个进程都背着属主的身份，这样一处缺陷就是 root 漏洞，而不是小毛病。清单要短，并给每个二进制一个除此之外一无所有的属主。

快速验证

在要审计的机器上执行：

find / -xdev -perm -4000 -type f -printf '%m %u %p\n' 2>/dev/null
findmnt -no TARGET,OPTIONS / /home /tmp /var | grep -o nosuid
getcap -r /usr/bin /usr/sbin 2>/dev/null
grep -E 'NoNewPrivs|CapEff' /proc/self/status
stat -c '%A %a %U %n' /usr/bin/passwd

第一条命令应当只返回很短的一串；在一台干净的 Debian 上大约是十几条路径，其中每一条都该是你愿意把属主整个身份托付出去的程序。持有 setuid 二进制的文件系统上出现 nosuid，就解释了某份权限为什么凭空消失；而出现在 getcap 输出里的二进制，则早已从 setuid 迁移走了。

来源

man7：execve，exec 时的 set-user-ID 切换与四种跳过条件，已核验 2026-09-16。
man7：setuid，CAP_SETUID、saved set-user-ID，以及 seteuid 为何是可逆路径，已核验 2026-09-16。
man7：capabilities，以更窄的 capability 授权替代 setuid-root 二进制，已核验 2026-09-16。

临时目录是公用空间

Sun, 26 Sep 2027 00:00:00 +0000

/tmp 是名字的共享命名空间，不是私有的暂存区。任何本地用户都能创建你的进程即将使用的那个名字，所以名字并不构成对文件的占有；而 hier(7) 明确说，里面的内容可能在任何时候被删除，而且不会通知你。

粘滞位让这个目录可以安全地被共享，却没有让它能被可预测地使用。因此修法不是改权限，而是改系统调用的形状：用一次调用同时生成名字并创建文件，中间不留任何空隙给别人抢占。

1777 才让共享成为可能

模式 1777 是「人人可写」加上粘滞位，而在这台主机上这不是假设：/tmp 是指向 private/tmp 的符号链接，后者是 drwxrwxrwt。没有粘滞位，目录里任何能写的人都能删除或重命名别人的文件；有了它，只有文件属主、目录属主或 root 可以。正是这一个位，让 /tmp 能被许多互不信任的用户同时使用。

粘滞位做不到的事，是在文件存在之前保护那个名字。open("/tmp/svc.log", "w") 会跟随一个已经存在的符号链接，于是写入落在链接指向的地方，而不是一个新文件里。实验用真实的 open(2) 验证了这一点，随后验证了两次拒绝：O_CREAT|O_EXCL 因名字已被占用而返回 EEXIST，O_CREAT|O_NOFOLLOW 因最后一段是符号链接而返回 ELOOP。

不是你创建的文件，权限不属于你

同一个缺陷的另一半更隐蔽：既没有符号链接，也没有可见的竞争。O_CREAT 只在它真正创建文件时才应用模式参数，所以一个被预先创建、人人可读的文件，在你用模式 0600 打开它之后仍然保持 0666，你写进去的秘密也就一直人人可读。实验用真实的 stat(2) 复现了这一点。

修法是让一次调用同时完成命名与创建。mkstemp(3) 把契约写得很清楚：模板的最后六个字符是 XXXXXX，文件以权限 0600 创建，并以 O_EXCL 打开，从而保证创建者就是调用者。mktemp(1) 在 shell 里做同样的事，会遵循 TMPDIR，默认模板为 tmp.XXXXXXXXXX。它的 -u 只打印名字而不创建任何东西，手册直接把它标为 “(unsafe)"；实验确认那个被打印出来的名字之后仍然空闲，而这正是 mkstemp 要关掉的那扇窗。如果工作单元是目录而不是文件，mkdtemp(3) 应用同一条规则：以模式 0700 创建它，别人进不去。这一步同样是一次调用完成命名与创建，没有留给别人的窗口。

隔离，以及它的代价

TMPDIR 是最便宜的隔离手段：实验显示 tempfile.gettempdir() 会遵循它，而本机已经给每个用户一个私有的临时目录。systemd 的 PrivateTmp= 按 unit 做同样的事，为它建立一个文件系统命名空间，其中的 /tmp 与 /var/tmp 不与外部进程共享，服务停止时其中的文件也会被删除。同一份文档对代价也很诚实：它让进程之间通过 /tmp 或 /var/tmp 共享变得不可能，而且该实现可能不可用，所以 unit 不应只靠它来做安全。

tmpfs 上的 /tmp 会带来另一种无关的故障。tmpfs 默认是内存的一半，而这些页就是内存，所以一个失控的构建缓存塞满 /tmp 之后，下一个服务的 4 KiB mkstemp 会以 ENOSPC 失败，尽管它自己的数据目录是空的。失败的服务并不是塞满目录的那个，而停在 /tmp 里的每一个字节，都是机器其余部分拿不到的内存。

坏掉的样子

第一种故障是可预测的名字，它表现为一个其实是符号链接的文件，或者一个最终人人可读的秘密。排查是机械的：找出 /tmp 下的固定路径，以及 tmpnam/tempnam——它们在文件存在之前就返回名字。把它们换成 mkstemp/mkdtemp，或 tempfile.mkstemp(prefix=..., dir=...)；还要记住崩溃的进程会把文件留在身后，所以在 finally 里清理，而不是只在顺利路径上清理。

第二种故障是共享的 /tmp 波及无辜。因为 tmpfs 上的 /tmp 有一个与磁盘无关的容量上限，一个服务遗弃的临时文件，会让另一个服务的 mkstemp 在自身存储为空的情况下以 ENOSPC 失败。正是这个爆炸半径让它值得被当作服务级依赖来监控，而会产生大文件的写入方，应该放到真实路径或 $XDG_STATE_HOME 下面。

快速验证

stat -c '%A %a %n' /tmp
ls -ld "$TMPDIR"
python3 -c 'import tempfile,os;fd,p=tempfile.mkstemp(prefix="probe-");print(p,oct(os.stat(p).st_mode & 0o777));os.close(fd)'
mktemp; mktemp -u
grep -rn "tmpnam\|tempnam\|/tmp/[a-z]" --include='*.py' --include='*.c' --include='*.sh' . | head

stat 那行应该显示 drwxrwxrwt、模式 1777；少了粘滞位，就是一个任何用户都能删文件的共享目录。mkstemp 那行应该打印一个随机名字和 0o600，所以出现 0o644 或固定名字，就说明代码没用原子接口。mktemp 会创建文件，而 mktemp -u 只打印名字，所以在脚本里看到 -u，就是看到了竞争窗口。grep 用来审计固定的临时路径。

来源

mktemp(1)，默认模板、TMPDIR 处理，以及被手册标为不安全的 -u 空跑，已核验 2026-09-16。
mkstemp(3)，XXXXXX 模板、0600 创建模式，以及 O_EXCL 保证，已核验 2026-09-16。
hier(7)，/tmp 存放可能被随时删除且不通知的临时文件，已核验 2026-09-16。
systemd.exec(5)，PrivateTmp= 命名空间及它使共享变得不可能，已核验 2026-09-16。

框架策略明确谁可以嵌入当前页面

Thu, 23 Sep 2027 00:00:00 +0000

点击劫持利用用户对界面的误判，让一个动作落到并非其真实意图的控件上。恶意父页面可以把被嵌入的应用放在误导性视觉层后面，使用户点击实际进入该应用中的真实按钮。父页面不必能够读取子页面的文档结构，用户仍然可以与框架里的内容交互。因此，同源读取限制不能替代应用是否允许被嵌入的独立决定，也不能仅靠看不到对方文档就判断点击过程安全。

被嵌入的响应可以通过内容安全策略禁止任何祖先嵌入，或者明确列出允许的祖先来源。这里写的应当是获准包含当前文档的页面来源。假设商户页面嵌入支付页面，应由支付页面的策略允许商户来源；仅列出支付组件自己的来源，并不能表达商户有权嵌入它。配置之前先明确哪一份响应属于子页面、哪个来源是父页面，可以避免把允许列表方向写反。

把限制放到正确的响应上

嵌入祖先指令回答谁能嵌入当前文档，框架来源指令则回答当前文档自己可以加载哪些框架。给子页面设置严格的 frame-src，并不会阻止另一个父页面嵌入它。默认来源全部拒绝，也不会作为 frame-ancestors 的回退值。这些指令控制的是关系中的不同方向，不能仅因为名字都涉及框架，就把其中一个当成另一个的替代品。

嵌入祖先指令不能通过 CSP 的 meta 元素生效，必须通过响应头交付。遇到多层嵌套时，每一级祖先都需要符合策略，而不只是直接父级。某个组件即使可以合法放在指定应用中，当该应用本身又被放进未经许可的外层框架时，仍可能被阻止。因此制定允许列表时，要审阅整个预期嵌入链，不能只凭最内层组件和它紧邻的容器作判断。

坏掉的样子

一次部署可能只给容器页面增加了策略，却让真正敏感的子页面响应保持不受限制；另一次部署可能把策略写入 HTML 元数据，看到配置文字存在就误以为浏览器会执行。应检查实际被框架加载的响应，并验证浏览器是否渲染。仅收到二百状态，既不能证明嵌入成功，也不能证明没有框架防护，因为浏览器可以收到文档后，拒绝在当前祖先环境中显示它。

互相冲突的响应头也可能误导审阅者。在支持这套规则的现代浏览器里，强制执行的嵌入祖先策略优先于该响应的 X-Frame-Options。给允许某个父来源的策略再附加一个 DENY，并不必然得到期望中的更严格结果。如果确实需要保留多个响应头，应让它们与实际受众和浏览器支持约定一致，不能假定它们都像多份 CSP 那样自然取限制交集。

快速验证

将代码保存为 frame-policy.py，执行 python3 frame-policy.py –serve，并打开打印出的父页面地址。本次实际使用 Python 3.14.4 与 Chrome 152。父服务和子服务位于不同的本机回环端口，六份子响应只有合成说明文字，以及表示成功渲染的消息。父页面只接受预期子来源发来的消息并展示结果，结束后按控制键加 C 关闭两个临时服务，不会操作真实账号或业务控件。

import json
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.request import urlopen

paths = ["open", "csp-block", "xfo-block", "csp-allow", "meta", "frame-src"]
requests = []


class Child(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 name = self.path.lstrip("/")
 assert name in paths
 requests.append(name)
 meta = ('<meta http-equiv="Content-Security-Policy" content="frame-ancestors \'none\'">'
 if name == "meta" else "")
 body = ("<!doctype html><meta charset=utf-8>" + meta + "<p>Rendered: " + name + "</p>"
 "<script>parent.postMessage({frame:" + json.dumps(name) + "}," + json.dumps(app_origin) + ");</script>").encode()
 self.send_response(200)
 self.send_header("Content-Type", "text/html; charset=utf-8")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Cache-Control", "no-store")
 if name == "csp-block":
 self.send_header("Content-Security-Policy", "frame-ancestors 'none'")
 elif name == "xfo-block":
 self.send_header("X-Frame-Options", "DENY")
 elif name == "csp-allow":
 self.send_header("Content-Security-Policy", "frame-ancestors " + app_origin)
 self.send_header("X-Frame-Options", "DENY")
 elif name == "frame-src":
 self.send_header("Content-Security-Policy", "frame-src 'none'")
 self.end_headers()
 self.wfile.write(body)


class Parent(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 if self.path == "/events":
 body = json.dumps(requests).encode()
 kind = "application/json"
 else:
 body = ("""<!doctype html><meta charset="utf-8"><title>Frame policy lab</title>
<h1>Which child responses can this parent embed?</h1><pre id="result">Waiting for frame messages...</pre>
<button id="check">Show server requests</button><div id="frames"></div><script>
const child=""" + json.dumps(child_origin) + ";const names=" + json.dumps(paths) + """;
window.received=[];
window.snapshot=async()=>{
 const result={rendered:[...window.received].sort(),serverRequests:await (await fetch('/events')).json()};
 document.getElementById('result').textContent=JSON.stringify(result,null,2);return result;
};
addEventListener('message',event=>{
 if(event.origin===child && names.includes(event.data?.frame)) {
 window.received.push(event.data.frame);
 document.getElementById('result').textContent=JSON.stringify(window.received,null,2);
 }
});
document.getElementById('check').onclick=()=>window.snapshot();
for(const name of names) {
 const frame=document.createElement('iframe');frame.src=child+'/'+name;frame.title=name;
 frame.width=240;frame.height=100;document.getElementById('frames').append(frame);
}
</script>""").encode()
 kind = "text/html; charset=utf-8"
 self.send_response(200)
 self.send_header("Content-Type", kind)
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


child = HTTPServer(("127.0.0.1", 0), Child)
app = HTTPServer(("127.0.0.1", 0), Parent)
child_origin = f"http://127.0.0.1:{child.server_port}"
app_origin = f"http://127.0.0.1:{app.server_port}"
threads = [Thread(target=server.serve_forever, daemon=True) for server in (child, app)]
for thread in threads:
 thread.start()
try:
 for name in paths:
 with urlopen(child_origin + "/" + name, timeout=5) as response:
 assert response.status == 200
 if name == "csp-allow":
 assert response.headers["Content-Security-Policy"] == "frame-ancestors " + app_origin
 assert response.headers["X-Frame-Options"] == "DENY"
 response.read()
 requests.clear()
 print(json.dumps({"app_url": app_origin, "child_origin": child_origin,
 "wire_responses": 6}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 for server in (child, app):
 server.shutdown()
 server.server_close()
 for thread in threads:
 thread.join(timeout=5)

开放子页面应正常渲染；csp-block 被禁止祖先嵌入策略拒绝，xfo-block 被 DENY 拒绝。csp-allow 虽然同时发送 DENY，但强制祖先策略明确允许当前父来源，因此正常渲染。meta 页面也会渲染，因为该交付方式不能执行嵌入祖先指令；frame-src 页面同样渲染，因为它限制的是子页面接下来自己加载的框架，而不是正在验证的父子嵌入关系。

预期结果是四条成功渲染消息与六条服务端请求记录。点击页面中的查看服务端请求按钮，可以同时核对两者；浏览器检查还记录了两个被拒框架对应的响应阻止错误。单独运行 Python 探针时，六份响应都会返回二百状态，说明只读响应头不能替代渲染验证。本例只验证一个浏览器中的单层嵌入，没有验证真实账号操作或全部嵌套集成。发布前还应让合法路径与被拒父来源经过实际代理和内容分发层，确认目标子响应仍然保有预期策略。

来源

MDN CSP frame-ancestors，允许的嵌入父级、祖先检查及不支持的 meta 交付方式，已核验 2026-09-13。
MDN CSP frame-src，控制当前文档自己加载的框架，已核验 2026-09-13。
MDN X-Frame-Options，禁止嵌入与同源嵌入限制，已核验 2026-09-13。
W3C CSP Level 3，嵌入祖先策略的执行及其与 X-Frame-Options 的关系，已核验 2026-09-13。

XXE 展开实体的代价

Wed, 22 Sep 2027 00:00:00 +0000

XML 外部实体处理可能通过解析器去读本地文件、访问原本够不到的主机，而且这一切都是服务器解析时替你完成的。应当在解析器里把它禁掉。

实体是解析器的功能

XML 实体是解析器自带的一个功能,让文档可以引用别处的内容;也正是同一套机制,在得不到防护时把一条请求变成一次可无限扩展的实体炸弹。一份文档可以定义这样一个实体:它指向本机某个文件、某个网络地址,或另一个实体;解析器一旦去解析它,就会把文件内容读进来、塞进文档中「占位」的位置。便利与危险常常是双胞胎——允许多引用的解析器,自然也就允许去翻 /etc/passwd,或者把 URL 递到网络的另一端。

外部指针会泄文件

外部实体之所以会「泄」,是因为解析器替你去读了它。一次典型的 XXE 攻击,会发送一条指向文件路径或 URL 的实体声明;而一个过于宽松的解析器,就会把文件读出来、在响应里把其中一部分当作「占位符」的回显——于是一台内部文件或内网地址,就在攻击者只发送了一段 XML 帧的情况下被看见。伤害到底多大,取决于解析器允许访问什么;它的边界不是请求的体积,而是解析这段文档的进程权限。

干脆把这个功能关掉

最直接也最强的补救,是把这部分功能整个关掉:禁用外部普通实体与外部参数实体,决定解析器「是否允许翻网络」,并避开那些默认就去解析的外部解析库。在确实绕不开实体时,用 schema 对文档设一道闸,再用恰好够用的最小权限去跑解析。把 XXE 当做一个可开关的配置特性,而不是某段代码里的漏洞,才能让那些要处理历史数据的低层系统依旧安全——会决定「啃不啃得动一台机器」的,从来不是这份 XML 有没有内容,而是解析器有没有钥匙。

坏掉的样子

最典型的坏法是读文件：文档里声明一个指向本地路径的外部实体，应用又把展开后的内容回显到报错信息或预览字段里。请求本身只有几行，真正读磁盘的是解析器进程，所以访问日志看起来人畜无害，泄露只出现在响应正文。能读到什么不取决于攻击者，而取决于跑解析器的账号权限，服务账号能看到的秘密都可能变成远程可读。

同样的形状把网址放进系统标识符，就会变成服务端请求伪造。攻击者让解析器去访问云厂商的元数据地址拿凭证，或者去敲只有内网才能到达的管理后台。每次重试都是服务器替攻击者再跑一次，所以外部实体会放大伪造请求的伤害：一行很短的字符串，就能换来一次带内网身份的抓取。

还有一种不需要网络的坏法，叫实体炸弹。几个互相嵌套的内部实体，每层膨胀约十倍，一千字节的文档就能展开成几吉字节的文本，模式校验还没跑起来，内存就先被耗尽。容易被忽略的是图片上传：浏览器把可缩放矢量图形当作标记语言解析，于是头像通道里夹带文档类型声明，就把同一套机制从图片管线带了进来。防御常见的裂缝是不一致，主接口关掉了文档类型，订阅源、安全断言或随后重新解析文件的缩略图程序却还开着，攻击者总能找到那扇没关的门。

快速验证

把下面的程序保存到临时工作目录的xxe_probe.py，运行python3 xxe_probe.py。它只用标准库，不访问网络也不读写磁盘，对比宽松基线与加固入口的差别。基线会把内部实体炸弹展开到一千个字符，加固入口则拒绝一切声明了实体的文档类型。

"""XXE guard demo: stdlib only, no network, no disk reads."""
import io
import re
import xml.sax
import xml.sax.handler

BENIGN = '<?xml version="1.0"?><note><to>ops</to><body>hello</body></note>'
FILE_READ = ('<?xml version="1.0"?><!DOCTYPE r [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>'
 '<r>&xxe;</r>')
SSRF = ('<?xml version="1.0"?><!DOCTYPE r [<!ENTITY xxe SYSTEM '
 '"http://169.254.169.254/latest/meta-data/">]><r>&xxe;</r>')
BILLION_LAUGHS = ('<?xml version="1.0"?><!DOCTYPE l [<!ENTITY a "0123456789">'
 '<!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;">'
 '<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;">]>'
 '<l>&c;</l>')
SVG_UPLOAD = ('<?xml version="1.0"?><!DOCTYPE svg [<!ENTITY xxe SYSTEM "file:///etc/hostname">]>'
 '<svg xmlns="http://www.w3.org/2000/svg"><text>&xxe;</text></svg>')


class _Text(xml.sax.handler.ContentHandler):
 def __init__(self):
 self.chunks = []

 def characters(self, content):
 self.chunks.append(content)


class _RejectResolver(xml.sax.handler.EntityResolver):
 def resolveEntity(self, publicId, systemId):
 raise xml.sax.SAXException(f"blocked external entity: {systemId!r}")


def naive_parse(xml_text):
 """Permissive baseline: plain stdlib parse with no guard."""
 parser = xml.sax.make_parser()
 handler = _Text()
 parser.setContentHandler(handler)
 parser.parse(io.StringIO(xml_text))
 return "".join(handler.chunks)


def safe_parse(xml_text):
 """Hardened entry point: refuse entity machinery, then lock the parser."""
 if re.search(r"<!DOCTYPE|<!ENTITY", xml_text, re.IGNORECASE):
 raise ValueError("rejected: DOCTYPE/entity declarations are not accepted")
 parser = xml.sax.make_parser()
 parser.setFeature(xml.sax.handler.feature_external_ges, False)
 try:
 parser.setFeature(xml.sax.handler.feature_external_pes, False)
 except xml.sax.SAXNotSupportedException:
 pass # expat never fetches parameter entities; keep going
 parser.setEntityResolver(_RejectResolver())
 handler = _Text()
 parser.setContentHandler(handler)
 parser.parse(io.StringIO(xml_text))
 return "".join(handler.chunks)


def check_rejected(name, payload):
 try:
 safe_parse(payload)
 except ValueError as exc:
 print(f"blocked {name}: {exc}")
 return
 raise AssertionError(f"safe_parse accepted {name}; expected ValueError")


def main():
 text = safe_parse(BENIGN)
 assert "hello" in text, f"benign parse lost content: {text!r}"
 print(f"benign ok: {text.strip()!r}")
 expanded = naive_parse(BILLION_LAUGHS)
 assert len(expanded) >= 1000, f"baseline did not expand: {len(expanded)} chars"
 print(f"baseline expands billion-laughs to {len(expanded)} chars (unsafe)")
 for name, payload in [("file-read", FILE_READ), ("ssrf", SSRF),
 ("billion-laughs", BILLION_LAUGHS),
 ("svg-upload", SVG_UPLOAD)]:
 check_rejected(name, payload)
 print("PASS: 1 benign accepted, 1 baseline expansion shown, 4 malicious inputs rejected")


if __name__ == "__main__":
 main()

运行成功会先打印正常文档的文本，再报告基线展开的长度并标记为不安全，随后列出文件读取、服务端伪造、实体炸弹和图形上传四种输入被拦截，最后以通过行收尾。加固函数在解析前拒绝任何文档类型或实体声明，再关闭外部普通实体与外部参数实体，并装上遇到残留引用就抛异常的解析器。这些断言已在苹果电脑的 Python 3.14 上运行通过。演示只覆盖解析器配置，生产环境还要配合白名单、模式校验，以及在文件落盘前就拒绝文档类型的上传管线。

来源

OWASP：XXE，漏洞说明，已核验 2027-10-16。
OWASP：XXE 防护速查表，如何禁用外部实体，已核验 2027-10-16。
CWE-611：XXE，弱点定义与缓解措施，已核验 2027-10-16。
W3C：XML 1.0，实体与文档类型定义规范，已核验 2027-10-16。

客户端证书证明的是设备，不只是口令

Mon, 06 Sep 2027 00:00:00 +0000

双向 TLS 在验证服务器身份的同时，也认证客户端是否能够使用证书对应的私钥。但它并不天然证明某台物理设备的身份。可复制的软件私钥可以被带到别处使用；硬件绑定和设备证明需要额外机制。因此，标题中的设备身份应理解为注册和签发策略所赋予的身份，而不是 TLS 自动确认的硬件事实。

完成认证仍然需要授权

TLS 1.3 的证书式客户端认证中，服务器请求证书，客户端通过 CertificateVerify 证明自己能够使用对应私钥。只发送一份公开证书文件并不够。双方都必须应用各自的信任规则，检查证书链和适当用途；客户端还要验证服务器名称，不能因为自己提交了凭据就放弃验证对端。

服务端信任哪些客户端 CA，与客户端信任哪些服务器 CA，是两个方向的决定。应只接受预期签发者，并明确使用哪个已验证证书字段表示工作负载身份。URI SAN 可以存放应用标识，但谁有资格拿到这个标识，取决于签发者的注册规则。证书里出现了名字，不代表它自动拥有所有 API 权限。

“要求必须提供证书”也不同于“请求对方有的话就提供”。Go 的 RequireAndVerifyClientCert 要求有效客户端证书，而可选模式可能允许没有证书的连接通过。认证之后仍需根据已验证身份执行授权，因此合法访客可以得到 HTTP 403，而获准读取的客户端得到 HTTP 200，这两个结果不矛盾。

坏掉的样子

没有证书、签发者不受信任、凭据过期或扩展用途不合适，都可能阻止客户端认证。把服务端改为任意证书都接受，或者关闭客户端对服务器的验证，只是隐藏边界，不是在修复凭据问题。应区分握手失败和应用层拒绝，让排查人员能定位到实际负责的那一层。

私钥需要受控存储、签发、轮换和事件响应。续签证书并不必然更换私钥；被盗且仍被接受的私钥可能用于冒充，不能把等待过期当作唯一处置方式。Go 的证书 Verify 不执行吊销检查，因此发布了一条吊销记录，也不等于每个调用方已经应用它，接受策略必须另行核实。

TLS 终止位置还决定了身份在哪里被建立。后端收到调用方自行填写的身份 Header，不代表后端就验证了调用方证书。受信任的身份传递需要自己的认证边界和防伪造规则；凭据或权限变化时，既有连接、恢复会话如何处理，也必须有明确的生命周期策略。

快速验证

保存为 mtls_probe.go，使用 Go 1.23 或更新版本运行 go run mtls_probe.go。程序在内存中生成客户端 CA 和凭据，把 notBefore 回拨一分钟，并把 notAfter 设为生成时刻之后一小时。回环服务端使用 httptest 自带的测试服务器证书，配套测试客户端信任这张证书。两侧信任库都不安装到系统全局，也不打印或写出私钥。

package main

import (
 "crypto/ed25519"
 "crypto/rand"
 "crypto/tls"
 "crypto/x509"
 "crypto/x509/pkix"
 "errors"
 "fmt"
 "io"
 "log"
 "math/big"
 "net/http"
 "net/http/httptest"
 "net/url"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func authority(serial int64) (*x509.Certificate, ed25519.PrivateKey) {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), Subject: pkix.Name{CommonName: fmt.Sprint("fixture-ca-", serial)},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 IsCA: true, BasicConstraintsValid: true, KeyUsage: x509.KeyUsageCertSign,
 }
 der, err := x509.CreateCertificate(rand.Reader, template, template, public, private)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return certificate, private
}

func credential(serial int64, identity string, usage x509.ExtKeyUsage, ca *x509.Certificate, signer ed25519.PrivateKey) tls.Certificate {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 name, err := url.Parse("urn:example:" + identity)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), URIs: []*url.URL{name},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{usage},
 }
 der, err := x509.CreateCertificate(rand.Reader, template, ca, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return tls.Certificate{Certificate: [][]byte{der}, PrivateKey: private, Leaf: certificate}
}

func main() {
 ca, signer := authority(1)
 foreignCA, foreignSigner := authority(2)
 reader := credential(3, "reader", x509.ExtKeyUsageClientAuth, ca, signer)
 guest := credential(4, "guest", x509.ExtKeyUsageClientAuth, ca, signer)
 foreign := credential(5, "reader", x509.ExtKeyUsageClientAuth, foreignCA, foreignSigner)
 serverOnly := credential(6, "reader", x509.ExtKeyUsageServerAuth, ca, signer)
 roots := x509.NewCertPool()
 roots.AddCert(ca)
 options := x509.VerifyOptions{Roots: roots, KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth}}
 _, err := foreign.Leaf.Verify(options)
 var unknown x509.UnknownAuthorityError
 check(errors.As(err, &unknown), "foreign issuer fixture must fail trust")
 _, err = serverOnly.Leaf.Verify(options)
 var invalid x509.CertificateInvalidError
 check(errors.As(err, &invalid) && invalid.Reason == x509.IncompatibleUsage, "server-only fixture must fail client usage")

 var handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 check(len(r.TLS.VerifiedChains) > 0, "handler requires a verified client chain")
 identities := r.TLS.VerifiedChains[0][0].URIs
 if len(identities) != 1 || identities[0].String() != "urn:example:reader" {
 http.Error(w, "forbidden", http.StatusForbidden)
 return
 }
 fmt.Fprintln(w, "reader allowed")
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{
 MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13,
 ClientAuth: tls.RequireAndVerifyClientCert, ClientCAs: roots, SessionTicketsDisabled: true,
 }
 server.StartTLS()
 defer server.Close()
 request := func(certificate *tls.Certificate) (int, error) {
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "server identity verification must remain enabled")
 config.MinVersion = tls.VersionTLS13
 if certificate != nil {
 config.GetClientCertificate = func(*tls.CertificateRequestInfo) (*tls.Certificate, error) {
 return certificate, nil
 }
 }
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request.Header.Set("X-Client-ID", "urn:example:reader")
 response, err := client.Do(request)
 if err != nil {
 return 0, err
 }
 defer response.Body.Close()
 _, err = io.Copy(io.Discard, response.Body)
 must(err)
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "client requires a verified TLS 1.3 server")
 return response.StatusCode, nil
 }
 for _, test := range []struct {
 name string
 certificate *tls.Certificate
 status int
 }{
 {"reader", &reader, 200}, {"guest", &guest, 403},
 {"missing", nil, 0}, {"foreign issuer", &foreign, 0},
 {"wrong usage", &serverOnly, 0}, {"reader again", &reader, 200},
 } {
 status, err := request(test.certificate)
 if test.status == 0 {
 check(err != nil && status == 0, "invalid client must fail before HTTP")
 } else {
 must(err)
 check(status == test.status, "wrong authorization result")
 }
 fmt.Println(test.name, "HTTP status:", status)
 }
 check(handled.Load() == 3, "only reader, guest, and reader again may reach HTTP")
 fmt.Println("three TLS rejections; authenticated guest denied despite claimed reader header")
 fmt.Println(runtime.Version())
}

reader 返回 200；同一个可信 CA 签发的 guest 返回 403，即使它在 X-Client-ID 中声称自己是 reader。授权使用已验证证书中的精确 URI SAN，不使用这个 Header。本例的 URN 只是应用身份标签，不是网络地址，固定规则只允许 urn:example:reader。

缺少凭据、外部 CA 签发的证书、仅允许服务端认证用途的证书，都在进入 HTTP 之前失败。此时打印的零只是“没有 HTTP 响应”的内部标记，不是一个真实 HTTP 状态码。独立的 X.509 检查还确认了两种非法证书分别触发 UnknownAuthorityError 和 IncompatibleUsage。最后再次请求 reader 应恢复成功，总共只有三次请求进入 handler。

证书回调刻意返回每次指定的凭据，包括外部 CA 的证书，而不是根据服务器公布的 CA 偏好默默选成“没有证书”。这样才能覆盖服务端拒绝不可信证书的路径；生产中的证书选择仍应遵守证书请求。本例每次都使用新的 transport，设置两秒超时，并关闭 HTTP 连接复用与会话票据。

已核验的 macOS、Go 1.27.0 运行通过全部断言。这验证了真实双向 TLS 和一条明确的应用授权规则，不是硬件身份或生产 PKI 的验收。实验没有测试吊销分发、自动续期、过期客户端在握手中的行为、恢复会话、反向代理身份传递，或既有连接上的权限变化。这些事项仍需在实际部署边界单独检查。

来源

RFC 8446：TLS 1.3，证书请求与私钥控制能力证明，已核验 2026-09-09。
Go crypto/tls，客户端认证模式、信任池和证书选择，已核验 2026-09-09。
Go crypto/x509，客户端认证用途、验证链与吊销检查边界，已核验 2026-09-09。
Go net/http/httptest，隔离 TLS 服务和可信测试客户端，已核验 2026-09-09。

SSRF 让服务器替你去开门

Sun, 05 Sep 2027 00:00:00 +0000

任何「从用户那里拿一个 URL、再由服务端去抓」的功能，都是在用服务器的身份、网络位置与凭据去跑这次抓取。缩略图生成、Webhook 测试、数据导入、PDF 渲染——只要目标来自请求，攻击者就不再是「自己去访问你的内网」，而是让你的服务器替他访问。

它比大多数注入类漏洞更值得优先处理，原因在可达性。服务器坐在边界之内：它能打开回环上的管理面板、能连 RFC 1918 网段里的服务、也能碰到云厂商提供实例凭据的那个 link-local 地址。攻击者与这张内网之间唯一的阻隔，就是那段决定「哪些 URL 可接受」的代码——而那段代码通常是一次字符串比较。

这次抓取带着服务器的权限

最经典的目标是实例元数据服务。在 AWS 上它监听 169.254.169.254，而 GET /latest/meta-data/iam/security-credentials/ 会返回实例所挂 IAM 角色的名字，紧接着就是该角色的临时凭据。实例的每一次 AWS API 调用用的都是这份凭据，所以一次打到元数据端点的 SSRF 不只是读到一个配置文件——它交出的是这台实例的云身份。OWASP 对内部 REST 接口、以及对那些「本来就只打算在内网可达」因而根本不带认证的 HTTP 数据库接口，记录的是同一种形态。

实验把两半都测了。对着一个本地替身，它用 127.0.0.1 的十六进制写法去打一个只检查 URL 字符串的校验，结果是 ALLOWED，抓取返回了一份凭据文档。接着它测加固：一台只开 v2 的实例对裸 GET 回 401，只有当请求带上 X-aws-ec2-metadata-token 时才放出元数据，而这个值攻击者必须先用 PUT /latest/api/token 拿到。一次只读一个 URL 的单发 SSRF 走不完这套握手。

URL 不是地址

字符串校验之所以失效，是因为那个字符串并不是客户端真正要连的地址。同一个回环地址有无数种写法：http://2130706433/ 是十进制，http://0x7f000001/ 是十六进制，http://127.1/ 是缩写形式，http://[::1]/ 覆盖 IPv6 那一侧。实验把它们逐一交给 getaddrinfo，拿回来的都是 127.0.0.1；而一个找 127.0.0.1 的子串检查，把这些全部放行。

@ 更糟，因为它能让白名单通过。在 http://trusted.example@169.254.169.254/ 里，userinfo 段是 trusted.example，主机是 169.254.169.254。RFC 3986 把这两者分开，但一个「抓到协议之后的所有内容、再看里面有没有白名单名字」的正则，看到那个名字就批准了。实验里的正则白名单对这一条 URL 报的就是 ALLOWED，而 urlsplit 报出的是真实主机。重定向与 DNS rebinding 是同一个想法放在时间轴上：地址校验过了，然后在连接建立之前，有东西变了。

解析之后再校验，然后把连接钉死

顺序比清单更重要。用真正的解析器解析 URL，对协议、主机与端口做白名单，解析主机名，再对拿回来的每一个地址做分类——拒绝回环、私有、link-local、保留与多播网段。然后去连你校验过的那个地址，而不是再解析一次，否则一个 rebinding 的域名可以给校验返回公网地址、给 socket 返回内网地址。实验里那个「先解析再分类」的函数拒绝了全部七条探测 URL，包括字符串校验放行的那几条。

重定向需要在每一跳上做同样的事：要么禁止跟随，要么在客户端请求每个 Location 之前重跑一遍守卫。IMDSv2 是第二层，它让裸 GET 失去意义；一条阻止工作负载访问 169.254.169.254 的网络策略是第三层。三者互不替代：白名单决定意图，地址分类决定可达性，出网规则决定可能性。

坏掉的样子

第一种失败是信任字符串的抓取器。它的表现是「你以为会被拒绝，却回了 200」，或者回了一段既不像你的应用、也不像正常错误的响应体：一份凭据文档、一个内网管理页、某数据库的 REST 回复。实验里，朴素的校验对十六进制回环 URL 报 ALLOWED，抓取就返回了那份凭据 JSON——整场攻击只有两行：没有漏洞利用载荷，只有一个被守卫误读的 URL。

第二种失败是只校验一次的守卫。白名单主机上的一次重定向，或者一个在校验与连接之间改变了答案的域名，都能从单次预检旁边走过去。实验跟随那个重定向跳，拿回了元数据响应体；而一个对每一跳重新校验的客户端会拒绝它。爆炸半径最大的情形，是目标为某个内网控制面——它之所以不带认证，恰恰因为它相信只有 localhost 能碰到它。

快速验证

拿字符串校验会漏掉的几种形状去探你自己的抓取器：

curl -s -o /dev/null -w 'allowlisted -> %{http_code}\n' 'https://app.example.com/api/fetch?url=https://cdn.example.com/logo.png'
curl -s -o /dev/null -w 'imds -> %{http_code}\n' 'https://app.example.com/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
curl -s -o /dev/null -w 'decimal -> %{http_code}\n' 'https://app.example.com/api/fetch?url=http://2130706433:8080/admin'
curl -s -o /dev/null -w 'userinfo -> %{http_code}\n' 'https://app.example.com/api/fetch?url=http://trusted.example@169.254.169.254/'

第一条必须成功，因为一个什么都拦的守卫不是守卫，是一次故障。另外三条必须回 4xx，并且不带来自目标的响应体；任何一条回 200，都说明这个抓取器是照着 URL 字符串做决定的。若 200 的响应体里带着凭据文档、内网页面或被回显的连接错误，那就是确认的 SSRF，不是误报。

来源

OWASP：服务端请求伪造，攻击者能触及什么、以及元数据端点为何关键，已核验 2026-09-16。
OWASP：服务端请求伪造防护速查表，白名单、先解析再连接与重定向处理，已核验 2026-09-16。
AWS：使用实例元数据服务，IMDSv2 的令牌握手与仅 v2 选项，已核验 2026-09-16。
RFC 3986：URI 通用语法，authority、userinfo 与 host 各部分，已核验 2026-09-16。

CSRF 检查请求到底来自哪里

Sat, 04 Sep 2027 00:00:00 +0000

浏览器在为任何页面发起的请求都会带上 Cookie。反 CSRF 令牌与 SameSite Cookie 能把每个状态变更与用户真正见过的那个页面绑定起来。

浏览器判别是否带上 Cookie,依据的是目标域名与路径,而不是「这次请求是由用户先前的什么意图触发的」。于是,来自攻击者网站的页面,也能驱动受害者的浏览器发出一条改变状态的请求——改密、改资料——并且这条请求会带上已登录的会话 Cookie。服务器看到这样一条请求,会以为它来自合法用户。这正是关键:请求带了凭据,并不能证明这是用户的本意;浏览器只是在执行它的 Cookie 规则,而不是用户的意志。

令牌把动作与来源绑定

对策是让「改变状态的动作」带一个攻击者无法预料的参数。服务端为每个会话生成一个反 CSRF 令牌,在它自己的表单里带上,提交时再比对;攻击者的跨站页面既没有这个令牌,校验就会失败。配合严格的方法约束——不要让 GET 去改变状态——让「带令牌」成为改变状态的唯一途径。比对必须严格:缺失或不匹配就拒绝,而且绝不接受攻击者自带的 origin。

SameSite 是浏览器护栏

给 Cookie 加上 SameSite=Lax/Strict,浏览器就不会在跨站请求里带上它,于是攻击者触发的请求从一开始就少了一样东西。但它不是单独就够的保险:旧浏览器、某些上下文仍然会忽略这一属性,所以它要和反令牌叠加,而不是替代。更稳的姿态是两层并用:用 SameSite 让 Cookie 别成为攻击者的默认送信工具,再用双提交令牌,让即使一条带着 Cookie 的请求,也仍缺一个只有目标页面才有的秘密。

把 Origin 当作意图信号

对于改变状态的请求,服务端要先问浏览器这次请求从哪里开始。浏览器在跨站的表单提交与数据接口里带上来源头,顶层导航则回退到引用头;跨站页面的脚本写不了这两个头,因为它们属于浏览器禁止改写的字段。服务端只接受与本站完全一致的来源,包括协议主机与端口,改变状态的提交一旦缺失该信号就直接拒绝,而不是当作默认通过。现代浏览器的取元站点标记提供同一判断,跨站标记就是可疑起点。来源证据只能证明浏览器的说法,命令行工具随手就能伪造任意首部,所以仍要叠加会话令牌。与 Cookie 篇的分工正在这里:那篇讲存储与传输属性,这篇讲每次变更都要验证意图。

坏掉的样子

第一种是把状态变更放在获取方法后面。图片与链接就能触发,宽松的站点隔离仍会在顶层获取导航里带上会话,伪造的跳转带着真实凭据到达,服务端却误以为是用户本意。排查时只看是否登录成功没有意义,还要看这条改变状态的请求能不能被一行标签触发。

第二种是回退到显式跨站放行。旧浏览器直接忽略该属性,跨站照样带上会话;显式写成放行又没有加密限定,等同于把运送通道重新打开,令牌一旦缺席立刻被利用。更隐蔽的是开发环境为了联调用了放行,上线忘记改回,测试时一切正常,攻击者却多了一条现成的通道。

第三种是令牌只验有无、不验对错。处理器仅在参数存在时比对,接口路径干脆跳过校验,或者把令牌放在查询串里,经引用头与日志到处扩散,攻击者拿到就能重放。还有把令牌存在可被子路径脚本读取的位置,跨站脚本先读后用,双校验就只剩一层。正确做法是缺失与不匹配一律拒绝,且只接受请求体或专用首部里的值。

第四种是子域信任过大。站点隔离比的是站点而非来源,受控的子域与主站同站,能覆盖会话标识,也能种下已知令牌。登录接口若不做同样的双校验,还会留下登录伪造,攻击者用自己的账号让受害者登录,后续操作全部记在攻击者账下。每种失败里凭据都是有效的,缺的从来都是意图证明。

快速验证

把下面程序存为 csrf_probe.py,运行 python3 csrf_probe.py。它只用标准库模拟服务端关卡:方法必须是大写提交,令牌必须与会话值一致,来源信号必须吻合。不起网络服务,不碰浏览器,任何机器跑出的五组结果都一样,适合放在提交前快速执行。

from hmac import compare_digest
from urllib.parse import urlsplit
import sys

EXPECTED_ORIGIN = "https://bank.example"
SESSION_TOKEN = "token-issued-with-own-form"

def decide(method, origin, referer, token):
 """模拟服务端关卡：安全方法、令牌与来源信号必须同时通过。"""
 if method != "POST":
 return 405, "state change requires POST"
 if not compare_digest(token or "", SESSION_TOKEN):
 return 403, "missing or wrong token"
 if origin:
 if origin != EXPECTED_ORIGIN:
 return 403, "origin mismatch"
 elif referer:
 base = urlsplit(EXPECTED_ORIGIN)
 seen = urlsplit(referer)
 if seen.scheme != base.scheme or seen.netloc != base.netloc:
 return 403, "referer mismatch"
 else:
 return 403, "no origin signal"
 return 200, "transfer accepted"

def check(actual, expected, label):
 assert actual == expected, f"{label}: got {actual}, want {expected}"
 print(f"{label}: {actual[0]} {actual[1]}")

check(decide("POST", EXPECTED_ORIGIN, "", SESSION_TOKEN),
 (200, "transfer accepted"), "legitimate form post")
check(decide("POST", "https://evil.example", "", SESSION_TOKEN),
 (403, "origin mismatch"), "forged cross-site post")
check(decide("POST", EXPECTED_ORIGIN, "", ""),
 (403, "missing or wrong token"), "missing token")
check(decide("POST", "", "https://bank.example/transfer", SESSION_TOKEN),
 (200, "transfer accepted"), "referer fallback navigation")
check(decide("GET", EXPECTED_ORIGIN, "", SESSION_TOKEN),
 (405, "state change requires POST"), "state change over GET")

print("PASS: legitimate, forged, and missing-token cases behave differently")
print(sys.version)

合法的同源提交带对令牌返回成功,伪造来源即使令牌正确也返回禁止,缺失令牌即使来源正确同样拒绝。回退到引用头的同站导航正常放行,获取方法改状态返回方法不允许,正好说明安全方法为何重要。预期输出以成功标记结尾并打印解释器版本,五组断言全部通过才算成功,任一组失败都会直接抛出异常中断。

这个夹具只验决策逻辑,不验浏览器是否真的按站点隔离丢弃凭据,也不验传输加密与会话过期。上线前要在真实浏览器里打开开发者工具,对改密转账这类接口再测一次跨站与同站行为,确认请求头与响应状态符合预期,才能把关卡当作完成。

来源

MDN：跨站请求伪造（CSRF），攻击形态、令牌与 SameSite 防御，已核验 2027-08-15。
OWASP：跨站请求伪造防护速查表，关于令牌与 SameSite 的指引，已核验 2027-08-15。
RFC 6265：HTTP 状态管理机制，SameSite 处理所依赖的 Cookie 语义，已核验 2027-08-15。

Kubernetes Secret 需要明确的访问边界

Sat, 21 Aug 2027 00:00:00 +0000

Kubernetes Secret 是用于保存工作负载所需机密值的 API 对象，提供专门的类型、消费路径和访问控制目标。但它不会让所有其他参与者都无法读取内容。设计边界时，需要同时考虑谁能取回对象、谁能创建消费者、谁能查看消费者输出，以及谁能管理运行它们的节点。仅区分配置对象与秘密对象，还不足以完成权限设计。

编码与保护处于不同层次

在 JSON API 表示中，Secret 的 data 使用 base64；stringData 则便于在写入时提交字符串。Base64 无需密钥就能还原，并不是加密。这种表示也不能证明某个具体集群怎样保护底层存储。Kubernetes 文档说明，若未配置相应加密，秘密数据默认不在存储层加密。应核对实际 API 服务器和存储设置，不能看到编码文字就推断保密措施已经生效。

存储加密同样不会阻止获得授权的 API 读取者拿到数据。RBAC 中的 get、list 和 watch 权限都可能暴露 Secret 内容，广泛的列表权限并不只是允许查看对象名称。备份和诊断输出也需要保护。正常应用最终仍要获得可用值，因此，一旦有权消费数据的程序被控制，攻击者就已经进入这份数据的信任边界，不能靠编码再次隔离它。

Secret 适合小规模值，单对象有一 MiB 限制。应只挂载需要的键，并只交付给真正需要它的容器。文件模式可以缩小工作负载内部的读取范围，却不能替代 API 授权或对创建工作负载权限的控制。环境变量注入也有暴露范围和生命周期方面的取舍，应根据应用需求选择，不能默认它一定比文件更安全。

坏掉的样子

禁止直接 get Secret，不一定禁止间接取得内容。主体如果可以在命名空间创建 Pod，通常就能在自己提交的规范中指定一个 Secret 卷，由 kubelet 把数据交给该工作负载。创建相应控制器的权限也可能产生类似效果。因此，除了直接读取数据的规则，还必须一起审查创建工作负载的权限及适用的准入限制，否则边界会漏掉实际消费路径。

把全部键挂进去，会扩大进程能够读取的内容集合。通过 volume items 只选一个键，可以限制这一次投射，但有更大创建权限的主体仍可能提交另一份投射定义。不能把一份范围较小的清单，误当成编写清单的人本身也受到同等范围限制。预期消费者是谁，以及谁能定义消费者，是需要分别处理的两个权限问题。

轮换也不只是修改 API 对象。数据交付、应用重新加载、凭据签发和旧值撤销都有各自时序。环境快照与 subPath 挂载不会像普通投射那样自动刷新；文件更新也不会强迫应用丢弃已经缓存的旧值。只有把签发系统与消费者一起验证，才能判断旧凭据是否确实不再被接受，不能仅以对象更新时间作为轮换完成证据。

快速验证

准备可丢弃的 Kubernetes 集群，并使用有测试 impersonation 权限的管理员连接，确保节点已有 python:3.11-slim-bookworm 镜像。保存为 secret-access.py，执行 python3 secret-access.py KUBECONFIG_PATH CONTEXT，明确指定专用配置和上下文。实测版本为 Kubernetes 1.34.11。这里全部数值都是明确的合成示例，输出只报告检查结果，不打印存储内容。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

import base64
namespace = 'notes-secrets-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 demo = 'DEMO_ONLY_NOT_A_CREDENTIAL'
 k('create', '-n', namespace, '-f', '-', payload={'apiVersion': 'v1', 'kind': 'Secret', 'metadata': {'name': 'example'},
 'type': 'Opaque', 'stringData': {'needed': demo, 'unused': 'UNUSED_DEMO'}})
 stored = obj(namespace, 'secret', 'example')
 assert base64.b64decode(stored['data']['needed']).decode() == demo
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ServiceAccount', 'metadata': {'name': 'creator'},
 'automountServiceAccountToken': False})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'Role',
 'metadata': {'name': 'pod-creator'},
 'rules': [{'apiGroups': [''], 'resources': ['pods'], 'verbs': ['create', 'get']},
 {'apiGroups': [''], 'resources': ['pods/log'], 'verbs': ['get']}]})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'RoleBinding',
 'metadata': {'name': 'pod-creator'},
 'subjects': [{'kind': 'ServiceAccount', 'name': 'creator', 'namespace': namespace}],
 'roleRef': {'apiGroup': 'rbac.authorization.k8s.io', 'kind': 'Role', 'name': 'pod-creator'}})
 identity = 'system:serviceaccount:' + namespace + ':creator'
 denied = k('--as', identity, 'get', 'secret', 'example', '-n', namespace, expected=None)
 assert denied.returncode != 0 and 'Forbidden' in denied.stderr
 probe = "from pathlib import Path\nimport json,time\nroot=Path('/example')\nprint(json.dumps({'synthetic_value_matches':(root/'one').read_text()=='DEMO_ONLY_NOT_A_CREDENTIAL',\n 'unused_key_absent':not (root/'unused').exists(),\n 'service_account_token_absent':not Path('/var/run/secrets/kubernetes.io/serviceaccount/token').exists()}),flush=True)\ntime.sleep(600)"
 podspec = spec(probe)
 podspec['serviceAccountName'] = 'creator'
 podspec['volumes'] = [{'name': 'example', 'secret': {'secretName': 'example',
 'items': [{'key': 'needed', 'path': 'one'}], 'defaultMode': 0o400}}]
 podspec['containers'][0]['volumeMounts'] = [{'name': 'example', 'mountPath': '/example', 'readOnly': True}]
 definition = {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'reader', 'namespace': namespace},
 'spec': podspec}
 k('--as', identity, 'create', '-f', '-', payload=definition)
 wait_for(lambda: obj(namespace, 'pod', 'reader'), pod_ready)
 output = wait_for(lambda: k('--as', identity, 'logs', '-n', namespace, 'reader').stdout.strip(), bool)
 observed = json.loads(output)
 assert all(observed.values())
 print(json.dumps({'api_base64_decodes_to_synthetic_value': True,
 'direct_secret_get_forbidden': True, 'same_identity_can_create_consuming_pod': True,
 'mount_observation': observed, 'etcd_encryption_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序创建包含两个演示键的 Secret，确认 API 中的 base64 可以还原成给定的合成文字。然后为服务账号绑定一个角色，允许创建 Pod 和读取 Pod 日志，却不给读取 Secret 的权限。管理员以这个账号身份发出的直接读取请求会返回 Forbidden，因此这一步实际验证了对应的 API 授权拒绝。

同一个被模拟的主体接着创建 Pod，只投射需要的键。由它指定的工作程序确认：读到预期演示值，未需要的键没有出现，也不存在自动挂载的服务账号令牌。该主体再通过获准的日志接口读取这些布尔结果。全部检查通过，展示了直接请求被拒绝之后，工作负载路径仍然能够取得指定内容，而不是仅从权限配置进行猜测。

命名空间最后被删除。本实验没有使用真实凭据或实际签发的服务账号令牌，也没有测试底层存储加密和轮换流程。它建立的是授权与投射行为的证据，不是一套完整秘密管理系统。在称某份数据已经严格限定范围之前，应同时评估直接读取者，以及能够创建或修改读取者的主体。

来源

Kubernetes: Secrets，API 表示、消费方式和访问含义，已核验 2026-09-13。
Kubernetes: Good practices for Secrets，加密、最小权限与工作负载访问，已核验 2026-09-13。
Kubernetes: RBAC authorization，资源操作、角色绑定和命名空间范围，已核验 2026-09-13。

安全 · XB 现场笔记

ssh agent 传递密钥而不暴露

远程拿到的是套接字，不是密钥

转发是逐跳选择的

服务端能管和管不了的事

坏掉的样子

快速验证

来源

OCSP Staple 免去一段往返校验

服务器只取一次

客户端免去一次查询

是 Staple,不是绝对保证

坏掉的样子

快速验证

延伸阅读

来源

安全上下文需要运行时证据来验证

把设置放在正确层级

坏掉的样子

快速验证

延伸阅读

来源

证书透明度是一本台账，不是机密

承诺不等于包含证明

坏掉的样子

快速验证

延伸阅读

来源

SYN Cookie 在队列溢出时作答

两个队列，两种症状

Cookie 就是你拒绝保存的那份状态

Cookie 装不下的东西

坏掉的样子

快速验证

来源

TLS ECDHE 保证前向保密

两类密钥承担不同职责

坏掉的样子

快速验证

延伸阅读

来源

内核把设备噪声转成密钥

熵池是输入，生成器是产物

/dev/random 不再是「更谨慎」的选择

真正要紧的窗口只有启动那一小段

坏掉的样子

快速验证

来源

签名镜像可以证来源

摘要是身份，标签是指针

对标签签名绑不住任何东西

校验才是控制，签名不是

坏掉的样子

快速验证

来源

OAuth 授权码用码换令牌

浏览器只拿 code

后端负责兑换

code 一次性且短命

坏掉的样子

快速验证

延伸阅读

来源

请求走私把代理链路带偏

两个解析器，一条消息边界

分歧的四种形状

连接上的下一条请求才是载荷

坏掉的样子

快速验证

来源

JWT 带着签名与寿命

编码不加密

签名先行为先

过期即契约

坏掉的样子

快速验证

延伸阅读

来源

预备语句把取值与 SQL 结构分开

坏掉的样子