安全 · XB 现场笔记

SSH 代理转发的权限边界

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

agent 转发并不等于 agent 本身。本地 agent 可以替客户端完成认证操作，而不把私钥交给服务器；转发则进一步在远端开放一个套接字，让那边的程序也能请求这项服务。因此，「私钥材料留在本地」和「身份认证能力只留在本地」是两个不同的承诺。

选择堡垒机访问方式时，这个区别尤其重要。如果只是要登录内网机器，通常用 ProxyJump 并关闭 agent 转发就够了。只有程序确实需要在远端发起认证，例如一条经过明确授权的后续 SSH 连接，才需要考虑把 agent 的使用能力交过去。不要把网络可达性和身份委托混成一个开关。

远端拿到的是能力

转发出来的套接字通常通过远端的 SSH_AUTH_SOCK 暴露。能访问它的进程，包括拥有足够权限的本机攻击者，都可以向原始 agent 请求操作。这不意味着服务器上的任何普通账户都有权限，更不意味着私钥文件已经被复制过去；风险来自可以调用身份，而不是必须先偷到密钥。

一把没有额外约束的已加载密钥，在转发通道仍然可用时，可能被拿去完成你没有打算批准的登录。密钥的存活期、逐次确认、目标限制，以及目标服务器是否接受这个身份，都会改变请求能否成功。把它说成「完整拥有私钥」不够准确，把它说成「只是一只无害套接字」同样会误导操作判断。

旧版本曾把一枚没有解释来源的八十八字节签名当作证据。单看长度，既不能证明实验实现了 OpenSSH agent 协议，也不能证明一次经过转发的认证成功。下面改用真正的 SSH 客户端，验证一个范围明确、读者可以复现的性质：最终生效的转发选项。这个检查不冒充真实网络集成测试。

转发由生效配置决定

命令里没有 -A，并不代表关闭了转发。匹配的 Host 段、被包含的配置文件，或者系统配置，都可能已经把它打开。反过来，即使文件写着 ForwardAgent no，命令行上的 -A 仍会显式启用转发。需要关闭时，应当使用 -a，或者没有相互矛盾选项的 -o ForwardAgent=no。

ProxyJump 提供到目标的 TCP 路径，并不会顺便重置目标连接的转发选项。目标 SSH 连接及其认证仍从本地发起，所以单纯借道跳板机不需要把 agent 暴露过去。目标和跳板机的配置也不一定一样，应分别检查相应别名，不要把某一条 ssh -G 的输出理解成整条路径的所有设置。

如果已经进入远端 shell，再运行一次 SSH，那台机器上的客户端会读取它自己的配置。判断哪一跳继续转发，要看每次调用的有效设置，不能数历史命令里出现过几次 -A。排查已有连接时还要留意连接复用：打印当前配置描述的是这次拟议调用，不能反推所有既有主连接的运行状态。

缩小委托范围

ssh-add -c 通过 askpass 程序请求使用确认，不能只因为请求方没有终端，就断言确认必然失败。ssh-add -t 可以限制身份留在 agent 中的时间。自 OpenSSH 8.9 起提供的目标约束依据已知主机密钥识别主机，经过转发路径使用时还需要客户端和服务端配合支持。协作路径上的每一跳都须获准；恶意节点仍可用其他工具再次中继套接字，但签名仍受获准目的地限制，不能把路径约束当作绝对防中继机制。

服务端设置 AllowAgentForwarding no，可以关闭 OpenSSH 自带的转发设施，但不能阻止拥有不受限制 shell 的用户另行搭建转发器。这个限制有配置卫生价值，却不能单独隔离一个恶意 shell 用户。仍然应该把服务器信任关系和可执行程序的权限纳入判断。

坏掉的样子

堡垒机被攻陷后，攻击者可能在转发通道和相应身份仍可用的窗口里滥用 agent。在磁盘上换掉私钥文件，并不会自动卸载 agent 内存里的旧身份。处置时应终止转发连接、移除相关的已加载身份；如果风险需要，再撤销服务器接受该身份的授权。已经建立的远程会话不会因此自动消失，需要另外处理。

另一个常见问题是把 ForwardAgent yes 放进 Host * 后忘记它。最好只为确实需要的主机设置例外，并让用于转发的 agent 只包含必要身份。给某次登录指定 IdentityFile，并不会把整个转发 agent 过滤成只有那一把钥匙。登录时选什么身份，和远端能向 agent 请求什么，是两个不同层次的问题。

ProxyJump 提供路径，代理转发暴露签名能力。生效配置与协作式目的地限制须分别检查。

快速验证

下面的一次性配置打印四项设置，供人工比较，不连接网络或读取私钥。代码没有值断言，也没有失败与清理陷阱；示例域名仅用于配置匹配：

f=$(mktemp)
printf 'Host *\n ForwardAgent no\n' > "$f"
ssh -G -F "$f" target.invalid | grep '^forwardagent '
ssh -G -F "$f" -A target.invalid | grep '^forwardagent '
printf 'Host *\n ForwardAgent yes\n' > "$f"
ssh -G -F "$f" -J bastion.invalid target.invalid | grep '^forwardagent '
ssh -G -F "$f" -a -J bastion.invalid target.invalid | grep '^forwardagent '
rm "$f"

保留的 OpenSSH 10.0p2 记录报告顺序为 no、yes、yes、no；本轮没有重新执行。这验证了选项处理，不验证套接字权限、签名操作、目标约束，也没有建立真实的多跳连接。检查可信配置时，可以查看 ssh -G destination 和各跳板别名；但 Match exec 求值可执行本地命令，主机名规范化也可能触发 DNS，不能把任意配置检查都当作无副作用。每一个 yes 都应该能回答两个问题：为什么需要转发，以及接收方为什么值得信任。

来源

OpenBSD：ssh，命令行转发开关、跳板连接与配置检查，已核验 2026-10-15。
OpenBSD：ssh_config，ForwardAgent、ProxyJump 与配置优先级，已核验 2026-10-15。
OpenBSD：ssh-agent，agent 套接字与无需传输私钥的认证方式，已核验 2026-10-15。
OpenBSD：ssh-add，askpass 确认、存活期与目标约束的支持条件，已核验 2026-10-15。
OpenBSD：sshd_config，AllowAgentForwarding 与 shell 访问下的限制，已核验 2026-10-15。

OCSP 装订按客户端策略交付状态证据

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

OCSP 装订让 TLS 服务端在握手过程中发送签名的证书状态响应。对于原本需要在线查询 OCSP 的客户端，它可能省去一次单独请求。收益取决于客户端的吊销策略：并非每个浏览器每次连接都查询 OCSP，也不是每个证书颁发机构仍然提供这种服务。装订只是传递状态证据的一种方式，不能代替完整证书验证，更不能把“握手收到了一段数据”当作信任已经成立。

传递证据并不转移信任责任

服务器从颁发机构或获得授权的应答方取回响应，并为适用握手缓存它。客户端仍须检查响应签名、签名者权限、证书标识、状态和可接受时间范围。服务器把响应附在握手里，不会让它自动可信。OCSP 的 good 状态也不能证明主机名匹配、证书仍在有效期内，或整条证书链已经连接到受信任根。这些验证职责必须分别保留。

线上表示还取决于 TLS 版本。TLS 1.2 使用状态请求扩展与 CertificateStatus 握手消息；TLS 1.3 则把响应放在对应 Certificate 条目的扩展中。把两者统称为 certificate_status 扩展，会混淆实际协议结构。普通网络攻击者不能随意剥离受认证握手消息，同时仍让 Finished 校验成功。讨论吊销检查被绕过时，应明确攻击能力和客户端策略，而不是虚构一种可以无痕删除握手数据的能力。

先核对支持范围，再决定启用

运维者首先需要确认颁发方提供可用响应，并检查服务端及客户端是否支持预期策略。Let’s Encrypt 已在二〇二五年八月六日结束 OCSP 服务，改用证书吊销列表。因此，对于没有 OCSP 支持的证书，缺少装订不自动意味着刷新任务损坏。应查当前颁发方文档，而不是把“所有站点都应该打开装订”当成不需要前提的清单步骤。

对于仍提供 OCSP 的颁发方，应在缓存过期之前留出刷新余量，并覆盖证书轮换。需要检查响应对应哪张证书、新鲜度及边缘实际交付内容，而不只是缓存是否存在。不同服务进程可能持有不同结果；控制面抓取成功也不证明全部已更新。缓存中的 good 响应仍可能在可接受窗口内，而较新的吊销信息已经出现，因此装订不能提供瞬时吊销知识。

坏掉的样子

缺失、过期、无效和已吊销是不同状态。客户端可能拒绝连接、查询其他机制，或应用明确的软失败策略。缺少响应不保证触发直连颁发机构，已经提供但无效的响应也不保证仅仅增加延迟。描述时应说明具体校验器的行为，不要承诺所有握手都会继续，更不能把“没有报错”直接解释为吊销状态已经得到确认。

TLS Feature 扩展通常被称为 Must-Staple；支持并执行它的客户端，可以要求服务器提供状态证据，但它不能强迫不支持的客户端执行同样检查。依赖这个要求之前，服务端需要处理冷启动、续期及应答服务中断。服务中断并不会立刻使仍在可接受窗口内的缓存失效，但剩余新鲜度窗口会限制它还能保护多久。是否失败必须结合实际缓存与客户端规则判断。

时钟异常也会改变接受结果。thisUpdate 和 nextUpdate 描述状态时间，producedAt 描述响应生成时间；真实校验器还会采用自己的最大年龄和时钟容差规则，有些协议响应也可以不带 nextUpdate。这些实现差异应明确写出。程序里一个名叫“签名正确”的布尔值，只是输入假设，不能作为真实密码学验签的证据。

OCSP 证据交付：机制与证据边界。

快速验证

保存为 stapling_policy.py，使用 Python 3.9 或更新版本执行 python3 stapling_policy.py。独立模型使用虚构的验证后输入，明确要求两个时间边界，并对已经提供但无效的证据采取严格拒绝策略。它不访问网络，不解析证书，不实现签名算法，也不运行 TLS 服务或浏览器，因此不能用于证明任何真实证书可信。

"""Post-verification policy model. Booleans are fixtures, not cryptography."""
from dataclasses import dataclass, replace
from datetime import datetime, timedelta, timezone

@dataclass(frozen=True)
class Response:
 cert_id: str
 status: str
 signature_ok: bool
 signer_authorized: bool
 this_update: datetime
 next_update: datetime

def decide(response, now, cert_id, require_staple):
 if response is None:
 return "reject-missing" if require_staple else "consult-other-policy"
 if response.cert_id != cert_id:
 return "reject-wrong-certificate"
 if not (response.signature_ok and response.signer_authorized):
 return "reject-untrusted"
 if not response.this_update <= now < response.next_update:
 return "reject-time"
 if response.status == "revoked":
 return "reject-revoked"
 if response.status != "good":
 return "reject-unknown"
 return "status-good-only"

now = datetime(2026, 10, 15, 12, tzinfo=timezone.utc)
good = Response("synthetic-cert", "good", True, True,
 now - timedelta(hours=1), now + timedelta(hours=1))
cases = [
 (good, False, "status-good-only"),
 (None, False, "consult-other-policy"),
 (None, True, "reject-missing"),
 (replace(good, status="revoked"), False, "reject-revoked"),
 (replace(good, status="unknown"), False, "reject-unknown"),
 (replace(good, signature_ok=False), False, "reject-untrusted"),
 (replace(good, signer_authorized=False), False, "reject-untrusted"),
 (replace(good, cert_id="another-cert"), False, "reject-wrong-certificate"),
 (replace(good, next_update=now), False, "reject-time"),
 (replace(good, this_update=now + timedelta(minutes=1)), False, "reject-time"),
]
for response, required, expected in cases:
 actual = decide(response, now, "synthetic-cert", required)
 assert actual == expected, (actual, expected)
 print(actual)
