Web 应用安全基础：XSS、CSRF、SSRF、CORS、CSP 与安全 Cookie——三十年纵轴脉络与 2026 横轴格局综合报告 未开始

题记与说明

课题：Web 应用安全基础：XSS、CSRF、SSRF、CORS、CSP 与安全 Cookie。
本报告由同课题纵轴研究（发展脉络 1994–2026）与横轴研究（2026-10-31 时间截面横向对比）两份章节综合而成，检索与撰写日期均为 2026-10-31。关键事实在行内附来源 URL；行业背景共识、未逐字核验的转述均已单独标注。两章之间的重复内容（Agent 映射、OWASP Top 10 2025 变化）已合并，个别表述出入已在正文注明取舍。本稿为按独立审读意见修订后的最终稿（2026-10-31）：统一 CSP 采用率口径（21.9% 为 CSP 总体采用率）、拆分并核实 Google/Calzavara 两篇 CCS 2016 论文来源、精确化 SameSite=Lax 表述、补齐若干来源链接、补充核心术语释义、新增 §2.4 安全 Cookie 属性速览与 §2.3"何时仍需 token"决策树、§3.1 改为按原语拆分的独立小节、新增附录 A 上手清单；修订时当日重新检索核实的条目见文末局限说明。

TL;DR

这门"基础课"的六个成员全部诞生于 1994–1999 年的同一块地基——Cookie、同源策略与动态页面，而安全本身是功能扩张的事后副产品。此后三十年按同一条规律演进：新架构先给执行体扩权，安全再追认边界——动态页面造就 XSS（2000 年命名），Ajax 造就 CSRF（2008 年学术化），Mashup 造就 CORS 与 CSP（2010–2014 标准化），云计算造就 SSRF（2019 年 Capital One 事件成名）。2023 年起的 Agent 工具服务把"读网页、发请求、执行动作、携带用户凭据"四权合一交给 LLM 循环，六个旧洞在语义层同时复现：XSS 变成间接提示注入，CSRF 变成 confused deputy（"被迷惑的代理人"：持有合法权限的执行者被外部内容诱导，滥用自身权限伤害委托人），SSRF 有了 fetch 工具这个新引擎，会话 Cookie 变成 Agent 代持的最高价值资产。2025 年 OWASP Top 10 将 SSRF 从独立类别并入失效访问控制、注入大类继续收编 XSS，单点漏洞正在"根因化"；但最佳实践与真实部署之间鸿沟巨大——CSP 全网采用率仅 21.9%（总体口径），其中 nonce + strict-dynamic 的严格 CSP 份额更低（见 §2.3）。结论：六大原语不是过时知识，而是 Agent 时代的解释框架与最后防线；防御重心应从"让开发者更小心"转向"平台默认值 + 纵深组合 + 敏感动作人工确认"。附录 A 给出六个原语的最小配置清单、常见误配对照与自测方法，可直接上手。

一、纵轴：发展脉络（1994–2026）

1.1 七个阶段一张表

1.2 阶段 0：地基——Cookie、同源策略与动态页面（1994–1999）

这门"基础课"的三个概念诞生于同一时段、同一背景：Web 从静态文档变成可交互的应用。

第一块地基是 Cookie。1994 年，Netscape 工程师 Lou Montulli 为解决购物车状态问题发明了 HTTP Cookie（行业背景共识）；1997 年第一个正式规范 RFC 2109 落地，2000 年被 RFC 2965 取代，2011 年又被 RFC 6265 取代——这条"版本更替"本身就很能说明问题：Cookie 是实践中先于标准、标准被迫追认实践的经典案例（RFC 6265、daniel.haxx.se 的当年评述）。

第二块地基是同源策略（Same-Origin Policy）。1995 年 Netscape 2.0 引入 JavaScript 后，页面脚本一度可以读取任意内容，Netscape 在 2.02 版引入按"源"（origin）隔离脚本权限的机制——这成了此后三十年 Web 安全的宪法，本课题所有成员（XSS、CORS、CSP、SameSite）都在围绕"源"做文章（Wikipedia: Same-origin policy、aosabook 同源政策专章）。

这一阶段的特征是：没有任何一方在"做安全"，所有人都在做功能。Cookie、JS、动态 CGI 都是电商和门户时代的产物，安全是事后提炼的副产品。"先功能后安全"的顺序，决定了后面三十年这门课的内容几乎全是补丁。

1.3 阶段 1：XSS 时代——客户端注入被命名（2000–2004）

2000 年 2 月，CERT 协调中心发布 CA-2000-02《Malicious HTML Tags Embedded in Client Web Requests》，第一次把"页面把不可信输入当 HTML 输出"确认为一类独立漏洞——这是本课题公认的形式化起点，后续二十余年的 XSS 研究综述都以此文计时（CERT 公告存档引用，另见 Hannousse 等的系统综述《Twenty-two years since revealing cross-site scripting attacks: a systematic mapping and a comprehensive survey》，2022 年以预印本发布、后刊于 Computer Science Review：arXiv:2205.08425）。"cross-site scripting"这个名字常被归于 1998–2000 年间微软安全工程师发现并修复同类问题时的命名，缩写用 XSS 而非 CSS 纯粹是为了避让层叠样式表（背景共识，Wikipedia: XSS）。

这五年的核心矛盾是：服务器把"浏览器是 dumb terminal"的假设带进了有脚本能力的浏览器。输出编码、输入校验这些今天的基础功，当时全靠各应用各自摸索。转折性的个体动作是：微软在 2002 年 2–3 月的"Windows Security Push"期间想出 HttpOnly 标志并在 IE6 SP1 落地，让脚本读不到 Cookie——这是第一个"平台级"的 XSS 缓解，也是 Cookie 安全属性第一次登场，直接把本课题的两条线（XSS 与 Cookie）缝在了一起（OWASP HttpOnly 词条、Acunetix: HttpOnly Flag、2002 年微软邮件列表原始讨论）。

驱动因素很单纯：Web 应用化（CGI、JSP、ASP）让"拼接 HTML"成为主流生产方式，注入漏洞随之爆发，行业需要一个共同的名字来谈论它。

1.4 阶段 2：CSRF 学术化与 Web 2.0 的信任危机（2005–2009）

如果说 XSS 是"服务器信任了不该信任的输入"，这一阶段补上的第二课就是"服务器信任了不该信任的浏览器"。CSRF 的实际利用据考证早在 2001 年就出现过，但让概念真正立起来的是普林斯顿的 William Zeller 与 Edward Felten：2008 年 9 月 29 日他们公开四大流行网站的未公开 CSRF 漏洞，10 月 18 日发布论文《Cross-Site Request Forgeries: Exploitation and Prevention》，正式定义 CSRF 并首次提出 login CSRF 变体（论文 PDF、Semantic Scholar 收录、CWE-352）。CSRF token 从此成为框架标配。

