北京
一条403拒绝日志，不是新漏洞，也不是越狱攻击。但里面躺着一个完整的会话令牌。192.0.2.10在9月3日早上发来一个POST请求，目标是/admin/users，WAF回了403。日志里Cookie字段写着CANARY_SESS_7f3a——一个活着的会话凭证。
我把这条日志存进了fixtures/negative.log。过去我会把类似的行丢给聊天模型，问"这个探测想干什么"。直到我重新看了一眼Cookie字段：WAF手里已经有一个会话令牌，我自己的终端里也有一份。为什么还要把第三份副本交给一个磁盘不由我轮转的模型服务商？
我定下一条不变量：如果拒绝日志里还带着CANARY_SESS，它就绝不能变成提示词。
拒绝日志本身就是秘密仓库
你已经拒绝把.env文件粘进聊天框。但你会用同样的标准对待$http_cookie吗？边缘日志是为事件响应设计的，不是为模型输入设计的。一次混乱的故障中，有人往log_format里加了$http_authorization、$http_cookie或$request_body。下一条403看起来信息量很大——因为它确实还握着一个凭证。
模型要判断一次探测，根本不需要受害者的Cookie。它需要的是方法、路径形状、状态码和触发的规则。其余部分，只是让另一个读者看到了你没能隔离的秘密。
一条403的五个读者
我把信任边界画在日志行上，而不是画在模型供应商那边。浏览器到WAF是正常一跳，WAF到源站是正常一跳。WAF到日志卷，多出来的副本在这里诞生。分析师笔记本到模型API，是这条fixture要守住的跳。模型主机到它自己的日志，是大多数"我们自托管所以安全"的故事跳过的一跳。
威胁是泄露，不是提示注入，也不是权重窃取。会话令牌出现在补全日志里，就是一个凭证被放进了保留策略错误的文件。如果Cookie对分类不是必需的，它就不该跨过第四跳。没有商量余地。
我拒绝发送的清单
我在脱敏器旁边维护着一份拒绝清单，不是凭感觉，是fixture可以验证的列表：
- Cookie和Set-Cookie值，包括session=旁边那个不起眼的theme=兄弟
- Authorization的bearer值，以及查询、头或正文里任何eyJ开头的JWT形状块
- referrer里的密码重置令牌和魔法链接查询串
- 原始请求体——批量赋值载荷和粘贴的API密钥藏在那里
- 当读者是我不运营的模型时，内部源IP会被哈希处理
- 当工单问的是"哪条规则触发了"而非"受害者是谁"时，路径里的邮箱、上传文件名和UUID
模型还有用吗？有。方法、路径模板、状态码、字节数、规则ID和粗略的user-agent族，足够区分"这是扫描器"和"这是坏客户端"。我用两个fixture复现泄露，而不是从一个生产桶开始。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