assert decide(good, now + timedelta(hours=2), "synthetic-cert", False) == "reject-time"
print("PASS: 11 explicit policy cases; no certificate or TLS validation performed")

十一项检查区分可接受状态、缺失、已吊销、未知状态、错误证书、未授权签名者、错误签名、过期和未来日期。最后把观察时间向后移动，验证这个模型的严格时间区间。可选装订缺失时返回 consult-other-policy，它不是接受结论，也不表示已经向外查询过任何服务。这一分支有意保留后续策略决定。

成功结果特意命名为 status-good-only，提醒读者其余证书验证仍在函数之外。保留的 Python 3.12.14 记录报告这些精确示例通过运行；本次源码审阅没有重跑。必须启用断言，不使用 -O 或 PYTHONOPTIMIZE。真正线上验证仍须核对颁发方、签名响应、TLS 交付、客户端策略、证书轮换和刷新失败，不能从模型分支推导整个部署已经可靠。

来源

RFC 6960，响应授权、证书绑定、状态和时间语义，已核验 2026-10-15。
RFC 6066，TLS 1.2 状态请求与证书状态消息，已核验 2026-10-15。
RFC 8446，TLS 1.3 证书条目状态扩展和握手认证，已核验 2026-10-15。
RFC 7633，TLS Feature 要求与客户端支持，已核验 2026-10-15。
Let’s Encrypt OCSP retirement，颁发方在二〇二五年八月六日结束 OCSP 服务，已核验 2026-10-15。
Python assert 语句，优化模式会移除断言及其表达式，已核验 2026-10-18。

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

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

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

原文 Kubernetes 1.34.11 历史样例，本次未重跑。结果反映组合设置；RuntimeDefault 取决于运行时。没有测试容器逃逸抵抗、全部 seccomp 规则、敌对多租户隔离或应用授权。执行仍为受阻。

把设置放在正确层级

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、允许权限提升或打开整个根文件系统来处理所有权限报错。必要写入与过大权限需要通过真实调用区分。

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备临时 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-10-15。
Linux: No New Privileges Flag，通过执行程序获取新权限的限制，已核验 2026-10-15。
Linux: capabilities(7)，独立能力权限与进程能力集合，已核验 2026-10-15。

证书透明度让签发可被观察

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 会改变本例的树根，旧的三叶树证明也不能再用来匹配这个新根。

文章使用三个合成字符串与 RFC 6962 哈希前缀。B 的固定证明包含 A、C 哈希，重建 branch(branch(A, B), C)。硬编码根仅在实验中视为可信；没有验证 SCT 签名、在线日志公钥、一致性证明、浏览器策略或签发授权。

保留原文记述了 macOS、Go 1.27.0 上全部断言通过的结果；本轮没有重跑该 Go 夹具。硬编码测试根只在本例中代表已经可信的三叶检查点，程序没有实现 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

Linux TCP 监听端区分尚未完成的握手请求，以及已经建立但等待应用 accept() 的连接，通常称为 SYN 队列和 accept 队列。两者容量限制与溢出路径不同，排查连接故障时应先确定压力发生在哪个阶段，不能把所有等待都归到同一个 backlog 数字。

SYN Cookie 减少握手未完成期间需要保留的逐请求状态。服务器把可恢复信息编码到 SYN-ACK，收到有效回复后重建连接状态。节省的是待完成请求的内存，不代表处理没有开销，也不取消已建立连接的状态，更不保证一定准入或保持正常应用性能。

SYN Cookie 作用于握手。校验不会绕过 accept 队列，也不会增加应用接受能力。

两个队列，两种症状

普通有状态路径会保留请求，等待最后一个 ACK。Linux 文档将 tcp_max_syn_backlog 描述为每个监听端记住的请求上限；随内存变化的默认值与请求大小估算，不是所有机器的分配实测。等待应用接受的已建立连接，则由 listen() backlog 及 somaxconn 上限约束。Linux 从 5.4 起将 somaxconn 默认设为 4096，但部署值可以不同。

Cookie 可以缓解未完成握手状态耗尽，却不保证连接一定完成。accept 队列满时，已建立子连接可能无法创建或准入。tcp_abort_on_overflow=0 下，某些有状态路径忽略 ACK 并保留待完成请求，之后仍可能恢复。客户端可能已经报告 connect 成功，其他尝试也可能超时。本次审阅没有重现原有四百客户端说法，也未将其绑定到保留的原始结果，不能据此确定具体丢失数量。

启用 CONFIG_SYN_COOKIES 的 Linux 中，模式一把 Cookie 用作溢出后备措施；模式二用于无条件生成的测试。固定 Linux 6.12 的 IPv4 实现把带密钥哈希、客户端初始序列号、时间计数器和 MSS 表索引合成为序列号。返回确认号的原始高位，并不是可以直接读取的计数器，不能只按位切开就宣称完成校验。

该实现每六十秒推进一次计数器，只有当前或前一个计数槽才会继续校验。七十秒前生成的 Cookie 可能已经跨过两个边界而失效，单凭经过时长不能确定结果。校验还绑定连接字段，并检查恢复出的索引。这些机制抵抗盲目伪造，但不是应用身份认证，也不能用统一的二十四位猜中概率代替完整安全论证。

选项支持取决于实现与本次握手。Linux 6.12 可以把窗口缩放、SACK 与 ECN 信息编码到时间戳位，再从回显时间戳恢复；缺少这条时间戳路径时，某些选项可能丢失。内核文档对扩展和性能限制发出警告，却不能据此断言每个 Cookie SYN-ACK 都没有选项，或每条获准连接必然更慢。应以对应版本的实际实现和握手内容判断。

固定版本的 IPv4 实现从四个 MSS 表项中选择，不能原样保留任意通告。如果没有窗口缩放，65535 字节接收窗口可能限制长 RTT 传输；这是带条件的窗口约束，不是 Cookie 模式吞吐实测。缺少 SACK 会改变恢复信息，但不强制重传后续所有段。先捕获实际选项，再判断减速是否来自 Cookie，不能仅凭启用状态推导性能损失。

坏掉的样子

Cookie 可能降低可见的待完成请求深度，但压力仍在持续。应把 SyncookiesSent 增量与队列占用、连接尝试、CPU 负载、警告和应用结果一起观察。计数上涨不证明遭遇攻击，合法过载或无条件测试模式也会产生 Cookie。应用仍可能失败，相关指标仍有价值，不能断言洪泛必然没有错误日志或应用层迹象。

Cookie 不增加 accept 队列或应用处理容量。选择补救办法前，应同时调查 ListenOverflows、接受速率与资源限制。更大的 backlog 可以吸收部分突发，却不增加持续处理能力；更快接受或增加工作进程，只有在对应阶段确为瓶颈时才有帮助。修改 Cookie 模式不能修复停滞应用，也不能保证所有观察数字都完全不变。

快速验证

以下只读 Linux 命令检查配置、累计计数和监听队列，不会复现洪泛、验证 Cookie 或测量报文交付：

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

在相关网络命名空间取可比较的快照，重点看增量。当前健康的服务也可能有非零历史计数，accept 队列短暂非空同样正常。对监听 TCP 套接字，Recv-Q 表示握手完成后等待接受的连接，Send-Q 表示 backlog 上限。持续接近上限的占用、新增溢出与请求失败共同出现，比任何单独累计总数更能支持接受阶段存在压力的判断。

来源

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。
Linux 6.12 IPv4 SYN cookies，带密钥的 Cookie 构造、MSS 表与时间戳携带选项，已核验 2026-10-19。
Linux 6.12 TCP Cookie 计时，六十秒计数器与两个计数槽年龄检查，已核验 2026-10-19。
Linux 6.12 待完成请求处理，带条件的溢出处理与请求保留，已核验 2026-10-19。

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 上全部断言通过的结果；本轮没有重跑该 Go 夹具。只输出结果标签。程序为了对照，刻意保留了前一轮共享机密，所以它没有证明安全擦除，也没有通过穷举证明密码学难度。比较观察到的两组结果，不能扩大成对所有随机输出永不重复的数学承诺。

实验分别观察了密钥协商、一轮一换、签名认证和非法输入处理，但没有执行真实 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

Linux 应用通常从内核的密码学安全生成器取得随机字节，不是每输出一位，就必须重新采集一位物理噪声。不过，初始化和状态复用仍然重要。机器繁忙不自动意味着安全，机器安静也不自动意味着故障。判断之前，应确认所用接口、内核版本，以及启动或克隆流程，不能只凭一个计数器就宣布密钥已经不安全。

区分采集与输出

Linux 6.12 的实现把输入混入基于 BLAKE2s 的池，并用 ChaCha20 生成输出。这是该版本的实现细节，不是所有未来版本永远不变的接口契约。硬件来源、中断时序和引导程序输入，按具体平台的信任规则参与。加入字节与把这些字节计入初始化熵估算，是两件不同的事；内核不能假设用户任意提供的一串字节都包含新鲜、不可预测的信息。

在这个实现中，poolsize 与初始化完成后的熵计数都达到二百五十六位，读取不会像消耗燃料一样扣减计数。因此，旧手册里四千零九十六位的描述，不应直接变成所有机器的告警阈值。应记录运行内核并检查对应行为，不能声称所有 Linux 版本的计数都一样，也不能仅因数字较小就判定随机输出薄弱。

选择会等待初始化的接口

默认 getrandom 会等到初始化完成。带 GRND_NONBLOCK 时，尚未初始化会报告 EAGAIN，使应用能够说明状态而不无限等待。初始化以后，默认源的一次请求若不超过二百五十六字节，具有文档规定的完整读取与信号保证；调用方仍应检查错误和返回长度。更大请求要正常处理部分返回和中断，不能把小请求的保证扩大到所有缓冲区。

random 设备从 Linux 5.6 起改变了行为：初始化后不再因为所谓熵耗尽而阻塞。在核对的 Linux 6.12 源码中，GRND_RANDOM 也不选择一个独立、会被耗尽的输出池。有些手册仍保留旧行为描述，不应把历史限制与当前内核结论混合。直接读取 urandom 可能发生在初始化之前；早期启动生成密钥，应使用支持初始化等待的接口。

坏掉的样子

早期启动仍可能缺少足够的可信计入输入。容器中缺少设备节点则是另一类接口问题：getrandom 不需要设备路径，普通容器共享宿主内核。操作等待时，应有明确的启动失败或等待策略，而不是改用时间戳、可预测种子或不安全的备用输出。让服务尽快启动，不是降低密钥生成要求的理由。

保存的种子可以帮助下一次启动，但把文件写回 urandom 并不会自动增加熵计数。一个三十二字节文件，或者某种硬件设备的存在，都不能单独保证立即就绪。应使用发行版提供的种子管理机制，了解它何时、依据什么信任条件计入熵。保护种子文件，避免在克隆镜像里分发相同的保存种子，并让引导程序专用的种子处理与操作系统流程一致。

复制磁盘镜像和恢复运行中的虚拟机，是两种不同风险。前者可能复制种子文件或已经生成的主机密钥，后者可能复制正在使用的生成器内存状态。新输入及虚拟机生成标识处理，可以让后续状态分离。未来输出完全相同是需要调查的风险，不是每次克隆必然出现的结果；两台机器使用同一份种子，也不足以证明它们全部生成器状态完全一致。

输入计入、初始化与输出各有边界。仅标明的 Linux 6.18.44 结果属于保留历史观察；本轮没有请求随机字节。

快速验证

在 Linux 上运行下面的 Python 3 脚本。它读取计数器，并请求一次非阻塞的三十二字节输出；不会打印随机内容，不读取私钥，不更改种子文件，也不需要管理员权限。这样可以观察接口是否就绪，而不把诊断过程变成密钥材料收集或系统配置变更。