同期 XSS 家族完成第二次分化：2005 年 Amit Klein 发表奠基论文《DOM Based Cross Site Scripting or XSS of the Third Kind》（WASC，2005-07），系统化阐述并命名 DOM-based XSS——原文站 webappsec.org 现已不可达，该文作为参考文献 [1] 收录于 OWASP DOM Based XSS 词条（OWASP 测试指南亦将其列为标准参考，背景共识），同年 10 月 MySpace 的 Samy 蠕虫一天感染百万用户，让社会第一次直观理解"存储型 XSS 的传染性"（行业背景共识，Wikipedia: Samy)）。

跨国界的另一条暗线是浏览器开始为跨域松绑：mashup、广告、字体与 Ajax 让"同源"变成生产力障碍。W3C 在 2005–2007 年间以《Access Control for Cross-Site Requests》为名起草跨域访问控制，2009 年 3 月更名为 Cross-Origin Resource Sharing——CORS 的起点，本意是"给同源策略开一扇有锁的窗"（W3C 历史版本索引、Wikipedia: CORS）。当时很少有人预见到，二十年后"配置错误的 CORS"会和"无锁的窗"一样成为常被利用的洞。

驱动因素：Ajax 与 Web 2.0 把应用逻辑搬进浏览器，服务器对"请求是谁发起的"只能依赖浏览器附带 Cookie 这一弱凭证——CSRF 正是这个结构性漏洞的总爆发。

1.5 阶段 3：标准化浪潮——防御第一次成为标准（2010–2014）

这一阶段的特征是大厂下场、白纸黑字：零散的攻防技巧被收编为正式标准。

• CSP 问世：2010 年 Firefox 4 以 X-Content-Security-Policy 头首次实现内容安全策略（Mozilla 与 WebKit 社区共同提案），随后被 W3C 标准化为 CSP 1（现存档为 W3C NOTE）。思路是把"页面允许加载和执行什么"从代码约定升级为浏览器强制执行的声明式合同（OWASP CSP Cheat Sheet 及 W3C 规格链接、W3C CSP3 草案历史）。
• Cookie 的现代标准：2011 年 4 月 RFC 6265 发布，废弃 RFC 2965、砍掉 Version/Cookie2 机制，把事实上的"version 0"Netscape 格式扶正为唯一标准，Secure/HttpOnly/Domain/Path 等属性统一收编（RFC 6265、daniel.haxx.se 评述）。
• CORS 转正：2013 年 1 月 29 日进入 Candidate Recommendation，2014 年 1 月 16 日成为 W3C Recommendation，Access-Control-Allow-Origin 等头从此写进每一份后端文档（W3C REC）。

参与者的画像变了：以前是 CERT、学者和个别浏览器厂商，现在是 Microsoft、Mozilla、Google、W3C/WHATWG 集体参与。驱动力来自两头——注入漏洞连年居 OWASP Top 10 榜首，以及跨域富应用对"可声明的信任边界"的需求。这一阶段确立的方法论至今在用：把安全决策从应用代码里拿出来，交给平台用机器可读的策略强制执行。

1.6 阶段 4：严格化与上云——防线收紧，攻击面搬家（2015–2019）

防线收紧的三件事。 2015 年 CSP 2 成为 W3C Recommendation，引入 nonce/hash 源表达式与更完善的报告机制（OWASP CSP Cheat Sheet）；2016 年 Google 团队（Weichselbaum、Spagnuolo 等）在分析了 160 余万主机的 CSP 部署（结论：约 95% 的白名单策略可被绕过）后发表 《CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy》（ACM CCS 2016），提出 'strict-dynamic' 与"Strict CSP"——放弃域名白名单、改用每响应随机的 nonce 沿信任链传播；作者在 DeepSec 2016 的同名演讲《CSP Is Dead, Long Live Strict CSP!》流传更广（ACM 论文页、作者 PDF、DeepSec 2016 幻灯）。同期 Calzavara 等的 CCS 2016 研究《Content Security Problems? Evaluating the Effectiveness of Content Security Policy in the Wild》系统批评了白名单型 CSP 的可绕过性（论文 PDF）。CSP 3 草案吸收了 strict-dynamic，最新版本更新到 2024 年 11 月 22 日，至今仍是 Working Draft（OWASP 链接的 W3C 规格）。Cookie 侧，__Secure-/__Host- 前缀等加固被写进接替 RFC 6265 的 6265bis 草案（draft-ietf-httpbis-rfc6265bis，截至本报告检索日（2026-10-31）已完成 IESG 评审、处于 RFC Editor 出版队列等待最终批准，尚未取得 RFC 编号，经当日查询 datatracker 核实）。

攻击面搬家的三件事。 云计算把"内网"变成了"控制面"：AWS/GCP/Azure 都在每台实例上挂了 169.254.169.254 链路本地元数据服务（IMDS，Instance Metadata Service，实例元数据服务，内含访问云 API 所需的临时 IAM 凭据）——SSRF 从"内网端口扫描"升级为"直接接管云身份"（securelayer7 IMDSv1 攻击分析）。2019 年 7 月的 Capital One 事件是标志性一课：攻击者利用配置错误的 WAF 发起 SSRF，从 IMDSv1 拿到 IAM 角色凭据，拖走约 1.06 亿客户记录，成为那个年代最大的数据泄露案之一（ACM 系统性分析、Zscaler 白皮书）。AWS 随即在 2019 年底推出 IMDSv2——要求先 PUT 获取会话 token 再 GET 元数据，使经典 SSRF（简单 GET 请求）无法直接取到凭据（IMDSv1/v2 对比分析）。

这一阶段的驱动力可以概括为一句话：资产搬家了，防御的假想敌从"陌生用户"变成"被攻陷的机器自身"。

1.7 阶段 5：默认安全转向——平台替开发者做决定（2020–2022）

这一阶段的主题是"默认值工程"。行业发现二十年的文档、扫描器和培训都没能把基础功变成肌肉记忆，于是浏览器和云厂商直接改默认行为：

• 2020 年 2 月 Chrome 80：未声明 SameSite 的 Cookie 一律按 SameSite=Lax 处理，跨站 Cookie 必须显式 SameSite=None; Secure——CSRF 最主要的"路条"（跨站携带的会话 Cookie）被平台层默认吊销（Chromium Blog、Google 搜索中心指南）。但 Lax 的精确语义是：仅顶级 GET 导航携带 Cookie；跨站 POST 与跨站子资源请求（fetch/XHR/图片）均不携带——经典 CSRF（跨站表单 POST）由此被默认挡住，但顶级 GET 导航仍带 Cookie，若状态变更误用 GET 端点、或叠加既有绕过技巧，仍可被利用，专用 CSRF token 仍是推荐防线（Security StackExchange 讨论、PortSwigger 绕过手册）。
• 2020 年 6 月 2 日：W3C 把 CORS 规范归档为 Obsolete Recommendation（SPSD），CORS 算法正式并入 WHATWG Fetch Standard 这一活文档——标准本身完成了从"一次性规范"到"持续演化的平台行为"的转变（W3C SPSD 声明、Fetch Standard）。
• 2021 年 OWASP Top 10：SSRF 首次作为独立类别 A10 入榜，评述明确点名其危害在于"即使有防火墙、VPN 或网络 ACL，应用也可能被诱导向意外目的地发请求"（A10:2021 官方页)）。