from pathlib import Path
import json
import os
import platform

def counters():
 result = {}
 for name in ("entropy_avail", "poolsize"):
 try:
 result[name] = int(Path("/proc/sys/kernel/random", name).read_text())
 except OSError as error:
 result[name] = type(error).__name__
 return result

before = counters()
try:
 sample = os.getrandom(32, os.GRND_NONBLOCK)
except BlockingIOError:
 print(json.dumps({"kernel": platform.release(), "ready": False,
 "counters": before}))
else:
 assert len(sample) == 32
 print(json.dumps({"kernel": platform.release(), "ready": True,
 "bytes_returned": len(sample), "before": before,
 "after": counters()}))

保留的历史审计输出记录了 Linux 6.18.44、Python 3.12.14 上的结果： ready=true、bytes_returned=32，前后两个计数器都为二百五十六。这只是已初始化主机上的结果，不是早期启动、硬件质量或恢复虚拟机的测试。出现 EAGAIN 时程序报告 ready=false，这个分支没有被复现。本次仅审阅源码，没有请求随机字节。其他系统调用错误会向外传播，不能直接解释成尚未初始化，也不能把未执行分支标记成实测通过。

成功调用说明当前接口在这一时刻提供了要求的字节，不是随机性统计检验，更不是密码学不可预测性的证明；比较两次样本也无法给出这种证明。如果 proc 访问受限，计数器可能显示错误类型，而系统调用仍然成功。应分别解释这些情况，不能把诊断信息不可读直接当作熵故障，也不能把成功返回当作所有启动和克隆风险均已排除。

用直接证据调查身份复用

密钥文件的修改时间不能证明生成时使用了哪个随机源。文件会跨重启保存，复制可以保留时间戳，系统时钟也可能调整；看不到初始化日志同样不能证明初始化失败。应检查镜像准备流程、密钥生成代码、启动策略和重复的公钥指纹。确认身份重复或泄露时再制定轮换措施，不应仅凭时间戳对比就宣布一批密钥已经受损。

来源

Linux 6.12 随机数实现，初始化计数、getrandom、sysctl 与虚拟机分叉重播种，已核验 2026-10-15。
Linux getrandom(2)，初始化等待、小请求与错误；历史 GRND_RANDOM 描述需结合版本，已核验 2026-10-15。
Linux random(4)，写入不计熵及 Linux 5.6 阻塞变化；历史池大小不代表当前内核，已核验 2026-10-15。
systemd 256 随机种子服务，种子生命周期、熵信任策略与镜像准备，已核验 2026-10-15。

镜像签名把摘要绑定到受信任签名者

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

容器镜像标签是可变指针，摘要则标识内容。有效签名把一份关于该摘要的声明绑定到签名密钥；这把密钥是否代表获授权的人或工作负载，要由信任策略判断。单靠签名，不能证明谁构建了镜像、构建是否遵循所宣称的流程，也不能证明软件内容安全。这些问题需要不同证据，不能因为校验成功就合并成一个结论。

真正有用的边界，是部署之前的验证决定。校验方需要检查内容绑定和预期信任根，再执行身份与来源策略。registry 地址、熟悉的标签，或者存在某份签名，都不足以独立构成放行依据。必须知道自己信任谁、允许其声明什么，以及这份声明究竟覆盖哪一个产物。

摘要是身份，标签是指针

OCI 清单摘要对精确清单字节进行哈希，清单中的描述符再通过各自摘要标识配置与层，客户端也须核对这些绑定。在哈希抗碰撞假设下，清单改变会得到不同摘要。如果只修改存储层中的字节却不更新描述符，应触发内容完整性失败，而不是悄悄把原镜像重新定义成另一份内容。内容寻址依赖实际校验，不只是路径看起来像摘要。

Cosign 的普通镜像签名载荷包含镜像摘要，验证时会把它与请求的镜像比较。不同标签可以指向同一个已签名摘要；标签一旦移动，先前的校验不能覆盖新对象。应解析并验证目标摘要，再部署同一个摘要。如果校验之后重新按标签拉取，就留下检查与使用之间的竞争窗口；重复查询标签也不能彻底关闭这个窗口。

标签字符串不能绑定镜像内容

对字面字符串 app:v2 签名，认证的是这个声明，并不是名字后面不断变化的对象。签名也可以包含其他上下文，所以需要检查真实载荷格式与校验器行为，而不是把所有方案都说成只签一个裸哈希。不要为了让不匹配的载荷通过，就关闭摘要声明校验，否则签名有效与目标镜像之间的关键联系会丢失。

基于密钥的校验，需要由策略说明为什么信任所给公钥。无密钥校验还要检查预期证书身份与 OIDC 颁发者，以及证书链和所要求的透明日志证据。Fulcio 证书把身份关联到密钥，不会检查构建过程或认证软件质量。要判断构建声明，还需要适当的来源证明、受信任的构建者，以及证明中主体摘要与待运行产物一致的检查。

校验才是控制，签名不是

强制检查可以放在准入或部署前，但效果取决于实际覆盖范围。需要确认哪些工作负载与 registry 被纳入策略，以及校验失败时如何处理。只记录摘要不能证明发布获授权；即使签名正确、身份也获授权，仍不能据此排除所有漏洞或恶意行为。安全测试与构建来源验证应各自提供证据，不能相互替代。

密码学签名有效与当前策略接受，是两回事。退役密钥需要更新所有相关验证方的信任策略，仅生成一把新密钥不会自动完成撤销。短期证书配合可信签名时间证据，可以支持证书到期之后验证历史签名。透明日志让活动可检查，却不会自动撤销泄露身份或阻挡恶意发布。事故响应仍须决定保留哪些身份、时间窗口、摘要和证明，不能把日志存在等同于风险已解决。

坏掉的样子

部署步骤先验证一个摘要，随后又按可变标签拉取；另一次推送就可能让最终运行的字节变掉。需要把经过验证的摘要一直传到部署交接处，并明确它指向单平台清单还是多平台索引，确认运行时怎样选择具体平台镜像。这样才能说明实际运行对象与被检查对象之间的关系。

另一种失败是接受任何能通过密码学检查的签名者。应把信任限制到获授权密钥，或明确的身份与颁发者组合，并测试错误签名者和未批准摘要会被拒绝。发现泄露后需要调查并改变策略；这并不自动证明该密钥以前签过的所有产物都恶意，也不能承诺继续接受它们一定安全。

镜像签名信任：机制与证据边界。

快速验证

下面是命令模板，不是可直接运行的夹具：registry 是示例，摘要也被省略。进行获授权的 registry 检查之前，需提供已有测试镜像的完整摘要、可信公钥，并确认所安装的 Cosign 与 Skopeo 版本。本次源码审阅没有签名、操作 registry 或执行部署，因此没有新的集成运行结果。

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 tree 发现关联对象，列出对象不等于验证其中声明。Skopeo 可以查看标签当下指向；如果不同，只说明它与刚才检查的摘要不同，另一个摘要仍可能有自己的签名。即使两者相同，也只是观察时刻的快照，无法阻止标签随后移动。

来源

Sigstore：用 cosign 校验签名，基于密钥与无密钥的摘要校验，已核验 2026-09-16。
SLSA v1.0 规范，来源信息、摘要，以及签名到底在证明什么，已核验 2026-09-16。
Sigstore policy-controller，在准入阶段强制签名与身份策略，已核验 2026-09-16。
OCI 镜像描述符规范，摘要与所引用内容的绑定，已核验 2026-10-18。
SLSA v1.0：验证产物，可信构建者与来源策略不等于签名有效，已核验 2026-10-18。
Sigstore 概览，身份证书与透明日志的边界，已核验 2026-10-18。
Sigstore 时间戳，可信签名时间与证书有效期，已核验 2026-10-18。
Sigstore：容器签名，tree 发现关联签名，已核验 2026-10-18。
Skopeo inspect 手册，顶层清单摘要与平台相关字段，已核验 2026-10-18。

OAuth 授权码用码换令牌

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

授权码流程把访问令牌的交付移到令牌端点，而不是在面向浏览器的授权重定向里直接返回访问令牌。这能减少令牌暴露在地址中的机会，却不代表浏览器绝不可能持有令牌。究竟由谁兑换授权码，以及结果保存在哪里，取决于客户端架构。审阅时应区分协议步骤、客户端类型和实际存储位置，不能把一种部署方式当成整个流程的定义。

授权跳转传递授权码，令牌端点交付令牌。PKCE、客户端与回调绑定、过期和单次使用各守一条边界。存储方式取决于客户端架构；离线模型不能证明完整登录流程。

公共客户端也能使用授权码流程

机密 Web 后端可以向令牌端点进行客户端认证，并把令牌保存在服务端。浏览器随后使用应用自己的会话，但会话安全仍需单独处理。原生应用和浏览器应用等公共客户端无法可靠地保守分发出去的客户端秘密，然而它们仍然可以使用授权码加 PKCE。因此，授权码流程并不是只有后端才能采用的方案。

若浏览器应用自行兑换，JavaScript 就会收到令牌响应。流程避免了在授权跳转地址里交付访问令牌，却不会消除脚本被入侵或令牌存储泄露的问题。后端架构改变了边界，并没有让所有浏览器侧风险消失。OAuth 解决委托访问；需要确认用户身份的应用，应采用 OpenID Connect 等适合的身份协议，并验证其中独立的身份凭据，不能把任意访问令牌直接当作登录证明。

把兑换绑定到原始请求

PKCE 为每次事务生成高熵校验串。授权请求携带它的 S256 挑战，令牌请求再提供原校验串，授权服务器检查二者是否对应。校验串不是固定的客户端口令，必须与发起它的事务关联。这样，只有截获授权码、却没有校验串的一方，不应能够完成兑换。日志和错误报告也不应同时泄露这两部分。

RFC 9700 要求公共客户端使用 PKCE，并建议机密客户端也使用。应选择 S256，避免降级成 plain。机密客户端仍需执行已配置的客户端认证，PKCE 不能代替这一职责。客户端认证也不一定意味着发送共享秘密；部署可以采用非对称认证机制。判断安全性时，要核对服务端实际执行的验证，而不是只看请求里出现了几个参数。

每枚授权码都应绑定客户端与回调地址，设置短有效期并限制只能使用一次。登记的回调地址通常必须精确匹配；原生应用的回环地址端口存在标准规定的例外。授权请求携带 redirect_uri 时，令牌请求中的值必须一致。在授权阶段就要拒绝未登记的回调，而不是等到授权码已泄露之后才靠兑换失败补救。

坏掉的样子

一次性并不能阻止攻击者抢先兑换一枚没有充分保护的授权码。过期只是缩短机会，不会让截获变得无害。回调中的授权码仍可能出现在访问日志、浏览器历史、来源信息和崩溃报告里。避免记录这些值，使用合适的 HTTPS 回调；开发原生客户端时，则按照原生回环重定向的专门规则处理，不要把例外扩展到任意明文回调。

客户端必须防止回调 CSRF 与授权码注入。事务状态应安全绑定发起请求的浏览器会话，并根据协议与提供方保证，正确组合 state、PKCE 或 OpenID Connect 的相应保护。随机 state 如果没有会话绑定，仍然不足。支持多个授权服务器时，还需防止签发者混淆；兑换成功本身，不能证明响应一定来自原本预期的身份提供方。

刷新令牌有独立的生命周期。对于公共客户端，安全最佳实践要求使用发送者约束，或者采用刷新令牌轮换。带重用检测的轮换是一种方案，并不意味着每枚没有变化的刷新令牌都无限有效。过期、撤销、不活跃时间限制和客户端绑定，共同决定真实的泄露窗口。不能只凭令牌字符串是否变化，就宣布整个刷新流程安全或失守。

快速验证