驱动力是明确的：开发者不主动加固，平台只好用默认值强制迁移。代价是兼容性阵痛——依赖跨站 Cookie 的第三方登录、SSO 与内嵌内网系统在 Chrome 80 推开后大面积出现登录故障，Chrome 团队为此提供企业级回退策略并分阶段放缓推广节奏（Chromium Blog；"一夜失效"为当时的行业印象性概括，背景共识），收益是整个生态的基线抬高了一截。

1.8 阶段 6：Agent 工具服务时代——六大机制被逐一复刻（2023–2026，时间线锚点）

2023 年起，大模型应用把"发起请求、解析内容、执行动作"的权力交给 LLM 循环和它挂载的工具服务。Agent 工具服务本质上是一台"被程序化驱动的浏览器 + 一个被外部内容指挥的后端"——过去三十年沉淀的六条防线，几乎每一条都在这个新形态上原样复刻了一遍。时间线锚点如下（机制逐项映射与实证案例集中在本文第三章交叉洞察）：

• 起点：2023 年 3 月 OpenAI 为 ChatGPT 开放插件，模型获得联网与工具调用能力；2024 年 11 月 25 日 Anthropic 发布开源协议 Model Context Protocol（MCP），自称"AI 应用的 USB-C"，把工具接入标准化（heise 报道、MCP 官方）；2025 年 6 月 18 日 MCP 规范更新，将 MCP 服务器重新定位为 OAuth 2.1 资源服务器，引入 RFC 9728 保护资源元数据与 WWW-Authenticate 发现（MCP 授权规范、规范讨论）。
• 攻击面公告密集出现：2025 年 4 月 Invariant Labs 披露 MCP 工具投毒攻击（TPA）并展示 GitHub MCP 官方服务器的 confused deputy（释义见 TL;DR）；2025 年 7 月 mcp-remote 命令注入（CVE-2025-6514）；2025 年 10 月 ChatGPT Atlas 发布后数天内的注入潮；2025 年 12 月 OWASP 发布 Agentic 应用 Top 10（条目列表见附录 A.3）。
• 分类学交接：2025 年 11 月发布的 OWASP Top 10 2025 中 SSRF 不再单列（并入 A01 失效访问控制）、注入大类继续收编 XSS（2021 版基线对照见 §2.2）；2025 年 12 月 9 日 OWASP 另发《Top 10 for Agentic Applications for 2026》——基础课与新课正式分轨（top10.owasp.org/2025、genai.owasp.org）。

三十年里每一次跃迁都遵循同一模式：新架构先给执行体扩权，安全再追认边界。动态页面造就 XSS（服务器扩了输出权）；Ajax 造就 CSRF（浏览器扩了请求权）；云计算造就 SSRF（服务器扩了出网权）；Mashup 造就 CORS 与 CSP（浏览器扩了跨域权）；Agent 工具服务把"读网页 + 发请求 + 执行动作 + 携带用户凭据"四权合一地交给 LLM 循环——于是六个旧洞同时复现，且因为模型无法稳定区分"数据"与"指令"，连"输出编码"这个最基础的等价物都还没有发明出来。

二、横轴：横向对比（2026-10-31 时间截面）

2.1 比什么：三类对比对象

本课题不是单一产品，而是一个"知识体系/能力域"。在 2026-10-31 截面上，横向对比对象分三类：

• A 类·同类知识体系：OWASP Top 10:2025、OWASP Cheat Sheet Series、PortSwigger Web Security Academy、MDN、中文社区与书目——与本课题争夺"学习者注意力"的直接同类物。
• B 类·机制替代方案：六个技术点各自的新旧防御路线之争（CSRF token vs SameSite vs Fetch Metadata；allowlist CSP vs nonce + strict-dynamic vs Trusted Types 等）。
• C 类·范式竞争者：Agent 工具服务（MCP 服务、浏览器 Agent、Computer Use）——不否定经典原语，而是改变威胁模型；其与六原语的逐项映射见第三章，避免与纵轴阶段 6 重复展开。

2.2 A 类：知识体系横向对比

逐项说明：

1. OWASP Top 10:2025：2025 版对本课题影响直接——SSRF 不再单列（2021 版的 A10），官方理由是 SSRF 本质上是"服务器被诱骗替攻击者发起未授权请求"，属于访问控制失败，故并入 A01: Broken Access Control；XSS 不再作为独立风险点名，继续归入注入大类。对照 2021 版基线（A01 失效访问控制、A02 加密失败、A03 注入——XSS 当年即属此大类、A04 不安全设计、A05 安全配置错误、A06 易受攻击和过时的组件、A07 认证与身份识别失败、A08 软件与数据完整性失败、A09 安全日志与监控失败、A10 SSRF，来源：OWASP Top 10:2021），2025 版的真实变化是：注入类别从 A03 顺延为 A05、SSRF 从独立类别 A10 并入 A01，并新增"软件供应链失效""异常条件处理不当"两个独立类别。榜单完整顺序：A01 失效访问控制、A02 安全配置错误、A03 软件供应链失效、A04 加密失败、A05 注入、A06 不安全设计、A07 认证失败、A08 软件或数据完整性失败、A09 安全日志与告警失败、A10 异常条件处理不当（来源：top10.owasp.org/2025，A01–A10 类名经修订时当日核对；GitLab 解读，正文未逐字核验）。启示：榜单正在"根因化"，六个点正从"独立漏洞"退化为"原语级思维"，专题学习反而更有长期价值。
2. OWASP Cheat Sheet Series：官方口径为 120+ 篇社区维护速查手册，与 Top 10 建立索引映射（owasp.org/projects/cheat-sheet-series）。它是本课题每个点的"实现层对应物"；本课题的差异化在于横切叙事与最新动态，而非替代它。
3. PortSwigger Web Security Academy：完全免费、250+ 交互实验，覆盖本课题全部六个点并有专门学习路径（portswigger.net/web-security、Learning Paths）。它是本课题最强同类竞品：机制讲解 + 在线靶场闭环。本课题相对劣势是"只读不动手"，建议引用其实验作为配套。
4. MDN：CORS、Cookie、Fetch Metadata 的语义权威（例：Sec-Fetch-Site、CORS）。本课题适合以 MDN 为"字典"，自己提供"决策"。
5. 中文生态：社区活跃（先知社区、看雪学苑、攻防世界），但体系化中文教材老化明显——《白帽子讲Web安全》成书于 2012/2014，早于 SameSite 默认化、Fetch Metadata、CSP3 strict-dynamic 和 Agent 浪潮；免费在线笔记 websec.readthedocs.io 覆盖面广但更新节奏有限（先知社区、websec.readthedocs.io）。这给本课题留下了"中文 + 2026 视角"的空白位。

2.3 B 类：六大技术点的新旧方案之争

逐项说明（纵轴脉络在此收束为"路线判断"）：

• XSS 防御的"三层栈"已经定型：输出编码/框架转义（第一层）→ 消毒库或 Trusted Types（第二层）→ 严格 CSP（第三层）。DOMPurify 的连续 CVE 说明"消毒库本身也是攻击面"；Trusted Types 的 Firefox 缺位说明跨浏览器成熟度仍不完整——这两点都应如实呈现，避免"装了 DOMPurify 就安全"的误导。
• CSRF 防御正在"去 token 化"：浏览器默认 SameSite=Lax 加服务端 Sec-Fetch-Site 校验已成为新流派，但两者都有边界情形——跨站重定向会翻转 Sec-Fetch-Site（W3C Fetch Metadata 规范 §4.1：该头部在重定向链的每个请求上都重算，"The header's value will shift in the presence of cross-origin or cross-site redirection"，且一旦链条触到跨站就保持 cross-site——按头一刀切会误伤 SSO 登录跳转、支付回跳等正常跨站重定向流程，W3C Fetch Metadata、实际行为讨论）、Lax 放行顶级 GET 导航。"何时仍需 token"的简化决策树如下（§3.2 第 2 条引用）：

何时仍需 CSRF token（简化决策树）
1) 站点是否全量启用 SameSite=Lax/Strict，且不存在依赖跨站跳转的登录/支付回调流程？
   否 → 需要 token（或先补齐 SameSite 再评估）。
2) 是否存在用 GET 触发状态变更的端点（如 ?action=delete）？
   是 → 改为 POST + token（Lax 拦不住顶级 GET 导航）。
3) 是否依赖 Sec-Fetch-Site 校验？核对业务里有无合法的跨站重定向链（SSO、支付回跳）——
   有则不能一刀切拦 cross-site，这些路径单独放行并补 token。
4) 以上皆否 → "SameSite 默认 + Fetch Metadata 校验"可作主力，token 降为纵深可选项。

• SSRF 的重心从"解析层"上移到"网络层"：URL 白名单多年被绕穿后，行业共识是把防线后移到出口代理、网段隔离与云元数据加固（IMDSv2）；OWASP 2025 的归类变化与此同构。
• CORS 的定位要摆正：它从来不是授权机制，只是读取许可；跨域安全真正的根在服务端授权与 Fetch Metadata 校验。
• CSP 的"名实差"是最值得写进课题的反差：最佳实践清晰（nonce + strict-dynamic），但全网采用率只有 21.9%（总体口径，严格 CSP 份额更低）——"知道"与"部署"之间的巨大鸿沟，正是专题教育的价值空间。
• Cookie 的结论与纵轴一脉相承：HttpOnly、SameSite、前缀属性的本质都是"让最值钱的凭据在最坏情况下也拿不到/带不走"，这条原则在 Agent 时代将继续以新形态出现（见第三章）；属性语义、三值选择与推荐 Set-Cookie 形态集中见 §2.4。

2.4 安全 Cookie 属性速览

标题六个成员里，安全 Cookie 是唯一没有专属攻击类别名的一个——它的全部内容就是一组 Set-Cookie 属性的组合学。散落在纵轴阶段 1、3、4、5 与 §2.3 表中的 Cookie 线索，在此集中成一份速查；本节与 §3.1.6（Agent 语境下的会话安全）互为补充。

三个核心安全属性：

• Secure：Cookie 仅经 HTTPS 传输，明文 HTTP 下浏览器直接拒发。
• HttpOnly：脚本读不到（document.cookie 不可见），专防 XSS 偷会话——但请求仍会自动携带，所以它防不了 CSRF。与 Secure 互补而非互替（纵轴阶段 1）。
• SameSite：控制"跨站请求是否携带 Cookie"，即 CSRF 的"路条"管理（纵轴阶段 5）。三值差异：
  • Lax（默认推荐）：仅顶级 GET 导航携带 Cookie；跨站 POST 与跨站子资源请求（fetch/XHR/图片）均不携带。
  • Strict（最严格）：任何跨站请求都不带，连点外部链接跳转进来都不带——最安全，但用户从外链进入时会"刚登录却像没登录"（导航型流量体验代价），一般只给高敏会话使用。
  • None（完全放开）：跨站请求一律携带，必须配 Secure，否则现代浏览器拒收。

选择建议：普通业务用 Lax；确需跨站共享会话的第三方嵌入用 None + Secure；支付、管理后台等高敏场景可上 Strict 并配短有效期。

Domain/Path：

• Domain 省略 = host-only（只有设置它的主机收到）；显式写 Domain=example.com 会共享给所有子域、暴露面立刻变大——能省则省。
• Path 只是作用域约定，不是安全边界：同源策略按 origin（scheme + host + port）判断，不按路径判断，浏览器对 /admin 的 Cookie 并不会比对 / 保护得更多。

前缀属性（浏览器强制，不是服务器自觉）：

• __Host-：名称以 __Host- 开头的 Cookie 必须同时满足 Secure + 不带 Domain + Path=/，等于把 Cookie 钉死在一个 origin 上——最强会话绑定的现成开关。
• __Secure-：只强制 Secure，弱于 __Host-。
• 两者均已由 6265bis 收编（见纵轴阶段 4）。

关于"无状态 JWT 会话"（§2.3 表中一笔带过，此处展开）：传统会话 Cookie 对应服务端一张会话表——吊销即删一行；自包含的 JWT 把会话状态签进令牌本身，过期前服务端无法直接"删掉它"，撤销要靠短有效期 + 刷新令牌 + 黑名单/版本号等补丁组合。"无状态"换来的横向扩展便利，以牺牲即时撤销能力为代价（背景共识）。Agent 语境下同理：MCP 令牌透传（token passthrough）之危险，正在于令牌绕过了可吊销的中间层（见 §3.1.6）。

自测：浏览器 DevTools → Application → Cookies 面板逐列核对 Secure/HttpOnly/SameSite/前缀；或 curl -sI https://你的站点 | grep -i set-cookie 查看响应头。推荐形态示例见 §3.2 第 2 条与附录 A.1。

2.5 C 类：Agent 范式竞争者（概要）

Agent 工具服务指 MCP 服务器、浏览器 Agent（OpenAI Operator 2025-01-23 研究预览、ChatGPT Agent 2025-07、ChatGPT Atlas 2025-10-21）及各类 Computer Use 实现与其插件生态。Simon Willison 于 2025-06-16 提出的 "lethal trifecta（致命三要素）"——私有数据访问、暴露于不可信内容、可对外通信——为 Agent 风险给出了最小模型（simonwillison.net、Atlas 介绍）。它与六大原语存在干净的映射：不可信内容 ≈ XSS 的注射语义；对外通信 ≈ SSRF/CORS 的外传语义；私有数据访问 ≈ Cookie/会话语义。逐项映射与实证案例见第三章。

三、交叉洞察：两轴结合说明了什么

3.1 两轴交汇处的三个结构判断