保存为 oauth_code_demo.py，执行 python3 oauth_code_demo.py。模型完全离线且单线程运行，使用合成客户端、明确登记的回调、每次新生成的随机授权码以及注入的时间。辅助函数接收校验串是为了在本地计算挑战；真正的授权请求只能发送挑战，不能把校验串一起送出去。程序不读取用户账号，也不调用任何身份提供方。

import base64
import hashlib
import hmac
import re
import secrets

REGISTERED = {'demo-client': 'https://app.example.test/callback'}
CODES = {}
NOW = 1_800_000_000


def challenge(verifier):
 if not re.fullmatch(r'[A-Za-z0-9._~-]{43,128}', verifier):
 raise ValueError('invalid verifier syntax')
 return base64.urlsafe_b64encode(hashlib.sha256(verifier.encode('ascii')).digest()).rstrip(b'=').decode()


def authorize(client, redirect, verifier, now):
 if REGISTERED.get(client) != redirect:
 raise ValueError('unregistered redirect')
 code = secrets.token_urlsafe(32)
 CODES[code] = {'client': client, 'redirect': redirect, 'challenge': challenge(verifier),
 'expires': now + 60, 'used': False}
 return code


def exchange(code, client, redirect, verifier, now):
 entry = CODES.get(code)
 if entry is None:
 raise ValueError('unknown code')
 if entry['used']:
 raise ValueError('code already used')
 if now >= entry['expires']:
 raise ValueError('code expired')
 if client != entry['client'] or redirect != entry['redirect']:
 raise ValueError('client or redirect mismatch')
 if not hmac.compare_digest(challenge(verifier), entry['challenge']):
 raise ValueError('PKCE verifier mismatch')
 # Atomic only because this demonstration runs sequentially in one thread.
 entry['used'] = True
 return 'DEMO-' + secrets.token_urlsafe(32)


def rejected(label, operation):
 try:
 operation()
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


client = 'demo-client'
redirect = REGISTERED[client]
verifier = secrets.token_urlsafe(32)
code = authorize(client, redirect, verifier, NOW)
rejected('wrong client', lambda: exchange(code, 'other-client', redirect, verifier, NOW))
rejected('wrong redirect', lambda: exchange(code, client, redirect + '/extra', verifier, NOW))
rejected('wrong verifier', lambda: exchange(code, client, redirect, 'x' * 43, NOW))
if not exchange(code, client, redirect, verifier, NOW).startswith('DEMO-'):
 raise RuntimeError('valid exchange failed')
rejected('replay', lambda: exchange(code, client, redirect, verifier, NOW))
stale = authorize(client, redirect, verifier, NOW)
rejected('exact expiry', lambda: exchange(stale, client, redirect, verifier, NOW + 60))
rejected('unregistered callback', lambda: authorize(client, 'https://other.example.test/', verifier, NOW))
print('PASS: bound code accepted once; six negative cases rejected')

预期打印六条拒绝结果和 PASS。正确兑换只成功一次。错误客户端、改变后的回调和错误校验串在消耗授权码之前失败；成功之后再次兑换则被拒绝。另一枚码恰好在到期时失败，未登记回调在签发前就被拒绝。代码和令牌既不打印，也不传输，所有状态仅在这次实验的内存中存在。

模型刻意比真实授权服务器简单。顺序执行的检查和标记操作没有测试并发；生产存储必须原子地消费授权码。示例还省略了 HTTP 处理、用户授权、客户端认证、浏览器会话绑定、签发者检查及刷新令牌处理。可把这些用例转成隔离配置中的集成测试要求，但通过内存实验不等于已经验证完整登录旅程，也不意味着可以直接部署这段代码。

来源

RFC 6749: OAuth 2.0，授权码绑定与令牌兑换，已核验 2026-10-15。
RFC 7636: PKCE，校验串语法与 S256 挑战，已核验 2026-10-15。
RFC 9700: OAuth 2.0 Security Best Current Practice，公共客户端、重定向、CSRF 与刷新令牌保护，已核验 2026-10-15。
RFC 8252: OAuth 2.0 for Native Apps，公共原生客户端与回环重定向，已核验 2026-10-15。

请求走私把代理链路带偏

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

请求走私发生在不同组件对 HTTP 消息边界理解不一致，而且攻击者利用了这种分歧的时候。在代理链中，被前端当作一个请求正文的字节，可能被后端当成另一个请求。关键证据是解析和转发结果不一致，而不只是抓包中出现两条 HTTP 状态行。理解问题时要把字节归属、连接复用和实际影响分开，不能直接用响应数量代替边界分析。

同一字节流，不相容的边界

HTTP/1.1 的组帧有明确规则。合法 Content-Length 可以指定正文长度；chunked 传输编码通过终止块和尾部字段结束。两种机制都没有的请求不包含正文。两种字段同时存在时，Transfer-Encoding 优先，但这是一种可疑组合，需要专门处理，而不是随意接受后继续复用连接。

RFC 9112 允许服务器拒绝同时携带两个字段的请求，或者仅按 Transfer-Encoding 处理；无论如何，响应后都必须关闭连接。中间组件若选择继续转发，必须先移除收到的 Content-Length，并在转发前处理 Transfer-Encoding。入口直接拒绝双重组帧是有用的严格策略，但不能把它说成标准描述的唯一合法行为。

CL.TE 表示前端使用 Content-Length、后端使用 Transfer-Encoding；TE.CL 则相反。其他分歧可能来自冲突长度，或对传输编码语法的不同处理。这些名称描述的是解析器实际行为，不代表报文有两种同样正确的解释。面对不合法输入，不能让每一跳各猜一次，再期待最终边界碰巧一致。

失步可以产生不同影响

完整的隐藏请求可能马上被后端处理，并不必然等待下一位受害者。另一些攻击留下不完整前缀，再与后续流量组合。响应队列污染只是可能后果之一；绕过路由过滤、缓存污染和未授权的后端请求，也可能在没有相同响应错配步骤时造成影响。实际后果取决于连接复用、路由、认证和应用行为，不能用一个实验情节概括全部攻击。

发现额外的后端请求时，应追溯具体字节和连接。仅靠数量不足，因为重试、健康检查、缓存和异步日志都可能让各层记录合理地不一致。后端出现没有对应边缘记录的请求，是调查线索，不是自动确证。应结合关联数据，并在可控实验中使用可辨认的合成请求，排除正常机制之后再判断边界是否被突破。

坏掉的样子

表面的请求头过滤可能漏掉协议转换时产生的歧义。HTTP/2 使用帧，不采用 HTTP/1.1 的 chunked 分界，但降级到 HTTP/1.1 又引入一次必须正确完成的序列化。对 HTTP/2 请求，Content-Length 必须与内容长度一致；无内容响应另有规则，因此不能说换成 HTTP/2 就不再存在任何相关长度检查。

端到端 HTTP/2 能避免部分降级特有的问题，却不是普遍免疫证明。应检查协议转换、统一拒绝畸形消息，并避免在不可恢复的组帧错误后继续复用连接。严格入口可以挡住某条具体攻击路径，即使另一组件仍然宽松；应按真实可达路径评估，不能断言只修一跳永远没有作用，也不能因为某一入口表现正确就忽略其他入口。

curl 显示 HTTP/2，只说明客户端这一段连接使用的协议，无法揭示 CDN 或反向代理后面的链路。类似地，两份响应可能只是正常回答了两个流水线请求。可靠评估必须展示每个组件如何归类字节，以及结果是否跨越原本的请求边界。状态码、计数和协议标签都提供线索，但单独一项无法证明整条代理链的行为。

相同合成字节呈现不相容边界算术。两请求流水线本身不是走私；真实解析器与连接行为仍未测试。

快速验证

保存为 framing_demo.py，执行 python3 framing_demo.py。离线模型在内存里构造字节串，计算两种刻意不一致的边界，并测试一种严格拒绝策略。不向服务器发送任何东西，不创建套接字，合成路径也不指向真实管理端点。Content-Length 根据实际正文计算，而不是复制一个难以复核的固定数字，从而使例子中的计数可以直接核对。

# An in-memory boundary model, not an HTTP parser or network probe.
followup = b'GET /synthetic-next HTTP/1.1\r\nHost: example.test\r\n\r\n'
body = b'0\r\n\r\n' + followup
head = (b'POST /upload HTTP/1.1\r\nHost: example.test\r\nContent-Length: '
 + str(len(body)).encode() + b'\r\nTransfer-Encoding: chunked\r\n\r\n')
wire = head + body
header_end = wire.index(b'\r\n\r\n') + 4
cl_boundary = header_end + len(body)
# This fixture has precisely one zero chunk and an empty trailer section.
te_boundary = header_end + len(b'0\r\n\r\n')
if wire[cl_boundary:] != b'' or wire[te_boundary:] != followup:
 raise RuntimeError('boundary expectations failed')
if cl_boundary == te_boundary:
 raise RuntimeError('the two interpretations must differ')


def reject_dual_framing(header):
 names = {line.split(b':', 1)[0].lower() for line in header.split(b'\r\n')[1:] if b':' in line}
 if {b'content-length', b'transfer-encoding'} <= names:
 raise ValueError('dual framing rejected')


try:
 reject_dual_framing(head)
except ValueError as error:
 print(error)
else:
 raise RuntimeError('ambiguous message accepted')

ordinary_first = b'GET /first HTTP/1.1\r\nHost: example.test\r\n\r\n'
ordinary_pipeline = ordinary_first + followup
first_boundary = ordinary_pipeline.index(b'\r\n\r\n') + 4
if ordinary_pipeline[first_boundary:] != followup:
 raise RuntimeError('ordinary pipeline example failed')
print('CL remaining bytes:', len(wire[cl_boundary:]))
print('TE remaining bytes:', len(wire[te_boundary:]))
print('ordinary pipeline: two intentionally separate requests')
print('PASS: different framing boundaries; dual framing rejected; pipelining distinguished')

按 Content-Length 解释时，剩余字节数是零；按这个固定 chunked 例子解释时，剩余部分是完整的五十二字节合成请求。严格策略拒绝两种字段并存。另一个正常流水线样本有意包含两个请求，不能因为二者同时出现就称为请求走私。成功运行时，PASS 只确认这些有限关系，不声称发现真实漏洞。本轮只核对未变的字节与保留记录，没有执行模型或连接代理。

这不是通用 HTTP 解析器。chunked 用例只有一个零长度块和空尾部区，头部检查也没有实现完整字段语法、重复头规则或协议转换。它在不接触线上服务的条件下说明边界分歧为何重要。集成测试仍需得到授权的隔离链路、真实解析器版本、连接生命周期观察，以及能证明歧义输入无法触发非预期后端操作的负面用例，不能把内存模型当作线上系统的安全报告。

来源

RFC 9112: HTTP/1.1，组帧优先级、中间组件处理、错误与持久连接，已核验 2026-10-15。
PortSwigger: HTTP request smuggling，解析分歧分类及其后果，已核验 2026-10-15。
RFC 9113: HTTP/2，帧内容、畸形消息与 Content-Length 一致性，已核验 2026-10-15。

JWT 带着签名与寿命

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

带签名的 JWT 携带一组声明，接收方可以检查它们的完整性，而不必先从会话表读取整枚令牌。便利并不等于保密，也不会自动完成授权或阻止重放。审阅时应先明确令牌格式和应用的验证契约，再分别测试边界。密码学验证成功，只是访问决策的一项输入，不能代替资源本身的权限判断。

签名保护完整性，并不提供保密性。紧凑 JWS 模型将密码学检查、应用策略与最终访问决策分开；时间窗不包含恰好到期的时刻。签名正确本身不能证明令牌适用。

带签名令牌只是 JWT 的一种形式

本文讨论以 JWS 表示的紧凑、带签名或消息认证码的 JWT：受保护头部、载荷、签名或认证码构成三个点分段。Base64url 可以逆向解码，并不提供保密性。但 JWT 也支持加密的 JWE 表示，因此“所有 JWT 都可读而且只有三段”并不准确。即使使用加密，也应减少个人信息，避免嵌入与当前用途无关的凭据。