判断一：Agent 不是"新漏洞类别"，而是六原语的同构复现。 纵轴显示每个时代的漏洞都源自执行体扩权；横轴显示 Agent 把四类权力（读网页、发请求、执行动作、携带凭据）合并到一个无法稳定区分"数据"与"指令"的执行体上。合并两章的证据，六大原语在 Agent 工具服务中的复刻形态先以"每格一句话"的摘要表给出（综合纵轴"综合映射表"与横轴"经典原语→Agent 语境映射表"，并补入全部实证案例）；逐原语的复刻形态、实证案例与可迁移防线拆解为 §3.1.1–§3.1.6 六个独立小节：

3.1.1 XSS：注入指令被当指令执行

复刻形态。 经典原型是"不可信输入被当 HTML 执行"；Agent 工具服务中，工具描述、工具结果、邮件与网页中的注入指令被当作指令执行——Agent 渲染 markdown 图片/链接本身就是注入汇。

实证案例（2025–2026）。 MCP 工具投毒攻击（TPA）（Invariant Labs，2025-04-01）：恶意指令藏在工具描述里，用户不可见、模型可见，还能"影子化"劫持对其他可信服务器的调用（Invariant Labs）。EchoLeak（CVE-2025-32711）：M365 Copilot 零点击漏洞，一封含隐藏指令的邮件即可注入，诱导 Copilot 将内部数据渲染进 markdown 图片 URL 外传；外传并未直连攻击者服务器，而是借微软内部的 URL 预览代理（Teams 的 asyncgw 预览接口）间接带出，绕过了"模型输出不得直连外部域"的限制；微软已修复，公开展示前未观测到在野利用（arXiv 论文；Aim Security 披露综述，未附核验链接）。

可迁移防线。 输出编码在此失效——模型没有"HTML 上下文"可供转义；对应物是内容标记（spotlighting，即用特殊标记/定界符把不可信内容显式标注出来，让模型更容易区分"数据"与"指令"）与信任分层（Microsoft MCP 防护指南，2025-04-28）。

3.1.2 CSRF：被借用的用户身份

复刻形态。 经典原型是"服务器信任浏览器自动附带 Cookie"；Agent 工具服务中，Agent 代持用户 Cookie 与 OAuth 令牌，以用户身份执行被页面内容指挥的动作。

实证案例（2025–2026）。 GitHub MCP 官方服务器 confused deputy（Invariant Labs，2025-05-26）：恶意 GitHub issue 注入指令，诱使 Agent 用用户自己的凭据读取私有仓库并外传到攻击者公开仓库（Invariant Labs）。Atlas 注入潮（2025-10）：NeuralTrust 演示 Omnibox 假 URL 注入（2025-10-24）、LayerX/Akamai 披露"ChatGPT Tainted Memories"记忆投毒（2025-10-27）、Brave 分析 Omnibox 注入隐私风险（2025-10-29）（Akamai/LayerX、Brave）。

可迁移防线。 SameSite/token 无直接对应物——SameSite 防的是"恶意网站借用户浏览器发请求"，防不了"用户自己的 Agent 被网页内容借道"；需要敏感动作人工确认（OpenAI watch mode 一类设计）。

3.1.3 SSRF：模型选定的 URL 成了新的触发参数

复刻形态。 经典原型是"参数化 URL 打到内网/云元数据"；Agent 工具服务中，fetch/浏览工具执行"模型选定的 URL"，而模型可被注入操纵；连接恶意 MCP 服务器可演变为客户端代码执行。

实证案例（2025–2026）。 CVE-2025-6514（mcp-remote，JFrog，2025-07）：连接恶意 MCP 服务器触发 OS 命令注入，Critical 级（JFrog 披露，正文未逐字核验）；CrewAI fetch 工具 SSRF 缺陷悄悄修复；HKUDS nanobot SSRF 漏洞 CVE-2026-92576 定为严重级（sweet.security 汇总，二手汇总，原文细节未逐一复核）。

可迁移防线。 部分可迁移：URL 允许列表、egress 控制（对可出网目的地做白名单与网络层限制）、IMDSv2 式 token 化——169.254.169.254 依然是最有价值的靶标，与 2019 年 Capital One 的区别只是触发参数从"攻击者控制的输入"变成"被注入控制的模型输出"。

3.1.4 CORS：缺位的授权边界

复刻形态。 经典原型是"跨域读取未显式授权"；Agent 工具服务中，MCP 服务器间/工具间缺乏授权边界；本地辅助进程监听 localhost 且无鉴权，浏览器跨源直接命中。

实证案例（2025–2026）。 CVE-2025-49596（MCP Inspector，CVSS 9.4，<0.14.1）：Inspector 本地代理无认证、0.0.0.0 绑定，恶意网页可跨源触发 RCE（远程代码执行）（GitHub Advisory/Inspector 仓库，正文未逐字核验）。

可迁移防线。 方法论可迁移：显式授权、最小权限；MCP 2025-06-18 版把服务器定位为 OAuth 2.1 资源服务器正是在补这道边界（MCP 规范）。

3.1.5 CSP：防外传的最后防线及其绕过

复刻形态。 经典原型是"声明式限制页面能加载/执行什么"；Agent 工具服务中，内容渲染与外传控制成为"防 exfiltration 最后防线"，但会被内部可信资源绕过。

实证案例（2025–2026）。 EchoLeak 正是借内部资源渲染完成外传（见 §3.1.1）；OpenAI 于 2025 年 12 月（22 日）公开承认 Atlas 提示注入"不太可能被完全解决"，转而用强化学习自动红队持续加固（OpenAI: Hardening Atlas、CyberScoop 报道；横轴章曾转述为"可能永远无法完全解决"且未逐字核验，本综合报告以纵轴核实的措辞与日期为准）。

可迁移防线。 方法论可迁移：策略与代码分离、平台强制执行；但尚无"声明式限制 Agent 能调用什么"的成熟等价物，当前通用缓解是工具允许列表、描述消毒、人在环确认与最小权限。

3.1.6 安全 Cookie：会话成为最高价值资产

复刻形态。 经典原型是"会话凭证可被偷/被跨站携带"；Agent 工具服务中，浏览器 Agent 直接使用用户真实登录会话，会话即攻击者眼中的最高价值资产；Agent 会话与人类会话无隔离；MCP 令牌透传（token passthrough，把用户凭据原样转交给下游工具）与未走 OAuth 的部署制造新时代的"无 HttpOnly 会话"。

实证案例（2025–2026）。 Rehberger 于 2025-02-17 发布对 Operator 的提示注入演示，含数据外传场景与防御讨论（ChatGPT Operator: Prompt Injection Exploits & Defenses，修订时补核）；2026-06 华盛顿大学研究：7 款主流 Agent 浏览器中 4 款可被绕过基础安全护栏（UW News，2026-06-30）；token passthrough 风险（sweet.security）。