HS256 用共享秘密计算 HMAC。每个持有秘密的验证方也能签发令牌，因此它不能证明究竟是哪一个持有者发出了令牌。非对称签名把签发与验证能力分开。无论采用哪种设计，都不能因为令牌附带了一把陌生密钥，就把它当作信任依据。可信签发者、密钥来源、允许算法和令牌种类需要一起配置。

验证是一份应用契约

实现可以先解析少量不可信数据，以定位已经配置的密钥，但在密码学验证及策略检查全部完成前，不能根据声明执行操作。把 kid 当作可信密钥集合内的标识，不允许它任意指定文件路径或网络下载地址。每把密钥必须绑定预期算法，不能让声称使用 HS256 的令牌把 RSA 公钥变成 HMAC 秘密。

除了主体和具体操作需要的权限，还要检查签发者与预期受众。发给另一个接口的真实令牌，在这里仍然不合适。不同令牌种类可能需要互斥的验证规则，防止一种凭据被替换成另一种。生产环境应采用维护良好的 JWT 库，并显式设置验证参数；下面的小模型只实现一个封闭的演示配置。

基础 JWT 规范并没有要求每枚令牌必须包含所有注册声明；哪些字段必需，由应用规范决定。短期访问令牌应要求并执行 exp 检查，存在 nbf 时也要限制提前使用。当前时间必须早于 exp，时钟容忍则应明确配置且有界。iat 记录签发时间，本身既不让令牌过期，也不替代 nbf。示例只接受整数时间，是比完整 NumericDate 定义更窄的本地策略。

坏掉的样子

过期令牌仍可能有完全正确的签名；反过来，时间戳再新也无法挽救错误签名。两种失败应分别测试，并覆盖恰好到达过期时刻的情况。对调用者统一返回令牌无效可能合理，但内部诊断仍需区分原因，同时不能把整枚令牌写进日志。先验证正常路径，才能避免把“全部拒绝”误判成安全实现。

过期时间限制重放窗口，却不是唯一的撤销机制。服务可以查询会话状态、令牌标识拒绝列表、账号策略或内省端点。这些方案都引入一致性与可用性要求。轮换签名密钥可能影响大量令牌，不能把它当作方便的单用户退出机制。单独加入 jti 字段既不会自动保存服务端数据，也不会自动完成吊销，相关状态和查询规则必须确实存在。

不要使用 Python 的 assert 执行认证检查，因为优化模式可能删除它们。声明类型也应明确验证，不能随意把字符串或布尔值转成时间戳。示例中可读的秘密不应成为部署后的签名密钥；HS256 需要足够强的秘密。这里每次运行生成三十二个随机字节，仅用于这一轮实验，程序结束后不再保存。

快速验证

保存为 jwt_check.py，分别执行 python3 jwt_check.py 与 python3 -O jwt_check.py。固定的合成时间让边界检查可重复，同时不改变机器时钟。所有数据都在内存里，不打印、不持久化、不发送令牌和密钥，也不会读取用户现有账号或环境凭据。

import base64
import hashlib
import hmac
import json
import re
import secrets

# Ephemeral fixture key, never a production credential.
KEY = secrets.token_bytes(32)
NOW = 1_800_000_000


def encode(raw):
 return base64.urlsafe_b64encode(raw).rstrip(b'=').decode('ascii')


def decode(value):
 if not re.fullmatch(r'[A-Za-z0-9_-]+', value):
 raise ValueError('invalid base64url')
 return base64.b64decode(value + '=' * (-len(value) % 4), altchars=b'-_', validate=True)


def issue(claims, algorithm='HS256'):
 head = encode(json.dumps({'alg': algorithm, 'typ': 'JWT'}).encode())
 body = encode(json.dumps(claims).encode())
 signed = f'{head}.{body}'
 signature = encode(hmac.new(KEY, signed.encode(), hashlib.sha256).digest())
 return f'{signed}.{signature}'


def verify(token, now):
 head, body, signature = token.split('.')
 header = json.loads(decode(head))
 if not isinstance(header, dict) or header != {'alg': 'HS256', 'typ': 'JWT'}:
 raise ValueError('unsupported header')
 expected = hmac.new(KEY, f'{head}.{body}'.encode(), hashlib.sha256).digest()
 if not hmac.compare_digest(expected, decode(signature)):
 raise ValueError('bad signature')
 claims = json.loads(decode(body))
 if not isinstance(claims, dict):
 raise ValueError('claims must be an object')
 if claims.get('iss') != 'fixture-issuer' or claims.get('aud') != 'fixture-api':
 raise ValueError('issuer or audience mismatch')
 if any(type(claims.get(k)) is not int for k in ('iat', 'nbf', 'exp')):
 raise ValueError('integer times required by fixture')
 if not claims['iat'] <= now or not claims['nbf'] <= now < claims['exp']:
 raise ValueError('outside time policy')
 if not isinstance(claims.get('sub'), str) or not claims['sub']:
 raise ValueError('subject required')
 return claims


def rejected(label, token, now=NOW):
 try:
 verify(token, now)
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


claims = {'iss': 'fixture-issuer', 'aud': 'fixture-api', 'sub': 'demo',
 'iat': NOW, 'nbf': NOW, 'exp': NOW + 60}
token = issue(claims)
if verify(token, NOW)['sub'] != 'demo':
 raise RuntimeError('valid token failed')
rejected('exact expiry', token, NOW + 60)
rejected('not yet valid', issue({**claims, 'nbf': NOW + 1}))
rejected('future issued-at', issue({**claims, 'iat': NOW + 1}))
rejected('wrong audience', issue({**claims, 'aud': 'other-api'}))
rejected('wrong issuer', issue({**claims, 'iss': 'other-issuer'}))
rejected('missing expiry', issue({k: v for k, v in claims.items() if k != 'exp'}))
rejected('boolean time', issue({**claims, 'exp': True}))
rejected('algorithm mismatch', issue(claims, 'none'))
head, body, signature = token.split('.')
forged_body = encode(json.dumps({**claims, 'sub': 'admin'}).encode())
rejected('tampered subject', f'{head}.{forged_body}.{signature}')
print('PASS: valid accepted; nine negative cases rejected')

两次调用都应打印九条拒绝结果以及 PASS。正常令牌首先建立成功路径，负面用例随后覆盖恰好过期、尚未生效、未来签发、错误受众、错误签发者、缺少过期时间、布尔时间、算法不匹配，以及保留原签名但改变主体。验证和测试失败都通过显式异常表示，因此优化模式不会把关键检查移除。

这是一段可执行的机制说明，不是完整 JWT 实现。它没有实现受众数组、重复成员处理、密钥发现与轮换、嵌套令牌、时钟容忍、大小限制、吊销与具体授权。生产库和应用仍需逐项审阅这些边界。通过这里的测试，只说明列出的局部契约成立，不代表整个身份认证系统已经得到认证。

来源

RFC 7519: JSON Web Token，JWT 表示与注册声明的语义，已核验 2026-10-15。
RFC 8725: JWT Best Current Practices，可信算法、密钥、签发者、受众与令牌替换，已核验 2026-10-15。
RFC 7518: JSON Web Algorithms，HMAC 密钥强度要求，已核验 2026-10-15。
Python: assert statement，优化模式会移除断言，已核验 2026-10-15。

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

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

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

绑定保护 SQL 语法边界，却不会禁用取值内部仍需解释的语言。例如，绑定后的 LIKE 模式仍把百分号与下划线当成通配符。入口究竟接收模式，还是字面子串，需要另行约定，必要时按该运算符的规则转义。正则、全文检索和业务授权同样具有绑定之后的语义，不能因为成功参数化就认为输入已经符合全部产品约束。

坏掉的样子

在 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-10-15。
Psycopg 预备语句，阈值、显式预备和会话生命周期，已核验 2026-10-15。
PostgreSQL 18 PREPARE，定制计划、通用计划和自动选择，已核验 2026-10-15。
PostgreSQL 18 模式匹配，LIKE 通配符与转义语义，已核验 2026-10-15。

Setuid 在 exec 时改变有效身份

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

Linux 可执行文件上的 setuid 位，可以在 exec 成功时把进程的有效用户 ID 改为文件属主的 ID。它不会把进程全部凭据都替换成属主的登录身份。特权辅助程序因此能够代表另一个账户完成受控操作，但输入处理和特权持续时间都会成为安全边界的一部分。模式位本身既不能证明身份转换已经发生，也不能证明这个辅助程序安全。

文件位与进程凭据分开观察

通常的 set-user-ID 转换会改变有效 UID，再将结果复制到保存的 set-user-ID；真实 UID 保持不变。组凭据是另一套状态：setuid 不会自动装入文件属主的附加组。Linux 还存在文件系统身份和能力集合，因此真实、有效与保存 UID 是有用的观察，却不是权限的完整描述。不能看到有效身份变成某个账户，就假设已经拥有该账户登录会话的全部上下文。

应检查实际部署的文件，不要推断整个发行版都采用同一权限。用于修改密码的特权程序，在容器或定制镜像里可能有不同安装方式。属主执行位位置的小写 s 表示同时具备 setuid 和属主执行位，大写 S 则表示存在 setuid 但没有那个执行位。两种显示都不能替代属主核验、目标文件核验，以及对真实启动上下文的检查。

执行环境可以抑制转换

Linux 文档列出了 no_new_privs、nosuid 挂载和被跟踪等条件，它们可能抑制特权转换；某些文档记录的组合也可能直接让执行失败。文件能力同样受到执行约束。不能为了让演示成功，就关闭这些保护。应确定目标路径与调用进程实际适用哪些政策，如实说明限制，而不是把受保护环境当作必须修复的故障。

Linux 忽略解释器脚本上的 set-user-ID 与 set-group-ID 位。因此，把原生辅助程序改成脚本并保留模式，不会保留原先的提权行为。给通用解释器增加特权也不是安全替代方案。特权程序另外启动的可执行文件，还可能主动重置凭据，所以运行独立的 id 命令，不一定忠实显示原辅助程序内部的身份。观测点必须与要验证的进程一致。

降权需要完整设计

setuid 系统调用不同于文件上的模式位。具有足够权限的调用者可以改变真实、有效和保存 UID；非特权调用者能够进行的转换范围更窄。若仍保留允许恢复的保存身份，seteuid 可以支持有效 UID 的可逆切换。无论哪种调用，都必须先检查返回值，再确认状态，不能因为进程原来拥有高权限，就假设降权调用不会失败。

去掉保存 UID 只是永久放弃权限的一部分。附加组、保留能力、已经打开的特权描述符、命名空间和后续执行路径，同样需要考虑。一条 setuid 调用不是通用降权配方，正确顺序取决于程序原有的凭据和资源。安全敏感的辅助程序需要针对设计进行审查，不能把文章里的身份概念直接复制成未经验证的安全实现。

坏掉的样子

带有 s 的模式显示可能掩盖被抑制的转换；另一方面，权限过大的辅助程序也可能通过不安全的路径搜索、用户选择的配置文件等接口泄露真实能力。动态加载器在安全执行模式下会限制危险环境变量，却不会替应用验证输入。应避免用 shell 字符串拼接命令，并明确辅助程序允许访问哪些文件、接收哪些参数和执行哪些操作。

能力机制可以缩小某项授予，例如只允许绑定特权端口，但不会让其他权限全部消失。账户已有的访问权和其他能力仍然存在，能力边界集合与 securebits 还会限制 root 行为。同样，命名空间内部的 root 不等于宿主 root，但映射到普通用户的权限仍然有实际作用。套接字激活可以交付已经打开的监听描述符，却不能免除接收请求的服务本身应承担的安全要求。

setuid 在文档规定条件下影响 exec 时的特定凭据。保留检查不执行目标，也不证明提权；当前运行仍待验证。

快速验证

在具备 Bash、GNU stat、util-linux findmnt、libcap getcap 和 Python 3 的 Linux 环境运行下面完整代码。它只读取一个已安装文件的元数据，以及新 Python 进程自己的凭据状态，不执行 passwd，不改变权限或身份，不挂载文件系统，也不创建命名空间。明确路径避免搜索选中另一个辅助程序，但分开的元数据读取不能原子地绑定之后实际执行的同一文件。本轮没有运行检查；应在可信测试环境启用断言，缺少依赖时不能删掉失败检查继续宣称完成。

BASH_ENV= bash --noprofile --norc <<'BASH'
set -eu
target=/usr/bin/passwd
test -f "$target"
stat -c 'mode=%A numeric=%a owner=%u group=%g path=%n' "$target"
findmnt --noheadings --output TARGET,VFS-OPTIONS --target "$target"
getcap -v "$target"
python3 - <<'PYTHON'
import os
from pathlib import Path

status = dict(line.split(':', 1) for line in
 Path('/proc/self/status').read_text().splitlines() if ':' in line)
uids = tuple(map(int, status['Uid'].split()))
gids = tuple(map(int, status['Gid'].split()))
assert uids[:3] == os.getresuid()
assert gids[:3] == os.getresgid()
assert len(uids) == len(gids) == 4
for key in ['Uid', 'Gid', 'Groups', 'NoNewPrivs', 'CapEff', 'CapBnd']:
 print(f'{key}:{status[key]}')
print('PASS: inspected metadata and current credentials; target not executed')
PYTHON
BASH

输出应包含实际模式、数字属主和属组、所在文件系统的挂载选项，以及目标的文件能力列表。没有文件能力，不等于没有 setuid 位；有 setuid 位，也不代表一定存在文件能力。Python 断言把 UID 与 GID 的前三个状态字段分别和对应系统调用结果比较；第四个字段代表文件系统身份。观察当前检查进程的状态，也不能推导尚未运行目标的执行结果。

最后的通过提示只证明这项只读检查完成。不同主机上的值可以不同，实验没有硬编码预期 root 身份，也没有演示提权、不可逆降权或抗攻击能力。这些结论需要另外获准的临时安全测试，以及真实辅助程序内部的观察，不能通过削弱宿主保护来取得一个看起来成功的结果。

来源

Linux execve，有效身份变化、保持不变的凭据及抑制条件，已核验 2026-10-15。
Linux credentials，附加组与文件系统身份，已核验 2026-10-15。
Linux setuid，特权与非特权转换及错误检查要求，已核验 2026-10-15。
Linux seteuid，允许的有效身份转换，已核验 2026-10-15。
Linux capabilities，能力限制与凭据交互，已核验 2026-10-15。
Linux 动态加载器，安全执行模式的环境限制，已核验 2026-10-15。
Linux proc_pid_status，凭据与能力状态字段，已核验 2026-10-15。

在可信位置原子创建临时文件

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

共享临时目录是其他用户也可能写入的命名空间，并不意味着里面每个文件都公开可读；内容访问仍受文件权限约束。真正危险的假设，是以为选定一个路径，就已经拥有这个名字对应的对象。应原子地创建新对象，并继续使用返回的句柄，而不是信任一个可预测名字，或先检查它不存在、稍后再打开。

名字归属与内容访问是两回事

Linux 的 /tmp 常用模式 1777，即宽松的目录写入、搜索权限，加上 sticky 位。sticky 限制其他用户删除或重命名目录项，却不让现有文件自动保密，也不提前保留尚未创建的名字。文件属主、目录属主、能力及其他访问控制仍然重要。应检查实际环境，不能假定所有操作系统都采用同一路径、挂载方式和权限。

普通写入打开可能跟随预先存在的符号链接。O_CREAT|O_EXCL 拒绝已经存在的最后一个路径名称，包括符号链接。O_NOFOLLOW 则拒绝最后一段是符号链接的情况，但单独使用时不会拒绝既有普通文件，也不保护所有祖先目录。这些是不同契约。应使用可信父目录和适当的临时文件接口，不能把一个标志当成通用路径安全方案。

创建模式也只在真正新建文件时生效。以 O_CREAT 和模式 0600 打开已有文件，不会收紧它原先的权限。随机名字降低碰撞概率，但安全性质来自排他创建，而不只是字符串看起来难以猜测。只生成名字的接口仍留下一段空隙，其他进程可以在真正创建之前占用该名字，因此先检查再创建也不能消除竞争窗口。

位置设置不等于隔离

Python 的 tempfile.mkstemp 安全地创建并打开文件，调用方负责关闭和删除。TemporaryDirectory 提供受限目录和正常退出时的清理。TMPDIR 影响位置选择，却不会自己创建私有目录，也不验证隔离策略。Python 会缓存默认目录选择；如果操作必须使用某个位置，应明确传入 dir=，不要依赖运行中修改环境变量来重新选择。

systemd 的 PrivateTmp= 可以给服务单独的临时文件命名空间，但它改变共享行为，并有平台与 unit 条件，不等同于设置一个环境变量。服务分别使用独立命名空间时，不能依赖跨服务的 /tmp 路径通信。下方本地实验不会启用或验证 systemd 隔离，也不能据此宣称部署已经具有相同隔离边界。

tmpfs 随使用量分配空间，在可用且被允许时可以使用交换空间。没有指定大小时，默认容量上限是物理内存的一半；这是上限，不是挂载时预留的内存。数据分配额度和 inode 数量都可能分别阻止后续工作。/tmp 也不一定挂在 tmpfs 上，因此容量监控应依据实际挂载与负载，不能把目录名字直接当成存储类型。

坏掉的样子

可预测名称可能把写入导向别处，也可能复用权限不符合预期的对象。只在成功路径清理，会在普通异常之后遗留文件。上下文管理器和 finally 能帮助这些路径，但无法保证在 SIGKILL 或机器崩溃后执行。应设计遗留文件清理，避免删除其他进程仍在使用的内容，也不要让临时存储承载唯一的持久副本。

共享容量上限可以让一个写入方影响另一个。创建和后续写入可能在不同阶段失败，成功创建空文件并没有为最终内容保留空间。需要限制暂存用量，并按数据寿命与大小选择文件系统。持久应用状态目录不是一次性构建输出的通用去处；位置、清理责任与存续要求应一起确定，而不是空间不足时随意迁移。

原子临时文件：机制与证据边界。

快速验证

把程序保存为 temp_contract.py，在 Linux 上用 Python 3.11 或更新版本执行 python3 temp_contract.py，并确认临时父目录可信、断言开启。不得使用 -O 或 PYTHONOPTIMIZE，因为优化模式会连同断言删去其中的 os.write 调用。实验只在单一身份下创建自己的文件，不修改现有权限或其他用户的对象。

from pathlib import Path
from tempfile import TemporaryDirectory, mkstemp
import errno
import os
import stat

with TemporaryDirectory(prefix="temp-contract-") as directory:
 root = Path(directory)
 target = root / "target"
 target.write_text("original")
 predictable = root / "predictable"
 predictable.symlink_to(target)
 with predictable.open("w") as stream:
 stream.write("followed")
 assert target.read_text() == "followed"

 for flags, expected in [
 (os.O_WRONLY | os.O_CREAT | os.O_EXCL, errno.EEXIST),
 (os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW, errno.ELOOP),
 ]:
 try:
 fd = os.open(predictable, flags, 0o600)
 except OSError as error:
 assert error.errno == expected, error
 else:
 os.close(fd)
 raise AssertionError("pre-existing symlink was accepted")
 assert target.read_text() == "followed"

 before = stat.S_IMODE(target.stat().st_mode)
 fd = os.open(target, os.O_WRONLY | os.O_CREAT, 0o600)
 try:
 assert stat.S_IMODE(os.fstat(fd).st_mode) == before
 finally:
 os.close(fd)

 fd, name = mkstemp(prefix="owned-", dir=root)
 try:
 mode = stat.S_IMODE(os.fstat(fd).st_mode)
 assert mode & 0o077 == 0
 assert os.write(fd, b"synthetic data") == 14
 os.lseek(fd, 0, os.SEEK_SET)
 assert os.read(fd, 14) == b"synthetic data"
 finally:
 os.close(fd)
 os.unlink(name)
 assert not Path(name).exists()
 print("ordinary open followed link; EXCL and NOFOLLOW rejected it")
 print("existing mode preserved:", oct(before), "; temporary mode:", oct(mode))
assert not root.exists()
print("descriptor round trip and normal-exit cleanup passed")

普通打开先改变符号链接指向的文件。之后两个带保护标志的打开分别返回预期错误，并保持目标内容不变。再次打开现有目标时，其测得的权限保持原样；实验刻意不假定进程采用哪种 umask。安全创建的临时文件没有组和其他用户权限位，通过返回的描述符完成写入、定位与读取的完整往返。

旧文报告 Python 3.12.14 运行通过，模式为 0644 和 0600，但这里没有建立对应的留存执行记录；本次也未运行文件系统示例。源码检查普通结束时的清理，没有覆盖跨用户攻击、并发竞争、突然终止、tmpfs 耗尽、网络文件系统或命名空间隔离。打印的总结不能替代这些测试，更不能从单身份样本推断实际部署已经具有全部保证。

来源

Linux open(2)，O_CREAT 模式应用、O_EXCL 及末段 O_NOFOLLOW 语义，已核验 2026-10-15。
Python 3.12 tempfile，mkstemp、TemporaryDirectory、默认位置缓存与清理边界，已核验 2026-10-15。
Linux tmpfs 文档，动态分配、交换空间及独立的容量和 inode 上限，已核验 2026-10-15。
systemd.exec(5)，PrivateTmp= 共享边界与实现前提，已核验 2026-10-15。
Linux unlink(2)，目录写入搜索要求与 sticky 所有权限制，已核验 2026-10-15。
Python assert 语句，优化模式会移除断言及其表达式，已核验 2026-10-18。

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

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 探针时，六份响应都会返回二百状态，说明只读响应头不能替代渲染验证。本例只验证一个浏览器中的单层嵌入，没有验证真实账号操作或全部嵌套集成。发布前还应让合法路径与被拒父来源经过实际代理和内容分发层，确认目标子响应仍然保有预期策略。

文章的单层浏览器实验中，六份子响应均为 HTTP 200，但只有 open、csp-allow、meta 与 frame-src 渲染。csp-allow 的强制祖先策略允许父来源，并优先于 X-Frame-Options DENY。实际嵌套集成仍需单独验收。

来源

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 不等于必然存在漏洞；需要先识别真正使用的库、已启用功能、资源解析器和后续处理步骤，才能判断输入究竟能够触发什么操作。

外部访问与内部展开不是一回事

外部解析实体可以用系统标识符指向资源。应用启用解析、进程又有能力访问时，读取文档便可能加载它。把内容反射到响应中只是泄露的一种形式；即使响应没有带回资源，向外发出的请求本身仍可能产生影响。访问范围同时受到解析策略、文件权限、网络控制和目标服务认证的限制，并不是一个 URL 就能保证拿到任意内部秘密。

内部实体则可以完全在文档中展开，不需要文件或网络。在保护不足的解析器中，重复嵌套替换可能消耗大量资源，这与 XXE 是不同问题。一个有明确上限的一千字符示例，只证明发生了替换，不能证明现代解析器允许无限放大。实体递归引用自身不符合 XML 规则，受支持的实现还可能在内存耗尽之前就拒绝过度放大，不能把所有解析器都描述成必然陷入死循环。

在解析开始前确定政策