可迁移防线。 IMDSv2 证明"给凭据加交互式获取步骤"（token 化）是对抗凭据盗取的有效平台级默认，与 HttpOnly、SameSite 一脉相承：不是消灭漏洞，而是让漏洞拿不到最值钱的东西（Cookie 属性语义与推荐 Set-Cookie 形态见 §2.4 与 §3.2 第 2 条）。

判断二：防御方法论的接力棒交回"平台默认值"。 纵轴三次证明最可靠的解法都不是让开发者更小心：HttpOnly（2002）让 XSS 偷不到 Cookie，IMDSv2（2019）让 SSRF 拿不到云凭据，SameSite=Lax 默认化（2020）替全网吊销了 CSRF 的路条。横轴的 Agent 证据链指向同一条路：MCP 把服务器 OAuth 2.1 资源服务器化、OWASP 对 Agent 应用的缓解建议（工具白名单、egress 控制、令牌隔离、敏感动作人工确认）都是"把边界做进平台默认值"的当代版本。而 OpenAI 承认提示注入"不太可能被完全解决"，恰是纵轴"安全永远是事后追认边界"规律的最新注脚——防线目标从"杜绝"降级为"持续加固 + 缩小爆炸半径"。

判断三：知识体系正在"根因化"与"分轨化"，本课题占据中间的解释位。 横轴显示 OWASP Top 10:2025 把 SSRF 并入访问控制、注入大类继续收编 XSS——单点漏洞榜单让位于原语级思维；同时 OWASP 于 2025-12-09 发布《Top 10 for Agentic Applications for 2026》，Agent 安全自立榜单（genai.owasp.org）。两轴合起来看：旧榜单在抽象化，新榜单在分化，而能解释"为什么六个旧洞会在 Agent 上同时复现"的，恰恰是这门基础课本身——它既是"旧世界"的防御清单，也是"新世界"的解释框架。

3.2 对读者的判断与建议

1. 学习顺序上，先地基后新词。 六个原语 + 同源策略是理解一切新威胁（提示注入、工具投毒、Agent 外传）的坐标系；跳过原语直接学"AI 安全"会停留在名词层。建议以本课题为主线，配 PortSwigger Web Security Academy 的对应实验补上动手环节，以 MDN 为语义字典、OWASP Cheat Sheets 为实现手册。
2. 防御选型上，用"纵深组合 + 边界情形"取代"单一银弹"。 XSS 用三层栈（框架转义 → 消毒库/Trusted Types → 严格 CSP），并跟踪消毒库版本；CSRF 用"SameSite=Lax 默认 + Fetch Metadata 校验"，对顶级 GET 与重定向边界情形保留 token（判断流程见 §2.3 决策树）；SSRF 把预算花在网络层（egress 控制、网段隔离、IMDSv2）而非 URL 正则；CORS 记住它是读取许可而非授权；Cookie 属性按"最坏情况下拿不走"的原则全量启用（HttpOnly + Secure + SameSite + __Host- 前缀），推荐形态：Set-Cookie: __Host-sid=<随机值>; Secure; HttpOnly; SameSite=Lax; Path=/（各属性语义见 §2.4，可直接落地的完整清单见附录 A）。
3. 工程管理上，正视"知道—部署"鸿沟。 CSP 最佳实践明确但全网采用率仅 21.9%（总体口径，严格 CSP 份额更低，见 §2.3），说明组织缺的不是知识而是默认值：把安全属性、CSP 头、Fetch Metadata 校验做进框架模板和 CI 检查，比多一轮培训有效。
4. 面向 Agent 时代，按"三要素"自查。 任何同时具备"私有数据访问 + 暴露于不可信内容 + 可对外通信"的系统（自己写的 Agent、接入的 MCP 服务、允许 Agent 代登录的浏览器）都是高危组合，至少砍断一条：MCP 工具用允许列表与最小权限 scoping，凭据走 OAuth 2.1 而非令牌透传，敏感动作加人工确认，出口加 egress 控制。
5. 信息跟踪上，跟着榜单的两条分轨走。 传统应用风险看 OWASP Top 10:2025（原语化后的 A01/A05），Agent 应用风险看 OWASP Agentic Top 10（条目列表见附录 A.3）与 Simon Willison 的 lethal trifecta 框架；中文学习者需警惕 2012/2014 年教材中已被平台默认值改写的结论（如"SameSite 不是默认行为""CSP 用域名白名单"）。
6. 对"新课"保持纵轴式耐心。 Agent 安全处在 2000 年 XSS 刚被命名、2008 年 CSRF 刚被学术化的阶段——威胁已经爆发，等价物（语义层的"输出编码"、Agent 的"内容安全策略"）尚未发明。历史规律是：等价物出现前，平台默认值与人在环确认是最优可得解；等价物出现后，今天这场讨论会成为下一份三十年纵轴的"阶段 0"。

附录 A：上手清单——六原语最小配置、常见误配对照与 Agentic Top 10 条目

本附录把正文从"解释框架"补成"可上手材料"：A.1 给每个原语一份最小可用配置，A.2 列出最常见的错误配置及其危险所在，A.3 补齐正文引用过 4 次却从未列出的 OWASP Agentic Top 10 条目，A.4 是自测方法。

A.1 六原语最小配置清单

XSS（三层栈一起上，配置只作用于第三层 CSP）：

# 严格 CSP：nonce 每个响应随机生成，页面脚本标签须携带同一 nonce
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'none'

• 第一层：框架自动转义（React/Vue/Angular 默认）；富文本场景用 DOMPurify 并紧跟版本（§2.3）。
• 第二层：可渐进启用 Trusted Types（require-trusted-types-for 'script'，Firefox 缺位，先 Report-Only）。
• 调试期先用 Content-Security-Policy-Report-Only 收集违规，再切强制。

CSRF： 会话 Cookie 设 SameSite=Lax（见本清单 Cookie 条）；服务端校验 Sec-Fetch-Site 为 same-origin（合法跨站重定向流程单独放行，§2.3 决策树）；表单提交携带随机 token 兜底。

SSRF（重心在网络层）：

• 出口网关/代理只放行业务白名单域名与目的网段；
• 云元数据上锁：AWS 强制 IMDSv2（aws ec2 modify-instance-metadata-options --http-tokens required，需按实例逐台执行）；
• 应用侧解析 URL 后校验解析出的 IP：拒绝 169.254.0.0/16、127.0.0.0/8、内网网段与 metadata.google.internal；禁用自动跟随重定向，或每一跳重新校验。

CORS：

# 白名单回显而非反射任意 Origin；凭据与精确 Origin 成对出现
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

CSP： 即 XSS 条的同一组头；frame-ancestors 'none' 可另防点击劫持。

安全 Cookie：

Set-Cookie: __Host-sid=<随机值>; Secure; HttpOnly; SameSite=Lax; Path=/

• 确需跨站携带时才降级为 SameSite=None; Secure；会话 Cookie 永远不要写 Domain（属性语义见 §2.4）。

A.2 常见错误配置对照

A.3 OWASP Top 10 for Agentic Applications（2026）条目列表