输入格式不需要 DTD 时，应使用解析器支持的策略或回调拒绝文档类型声明。同时按具体实现关闭不需要的外部普通实体、参数实体和外部子集。库与版本的默认行为不同，仅禁止网络访问可能仍允许读取本地文件；只做 schema 校验，也可能已经晚于危险的初次解析。应检查实际入口怎样构建解析器，而不是在配置文件中找到一个相似名字就认为已经完成防护。

确实需要外部资源时，只把明确批准的标识映射到受控资源。schema 导入、XInclude 与转换器要单独审阅，XXE 开关未必控制这些加载器。还要限制字节数、嵌套深度与资源消耗，并维护解析库版本。一个短包装函数不可能自动抵御全部畸形输入、压缩炸弹或后续处理风险，政策边界应如实写明。

坏掉的样子

只在原始字节中搜索 ASCII 的 DOCTYPE 拼写，可能漏掉 UTF-16 之类编码后的声明；简单文本搜索又会误杀包含该字样的普通注释。应让理解编码和语法的解析器识别结构，再在声明边界执行政策。成功拒绝一条熟悉攻击字符串，不等于覆盖了入口接受的所有编码，也不等于找到了所有可能读取资源的路径。

SVG 上传可能进入服务器端 XML 解析器或图像转换器。该环节的配置决定是否加载外部引用，不能因为文件是 SVG，就声称每种浏览器都会自动解析外部实体。应检查预览、导入以及后续重解析的每一环；第一个解析器安全，不会替第二个开启不同加载器的组件提供保护。测试对象应当是实际管线，而不是只看文件扩展名。

启用断言的原样 Expat 夹具支持有界解析行为，不证明外部资源访问、全部处理器与编码，也不保证通用安全。

快速验证

保存为 xxe_probe.py，使用受维护的 Python 3 执行 python3 xxe_probe.py。须启用断言，不使用 -O 或 PYTHONOPTIMIZE：优化模式会跳过 assert 内的参数实体设置调用和正例检查。实验采用 Expat 回调、固定内存字节与小规模限制，不配置打开文件或发起网络请求的资源加载回调。拒绝声明中的路径与域名只是测试输入，不会访问对应资源，也不会读取真实系统文件。

from xml.parsers import expat

MAX_BYTES = 4096
MAX_DEPTH = 32


def parse_without_dtd(data):
 """Bounded demonstration policy, not a general XML security library."""
 if not isinstance(data, bytes):
 raise TypeError("supply original encoded bytes")
 if len(data) > MAX_BYTES:
 raise ValueError("input too large")
 parser = expat.ParserCreate()
 text = []
 depth = 0

 def reject(*args):
 raise ValueError("DTD and entity declarations are disabled")

 def start(name, attrs):
 nonlocal depth
 depth += 1
 if depth > MAX_DEPTH:
 raise ValueError("too deeply nested")

 def end(name):
 nonlocal depth
 depth -= 1

 parser.StartDoctypeDeclHandler = reject
 parser.EntityDeclHandler = reject
 parser.ExternalEntityRefHandler = reject
 assert parser.SetParamEntityParsing(expat.XML_PARAM_ENTITY_PARSING_NEVER)
 parser.StartElementHandler = start
 parser.EndElementHandler = end
 parser.CharacterDataHandler = text.append
 parser.Parse(data, True)
 return "".join(text)


internal = ('<!DOCTYPE r [<!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;">]><r>&c;</r>')
# A bounded baseline: ordinary internal expansion, not a resource-exhaustion test.
baseline = expat.ParserCreate()
chunks = []
baseline.CharacterDataHandler = chunks.append
baseline.Parse(internal.encode(), True)
assert len("".join(chunks)) == 1000
assert parse_without_dtd(b'<r>hello &amp; goodbye</r>') == 'hello & goodbye'
assert parse_without_dtd(b'<r><!-- literal <!DOCTYPE is only a comment -->ok</r>') == 'ok'
external = '<!DOCTYPE r [<!ENTITY e SYSTEM "file:///not-read-by-this-demo">]><r>&e;</r>'
network = '<!DOCTYPE r SYSTEM "https://example.invalid/never-requested"><r/>'
svg = '<!DOCTYPE svg [<!ENTITY e "text">]><svg>&e;</svg>'
rejected = []
for name, payload in [
 ("internal", internal.encode()), ("file", external.encode()),
 ("external-subset", network.encode()), ("svg", svg.encode()),
 ("utf16-dtd", external.encode("utf-16")),
 ("oversize", b'<r>' + b'x' * MAX_BYTES + b'</r>'),
 ("depth", b'<r>' * (MAX_DEPTH + 1) + b'</r>' * (MAX_DEPTH + 1)),
]:
 try:
 parse_without_dtd(payload)
 except ValueError:
 rejected.append(name)
 else:
 raise AssertionError(f"policy accepted {name}")
assert len(rejected) == 7
try:
 parse_without_dtd(b'<r>unfinished')
except expat.ExpatError:
 pass
else:
 raise AssertionError("malformed XML accepted")
print("Expat:", expat.EXPAT_VERSION)
print("PASS: ordinary text/comment accepted; seven policy cases and malformed XML rejected")

另行执行的完整英文、中文围栏及独立重跑，已在 Python 3.12.14、Expat 2.8.3 且启用断言时通过；源码复核者没有执行这些程序。夹具会打印链接的 Expat 版本。基线把有限内部实体链展开为恰好一千字符。限制解析器允许普通文字、预定义的与号实体以及无害注释；它拒绝内部声明、文件实体、外部子集、SVG DTD，也拒绝同一文件声明的 UTF-16 编码形式。这里证明的是解析政策生效，而不是敏感文件曾经被成功读出。

另外两个案例分别超过四千零九十六字节与三十二层嵌套限制；语法不完整的 XML 必须引发解析器语法异常。这些检查区分 ValueError 与解析器语法异常，却没有断言具体由哪个政策分支拒绝。UTF-16 对照尤其说明，限制发生在识别编码之后的结构边界，而不是依赖某一种 ASCII 字节模式。所有输入都很小，不需要真的制造内存耗尽来验证判断分支。

DTD 回调会先拒绝，现有用例没有独立覆盖每个处理器或所有编码。这是一项有边界的解析实验，不是对文件、网络目标或上传服务的利用测试。它不验证 schema 处理、转换器、后续重解析、压缩请求处理或生产资源隔离。处理不可信文档时，应使用受维护的加固 XML 设施，并让实际应用入口重新跑相应政策测试。示例通过不能替代整条输入链的审查，也不能推导所有下游组件采用了同一套配置。

来源

Python 3.12 Expat 接口，声明回调、参数实体策略与编码输入，已核验 2026-10-15。
Python XML 安全，与库和版本相关的漏洞边界，已核验 2026-10-15。
OWASP XXE 防护，按解析器限制外部资源，已核验 2026-10-15。
W3C XML 1.0，实体、文档类型与禁止递归引用，已核验 2026-10-15。
Python assert statement，优化执行省略断言代码，包括带有副作用的表达式，已核验 2026-10-18。

客户端证书认证私钥控制能力

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

双向 TLS 在验证服务器身份的同时，也认证客户端是否能够使用证书对应的私钥。但它并不天然证明某台物理设备的身份。可复制的软件私钥可以被带到别处使用；硬件绑定和设备证明需要额外机制。注册和签发策略可以把密钥关联到设备，但 TLS 本身不会自动建立或验证这项硬件关联。

mTLS 认证私钥控制能力。应用根据已验证身份另行授权，因此有效凭据仍可能得到 403。物理设备身份与凭据生命周期还需要额外控制。

完成认证仍然需要授权

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 上全部断言通过的结果；本轮没有重跑该 Go 夹具。这验证了真实双向 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

服务端请求伪造会让服务器发出由攻击者选择或影响的请求。缩略图服务、导入器、Webhook 测试器或文档渲染器，可能到达请求用户无法直接访问的目标。服务器贡献的是自己的网络位置，以及这条具体抓取路径实际附带的凭据；取一个地址并不意味着进程可见的所有账号凭据都会自动加入请求。评估风险应从真实连接与认证方式开始。

先看清委托了什么权限

内部服务、回环管理端点和云元数据服务，在可达时都是重要目标。后果取决于认证、响应是否可见、允许的方法和网络策略。盲 SSRF 即使不返回目标正文，也可能触发动作或暴露时间信息。不能只凭功能名称给严重程度排位，而应确认它能联系什么，以及一次联系可以产生什么结果，尤其注意有副作用的内部接口。

在 EC2 上，实例附加了角色且相关访问被允许时，角色凭据可能通过元数据提供。角色名称列表与具体角色的凭据文档是不同请求。这些临时凭据代表该角色获得的权限，并不等于无限 AWS 访问，也不保证是实例上每个应用实际采用的凭据。目标没有角色、端点不可达或权限不足时，风险形态会不同，需要依照部署事实判断。

IMDSv2 要求先用 PUT 获取令牌，再在后续元数据请求中提供令牌。强制使用它可以挡住简单、没有认证头的单次 GET 路径，但不能解决能够控制必要方法和请求头的任意 SSRF。应结合最小权限角色与有效网络限制。元数据还可能通过 IPv4，以及启用并受支持时的 IPv6 到达；检查时不能只处理一种地址族。

解析、解析域名，并保留已检查的目标

允许列表应描述功能真正需要的目标。如果可以，接收资源标识而不是任意 URL。否则，应使用与 HTTP 客户端解释一致的解析器，限制协议、主机和端口。不需要的 userinfo 和歧义语法应拒绝，不能因为字符串某处出现了允许的域名，就认定目的地已经获准。解析函数有返回值，也不等于输入符合业务策略。

例如，位于 @ 前面的 trusted.example 是用户信息，不证明目标主机可信。旧式数字 IPv4 写法在不同解析器和解析库中可能有不同解释。IPv6 回环是 ::1，并不是 127.0.0.1，所以搜索一个固定字符串远远不够。一个运行时的解析结果，也不能直接成为另一个客户端行为的可移植保证。验证应围绕实际使用的组件版本建立。

解析允许的域名后，要按照预期网络策略检查返回的全部地址。只允许公网抓取时，应拒绝回环、私有、链路本地、多播以及其他禁止范围。地址库和登记规则会演进，因此要测试真正部署的版本。全球可路由也不代表目标是获准的、可信的或无害的服务；地址分类与业务允许列表解决的是不同问题，应同时保留。

坏掉的样子

先检查 DNS，再让客户端自行重新解析，会留下检查与使用之间的空隙。应通过受支持的传输机制固定经过验证的连接地址，同时保留原本的 TLS 主机名、证书校验和 HTTP authority。代理可能独立解析；因此须检查真实出口路径、重试与回退连接，不能假设一次本地预检控制了它们。固定地址也不能以关闭证书验证为代价。

重定向引入新目标。没有需要就关闭；需要时则在跟随每一跳之前重新执行验证，包括解析与地址选择。已经允许的域名不能为任意 Location 背书。出口策略是独立的限制层，应与工作负载需要的服务相符，并覆盖相关地址族。入口允许列表、解析检查和网络隔离相互补充，不能把其中一个配置项当成万能保证。

返回二百并不单独证明 SSRF，返回四百类错误也不能证明禁止的请求没有发生。应用可能包装错误、返回缓存，或者先联系目标再拒绝。应通过可控观察端点确认实际请求，区分响应处理和网络行为。不要为了让示例显得可信，就探测真实元数据凭据；安全测试应该使用合成响应，并明确获得对测试目标的授权。

批准数据不证明实际传输。策略须对应真实抓取路径，包括解析、重定向、重试、代理与 TLS 身份。

快速验证

保存为 ssrf_policy.py，执行 python3 ssrf_policy.py。这个刻意收窄的离线策略用传入的地址快照代替 DNS。公网地址只是输入值，程序不会联系它。所有决定都发生在内存中，不使用凭据、不创建套接字、不访问元数据，也不更改网络控制。这样可以验证拒绝规则，而不把真实服务暴露给实验请求。

import ipaddress
from urllib.parse import urlsplit

ALLOWED = {'cdn.example.test'}


def approve(url, addresses):
 # Deliberately narrow input language for this offline model.
 if any(ord(c) <= 32 or ord(c) >= 127 for c in url) or '\\' in url:
 raise ValueError('unsupported URL characters')
 parts = urlsplit(url)
 if parts.scheme != 'https' or parts.hostname not in ALLOWED:
 raise ValueError('scheme or host denied')
 if parts.username is not None or parts.password is not None or parts.fragment:
 raise ValueError('userinfo or fragment denied')
 if parts.port not in (None, 443):
 raise ValueError('port denied')
 if not addresses:
 raise ValueError('empty resolution')
 checked = []
 for text in addresses:
 address = ipaddress.ip_address(text)
 if '%' in text or address.is_multicast or not address.is_global:
 raise ValueError('non-public address denied')
 checked.append(str(address))
 return parts.hostname, tuple(checked)


def rejected(label, url, addresses):
 try:
 approve(url, addresses)
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


url = 'https://cdn.example.test/logo.png'
# Address values only. There is no DNS lookup, socket, or HTTP request.
public_snapshot = ['8.8.8.8']
name, pinned = approve(url, public_snapshot)
rejected('userinfo on allowed host', 'https://attacker@cdn.example.test/logo.png', public_snapshot)
rejected('userinfo host confusion', 'https://cdn.example.test@169.254.169.254/', public_snapshot)
rejected('decimal host', 'https://2130706433/', ['127.0.0.1'])
rejected('loopback IPv6', 'https://[::1]/', ['::1'])
rejected('link-local answer', url, ['169.254.169.254'])
rejected('mixed answers', url, ['8.8.8.8', '127.0.0.1'])
rejected('multicast answer', url, ['224.0.0.1'])
rejected('redirect destination', 'https://internal.example.test/', ['10.0.0.1'])
rejected('changed DNS answer', url, ['127.0.0.1'])
if pinned != ('8.8.8.8',) or name != 'cdn.example.test':
 raise RuntimeError('approved snapshot changed')
print('PASS: public fixture accepted; nine denied cases; approved address snapshot retained')

预期打印九条拒绝结果和 PASS。允许的合成域名加一个公网地址建立成功路径。允许主机上的用户信息、用户信息造成的主机混淆、允许列表外的数字与 IPv6 主机、链路本地和混合答案、多播、重定向主机，以及改变后的 DNS 答案都会失败。此前批准的地址元组保持不变。数字与 IPv6 URL 先被主机允许列表拒绝，因此这两项并未独立测试 IPv6 地址分类分支。本轮源码复核没有执行示例。

这里测试的是决策与数据保存，不是生产抓取实现。它没有执行 DNS、传输层固定、代理、TLS、真实重定向或响应大小限制，因此通过测试不能证明某个 HTTP 库确实连接了批准地址。集成测试仍须验证这些连接关系，并覆盖超时和资源上限，使用隔离目的地和合成响应，避免把局部规则通过误写成整条网络路径已得到证明。

来源

OWASP: SSRF Prevention Cheat Sheet，预期目标、地址验证与重定向，已核验 2026-10-15。
AWS: Instance Metadata Service，IMDSv2 令牌请求与端点行为，已核验 2026-10-15。
RFC 3986: URI Generic Syntax，authority、userinfo 与主机语法，已核验 2026-10-15。
Python: ipaddress，地址分类与版本变化，已核验 2026-10-15。

CSRF 检查请求到底来自哪里

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

浏览器可能为攻击者触发的请求附带会话 Cookie。CSRF 防御检查请求上下文是否可信，却不能证明用户真的看过或有意批准某个动作。

本图描述文章的服务端夹具，不是浏览器实测。SameSite 只减少 Cookie 发送；可信上下文不证明用户意图，XSS 与认证仍需独立防护。

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

令牌把动作与来源绑定

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

SameSite 是浏览器护栏

SameSite=Strict 不在跨站请求中发送该 Cookie；显式设置 Lax 时，使用安全方法的顶层导航仍可携带它。这些限制减少凭据被跨站运送的机会，但本设计仍要求服务端校验令牌。同站范围大于同源，浏览器支持和请求上下文也会影响结果。示例采用服务端保存的同步令牌，而非双提交 Cookie；两种模式不能仅因为都叫令牌，就混为同一种实现。源内脚本注入可以替用户发出合法上下文中的请求，所以还需单独防御 XSS。

把 Origin 当作来源信号

请求存在 Origin 时先检查它；缺失时，服务端可以检查 Referer 的来源部分。两个字段都可能缺失，Origin 也可能是字面值 null，不能把这些情况当作同源证据。本夹具有意同时要求有效令牌和可信来源信号，缺一即拒绝；实际兼容策略也应明确写出，不能默默跳过整个保护。应比较完整的协议、主机与端口，不能只匹配域名前缀，防止相似域名通过。

Sec-Fetch-Site 提供额外浏览器上下文，但表示站点关系，不等于完整来源匹配。命令行客户端可以伪造这些首部，来源检查针对的是浏览器被诱发的请求，不是用户认证或人类意图证明。反过来说，curl 能伪造首部，也不意味着攻击页面能够让受害者浏览器任意发送它们。不同威胁模型应分别理解，不能据此撤销浏览器侧防护。

坏掉的样子

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

第二种是显式跨站 Cookie 没有配套保护。SameSite=None; Secure 允许跨站传送，改变状态的接口仍需其他 CSRF 防御。现代浏览器会拒绝缺少 Secure 的 None Cookie，不能把它描述为普遍放行；旧版行为也不能用作安全保证。开发环境为了联调开放跨站传送，上线后忘记核对令牌和来源规则，仍可能留下真实攻击路径。

第三种是缺失令牌时跳过校验。处理器仅在参数存在时比对,接口路径干脆跳过校验,或者把令牌放在查询串里,经引用头与日志到处扩散,攻击者拿到就能重放。源内脚本注入也可能窃取或使用令牌，这是另一个必须防御的边界。正确做法是缺失与不匹配一律拒绝,且只接受请求体或专用首部里的值。

第四种是子域信任过大。站点隔离比的是站点而非来源,受控子域与主站可能同站；若它能设置父域 Cookie，就可能干扰会话处理或为天真的双提交方案种下已知令牌。优先使用主机范围的会话 Cookie，并拒绝含义不明的重复 Cookie。登录接口若不做同样的双校验,还会留下登录伪造,攻击者用自己的账号让受害者登录,后续操作全部记在攻击者账下。每种失败里凭据都是有效的,凭据都不足以独立说明请求合法。

快速验证

把下面程序存为 csrf_probe.py,运行 python3 csrf_probe.py。它只用标准库模拟服务端关卡:方法必须是大写的 POST,令牌必须与会话值一致,来源信号必须吻合。不起网络服务,不碰浏览器,各组用例可独立执行。固定令牌只是测试数据，真实服务必须为会话生成不可预测的值。

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):
 """模拟服务端关卡：仅 POST 变更、令牌与来源信号必须同时通过。"""
 if method != "POST":
 return 405, "state change requires POST"
 if not isinstance(token, str) or not token.isascii() or not compare_digest(token, SESSION_TOKEN):
 return 403, "missing or wrong token"
 if origin:
 if origin != EXPECTED_ORIGIN:
 return 403, "origin mismatch"
 elif referer:
 base = urlsplit(EXPECTED_ORIGIN)
 try:
 seen = urlsplit(referer)
 except ValueError:
 return 403, "referer mismatch"
 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")

check(decide("POST", "", "", SESSION_TOKEN),
 (403, "no origin signal"), "missing origin signal")
check(decide("POST", "https://evil.bank.example", "", SESSION_TOKEN),
 (403, "origin mismatch"), "same-site subdomain")
check(decide("POST", EXPECTED_ORIGIN, "", "令牌"),
 (403, "missing or wrong token"), "non-ASCII token")
check(decide("POST", "", "https://[", SESSION_TOKEN),
 (403, "referer mismatch"), "malformed referer")

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

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

补充用例还拒绝缺失来源、同站子域、非 ASCII 令牌与格式错误的引用地址。这个夹具只验决策逻辑，不验浏览器是否真的按站点隔离丢弃凭据，也不验传输加密与会话过期。其字面比较刻意没有实现 URL 规范化，因此显式写出等价默认端口也可能被拒绝。上线前应在隔离环境里使用虚构账号和真实浏览器，测试实际路由的跨站与同站行为，检查请求头、拒绝结果及业务副作用。

来源

MDN：跨站请求伪造（CSRF），攻击形态、令牌与 SameSite 防御，已核验 2026-10-19。
OWASP：跨站请求伪造防护速查表，关于令牌与 SameSite 的指引，已核验 2026-10-19。
RFC 6265：HTTP 状态管理机制，基础 Cookie 作用域；此 RFC 不定义 SameSite，已核验 2026-10-19。

Kubernetes Secret 需要明确的访问边界

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

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

Secret 的边界既包括直接读取者，也包括能够创建消费者的主体。窄投射只限制这一次交付，不一定限制创建者。轮换还需要交付、重载和签发方验证。此图是概念示意，本轮没有执行集群实验。

编码与保护处于不同层次

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

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

Secret 适合小规模值。Kubernetes v1.34.0 将解码后的 data 值总和限制为一 MiB；这项检查不计算 Base64 表示或元数据的大小；请求与元数据仍有各自的限制。应只挂载需要的键，并只交付给真正需要它的容器。文件模式可以缩小工作负载内部的读取范围，却不能替代 API 授权或对创建工作负载权限的控制。环境变量注入也有暴露范围和生命周期方面的取舍，应根据应用需求选择，不能默认它一定比文件更安全。

坏掉的样子

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

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备可丢弃的 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-10-15。
Kubernetes: Good practices for Secrets，加密、最小权限与工作负载访问，已核验 2026-10-15。
Kubernetes: RBAC authorization，资源操作、角色绑定和命名空间范围，已核验 2026-10-15。
Secret validation (v1.34.0)，ValidateSecret 累加解码后的 data 值字节数，再比较 MaxSecretSize，已核验 2026-10-18。

安全 · XB 现场笔记

SSH 代理转发的权限边界

远端拿到的是能力

转发由生效配置决定

缩小委托范围

坏掉的样子

快速验证

来源

OCSP 装订按客户端策略交付状态证据

传递证据并不转移信任责任

先核对支持范围，再决定启用

坏掉的样子

快速验证

来源

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

把设置放在正确层级

坏掉的样子

快速验证

延伸阅读

来源

证书透明度让签发可被观察

承诺不等于包含证明

坏掉的样子

快速验证

延伸阅读

来源

SYN Cookie 在队列溢出时作答

两个队列，两种症状

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

Cookie 装不下的东西

坏掉的样子

快速验证

来源

TLS ECDHE 的前向保密边界

两类密钥承担不同职责

坏掉的样子

快速验证

延伸阅读

来源

内核把设备噪声转成密钥

区分采集与输出

选择会等待初始化的接口

坏掉的样子

快速验证

用直接证据调查身份复用

来源

镜像签名把摘要绑定到受信任签名者

摘要是身份，标签是指针

标签字符串不能绑定镜像内容

校验才是控制，签名不是

坏掉的样子

快速验证

来源

OAuth 授权码用码换令牌

公共客户端也能使用授权码流程

把兑换绑定到原始请求

坏掉的样子

快速验证

延伸阅读

来源

请求走私把代理链路带偏

同一字节流，不相容的边界

失步可以产生不同影响

坏掉的样子

快速验证

来源

JWT 带着签名与寿命

带签名令牌只是 JWT 的一种形式

验证是一份应用契约

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

在真实部署中观察复用

来源

Setuid 在 exec 时改变有效身份

文件位与进程凭据分开观察