正文（§1.8、§2.5、§3.2、判断三）引用过 4 次却从未列出条目，此处补齐。OWASP 于 2025-12-09 发布《Top 10 for Agentic Applications for 2026》，标识为 ASI01–ASI10（官方页见参考来源 [34]；条目名称经 Promptfoo 文档页与多方解读交叉核对，个别措辞以 OWASP 官方 PDF 为准）：

1. ASI01 Agent Goal Hijack（Agent 目标劫持）
2. ASI02 Tool Misuse and Exploitation（工具滥用与利用）
3. ASI03 Identity and Privilege Abuse（身份与权限滥用）
4. ASI04 Agentic Supply Chain Vulnerabilities（Agentic 供应链漏洞）
5. ASI05 Unexpected Code Execution（意外的代码执行）
6. ASI06 Memory and Context Poisoning（记忆与上下文投毒）
7. ASI07 Insecure Inter-Agent Communication（不安全的代理间通信）
8. ASI08 Cascading Failures（级联失效）
9. ASI09 Human–Agent Trust Exploitation（人机信任滥用）
10. ASI10 Rogue Agents（失控 Agent）

与本文六原语的呼应：ASI01/ASI06 ≈ XSS（注入语义）；ASI02/ASI03 ≈ CSRF 与 CORS（授权边界语义）；ASI04 ≈ 软件供应链；ASI05 ≈ SSRF/RCE 家族；ASI07–ASI10 是传统榜单没有的新类——对应"分轨化"判断（判断三）。

A.4 自测方法

• CSP 部署与质量：curl -sI https://你的站点 | grep -i content-security-policy 看是否下发；策略质量用 Google CSP Evaluator 与 Mozilla HTTP Observatory 评估；先 Report-Only 观察违规再强制。
• Cookie 属性：DevTools → Application → Cookies 面板逐列核对 Secure/HttpOnly/SameSite/前缀（对照 §2.4）。
• CORS：curl -sI -H "Origin: https://evil.example" https://你的站点/api，若响应把任意 Origin 原样反射且允许凭据，即为 A.2 表中的高危误配。
• SSRF：盘点所有"服务器代发请求"的功能点（导入、预览、webhook、fetch 工具），逐一核对能否指向 169.254.169.254 与内网网段。

四、参考来源

地基与 Cookie

1. RFC 6265：<https://www.rfc-editor.org/info/rfc6265>；daniel.haxx.se 评述：<https://daniel.haxx.se/blog/2011/04/28/the-cookie-rfc-6265>
2. draft-ietf-httpbis-rfc6265bis：<https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/>（2026-10-31 查询：RFC Ed Queue，等待最终批准）
3. Wikipedia: Same-origin policy：<https://en.wikipedia.org/wiki/Same-origin_policy>；aosabook 同源政策专章：<https://aosabook.org/en/500L/the-same-origin-policy.html>

XSS 与 CSP

1. CERT CA-2000-02：<https://www.cert.org/advisories/CA-2000-02.html>；Wikipedia: XSS：<https://en.wikipedia.org/wiki/Cross-site_scripting>；Hannousse 等，Twenty-two years since revealing cross-site scripting attacks（2022 预印本，后刊 Computer Science Review）：<https://arxiv.org/abs/2205.08425>
2. OWASP HttpOnly：<https://owasp.org/www-community/HttpOnly>；Acunetix: HttpOnly Flag：<https://www.acunetix.com/blog/articles/http-only-flag-protecting-cookies-against-xss/>；2002 年微软邮件列表讨论：<https://lists.immunitysec.com/pipermail/dailydave/2002-May/000021.html>
3. Amit Klein，《DOM Based Cross Site Scripting or XSS of the Third Kind》（WASC，2005-07；原文站 webappsec.org 已不可达，经 OWASP 词条参考文献 [1] 收录）：OWASP DOM Based XSS 词条 <https://owasp.org/www-community/attacks/DOM_Based_XSS>；OWASP 测试指南：<https://owasp.org/www-project-web-security-testing-guide/>
4. OWASP CSP Cheat Sheet：<https://community.owasp.org/controls/Content_Security_Policy>；W3C CSP3 草案：<https://www.w3.org/TR/2018/WD-CSP3-20181015>
5. Google（Weichselbaum、Spagnuolo 等），CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy（ACM CCS 2016，DOI 10.1145/2976749.2978379）：<https://dl.acm.org/doi/10.1145/2976749.2978379>；作者 PDF：<https://research.google.com/pubs/archive/45542.pdf>；DeepSec 2016 同题演讲幻灯《CSP Is Dead, Long Live Strict CSP!》：<https://deepsec.net/docs/Slides/2016/CSP_Is_Dead,_Long_Live_Strict_CSP!_Lukas_Weichselbaum.pdf>
6. Calzavara et al., Content Security Problems? Evaluating the Effectiveness of Content Security Policy in the Wild（ACM CCS 2016）：<https://www.dais.unive.it/~calzavara/papers/ccs16.pdf>
7. 2025 Web Almanac Security 章（CSP 采用率 21.9%、2024 年 18.5%；nonce 约 20%、strict-dynamic 约 10%）：<https://almanac.httparchive.org/en/2025/security>
8. Mozilla standards-positions #20（Trusted Types）：<https://github.com/mozilla/standards-positions/issues/20>；DOMPurify 仓库：<https://github.com/cure53/DOMPurify>；DOMPurify releases 发布记录（3.4.0/3.4.7 条目经逐字核对）：<https://github.com/cure53/DOMPurify/releases>

CSRF 与 SameSite

1. Zeller & Felten 论文：<https://people.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf>；Semantic Scholar：<https://www.semanticscholar.org/paper/891d0b82a9ee35ebb98a1020fb0e24ad5d438f1e>；CWE-352：<https://cwe.mitre.org/data/definitions/352.html>
2. Chromium Blog（2020-02）：<https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html>；Google 搜索中心指南：<https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure>
3. PortSwigger 绕过 SameSite 手册：<https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions>；Security StackExchange 讨论：<https://security.stackexchange.com/questions/234386/do-i-still-need-csrf-protection-when-samesite-is-set-to-lax>
4. web.dev Fetch Metadata：<https://web.dev/articles/fetch-metadata>；MDN Sec-Fetch-Site：<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site>；W3C Fetch Metadata 规范（§4.1 重定向语义经当日核对）：<https://www.w3.org/TR/fetch-metadata/>；Sec-Fetch-Site 重定向行为讨论：<https://stackoverflow.com/questions/78195772/why-is-sec-fetch-site-cross-site-when-redirecting-to-same-site>

CORS 与 SSRF

1. W3C CORS REC（2014-01-16）：<https://www.w3.org/TR/2014/REC-cors-20140116>；W3C 历史版本索引：<https://www.w3.org/TR/cors/>；Wikipedia: CORS：<https://en.wikipedia.org/wiki/Cross-origin_resource_sharing>
2. W3C CORS SPSD（2020-06-02）：<https://www.w3.org/TR/2020/SPSD-cors-20200602>；Fetch Standard：<https://fetch.spec.whatwg.org>；MDN CORS：<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS>
3. OWASP A10:2021（SSRF）：<https://top10.owasp.org/2021/A10_2021-Server-Side_Request_Forgery_(SSRF)>；securelayer7 IMDSv1 攻击分析：<https://securelayer7.net/learn/cloud-security/imdsv1-attacks>
4. ACM: Capital One 系统性分析：<https://dl.acm.org/doi/10.1145/3546068>；Zscaler Capital One 白皮书：<https://www.zscaler.com/resources/white-papers/capital-one-data-breach.pdf>
5. OWASP Top 10:2021 官方列表（2021 版基线对照用）：<https://owasp.org/Top10/>

知识体系横向对比

1. OWASP Top 10:2025 官方页（A01–A10 类名经修订时当日核对）：<https://top10.owasp.org/2025/>；GitLab 解读（未逐字核验）：<https://about.gitlab.com/blog/2025-owasp-top-10-whats-changed-and-why-it-matters>；2025 版行业解读：<https://medium.com/@appsecmaster.net/what-you-need-to-know-about-the-owasp-top-10-in-2025-76ea74c15800>
2. OWASP Cheat Sheet Series：<https://owasp.org/projects/cheat-sheet-series>
3. PortSwigger Web Security Academy：<https://portswigger.net/web-security>；Learning Paths：<https://portswigger.net/web-security/learning-paths>
4. 中文生态：先知社区 <https://xz.aliyun.com>；websec.readthedocs.io：<https://websec.readthedocs.io>

Agent 工具服务与新课

1. MCP 发布报道（heise）：<https://www.heise.de/en/news/Model-context-protocol-Anthropic-wants-to-bring-AI-chatbots-out-of-isolation-10176872.html>；MCP 官方：<https://modelcontextprotocol.io>；MCP 授权规范（2025-06-18，OAuth 2.1 资源服务器）：<https://modelcontextprotocol.io/specification/2025-06-18>、<https://github.com/modelcontextprotocol/modelcontextprotocol/issues/43253>
2. Simon Willison，lethal trifecta（2025-06-16）：<https://simonwillison.net/2025/Jun/16/the-lethal-trifecta>；ChatGPT Atlas（2025-10-21）：<https://simonwillison.net/2025/Oct/21/introducing-chatgpt-atlas>
3. Invariant Labs，MCP 工具投毒（2025-04-01）：<https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks>；GitHub MCP confused deputy（2025-05-26）：<https://invariantlabs.ai/blog/mcp-github-vulnerability>
4. Microsoft MCP 间接注入防护指南（2025-04-28）：<https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp>
5. EchoLeak（CVE-2025-32711）arXiv 论文（外传经 Teams URL 预览代理路径经当日核对）：<https://arxiv.org/html/2509.10540v1>
6. JFrog，mcp-remote CVE-2025-6514（具体文章路径未逐字核验）：<https://jfrog.com/blog/>；Sweet Security，Agent SSRF（含 CVE-2026-92576 二手汇总）：<https://www.sweet.security/agent-security/ssrf-attack>
7. MCP Inspector CVE-2025-49596（正文未逐字核验）：<https://github.com/modelcontextprotocol/inspector>
8. Akamai/LayerX：Atlas 记忆投毒（2025-10-27）：<https://www.akamai.com/blog/security/layerx-identifies-vulnerability-in-new-chatgpt-atlas-browser>；Brave：Atlas Omnibox 注入分析（2025-10-29）：<https://brave.com/blog/atlas-omnibox-prompt-injection/>
9. OpenAI: Hardening Atlas against prompt injection（2025-12）：<https://openai.com/index/hardening-atlas-against-prompt-injection>；CyberScoop 报道：<https://www.cyberscoop.com/openai-chatgpt-atlas-prompt-injection-browser-agent-security-update-head-of-preparedness>
10. OWASP Top 10 for Agentic Applications for 2026（2025-12-09）：<https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026>；OWASP GenAI：<https://genai.owasp.org>；条目名称交叉核对用：Promptfoo OWASP Agentic AI 文档 <https://www.promptfoo.dev/docs/red-team/owasp-agentic-ai>
11. 华盛顿大学 Agent 浏览器安全研究（2026-06-30）：<https://www.washington.edu/news/2026/06/30/some-agentic-ai-browsers-come-with-major-cybersecurity-risks-uw-study-finds>
12. Johann Rehberger，ChatGPT Operator: Prompt Injection Exploits & Defenses（2025-02-17）：<https://embracethered.com/blog/posts/2025/chatgpt-operator-prompt-injection-exploits>

局限说明：全部事件节点均经 2026-10-31 当日检索核实（纵轴章与横轴章各自完成 WebSearch/WebFetch 核验，综合报告初稿未重新发起检索，仅对两章交叉核对了表述与链接）；按独立审读意见修订为最终稿时，另就下列条目当日重新检索核实并补入来源：Google/Calzavara 两篇 CCS 2016 论文的准确标题、作者与链接（初稿《Content Security Policy for Single Page Web Applications》标题经检索查无此文，已改为 ACM 收录题名）、Hannousse 综述（arXiv:2205.08425）、Amit Klein 2005 原文（原站 webappsec.org 已不可达，经 OWASP DOM Based XSS 词条参考文献 [1] 收录）、Rehberger Operator 演示（embracethered.com，2025-02-17）、DOMPurify 3.4.0/3.4.7 发布记录（GitHub releases 页逐字核对：3.4.0 含原型污染与过滤绕过修复、3.4.7 移除永久性 hook 污染）、Sec-Fetch-Site 重定向语义（W3C Fetch Metadata 规范 §4.1 原文核对）、6265bis 现状（2026-10-31 查询：RFC Ed Queue、等待最终批准，取代初稿"截至 2025 年 12 月仍在推进"的表述）、2025 Web Almanac CSP 统计口径（21.9% 为总体采用率，nonce 约 20%、strict-dynamic 约 10%，无单独"严格 CSP"统计）、OWASP Top 10:2025 类名（top10.owasp.org/2025 当日核对）、Agentic Top 10 条目（ASI01–ASI10，经官方页与 Promptfoo 等多方解读交叉核对，以官方 PDF 为准）；初稿"绕过微软 XSSF 限制"一语经检索查无公开出处（arXiv 论文全文不含该缩写），已改为论文记载的 Teams URL 预览代理外传路径；"微软命名 XSS""Netscape Cookie 1994""Samy 蠕虫""Chrome 80 默认 Lax""Passkeys 定位"等属行业背景共识或模型既有常识，均已标注；横轴章中标注"未逐字核验"的二手转述（GitLab 解读、JFrog 披露、MCP Inspector 细节、EchoLeak 披露综述链接缺失）在本报告中继承该标注；CrewAI SSRF 修复与 CVE-2026-92576 依赖安全厂商二手汇总；检索窗口截至 2026-10-31，其后事件不在覆盖范围内。