00:00:00
资料库 · 认证、会话与令牌
第 ③ 卷，条目 41–60。来源以 PortSwigger Research 为主，另有浏览器与平台厂商的安全公告。
这一卷讲的是身份：怎么证明你是你、怎么在多次请求之间维持这个证明、以及这个证明怎么被偷走或伪造。
有一条规律贯穿全卷：认证协议的实现漏洞远多于设计漏洞。SAML、OAuth、JWT 的规范本身大体是可用的，出问题基本都在"某个实现对某个字段的处理和另一个实现不一样"——和 第二卷 是同一个母题。
SAML 与签名验证
41. The Fragile Lock: Novel Bypasses For SAML Authentication
来源：PortSwigger Research，2026 年。
读它解决什么：SAML 认证的新绕过手法。
要点：
- SAML 认证的新型绕过，标题把它比作"脆弱的锁"
- 2026 年发表
我的补充：SAML 是企业 SSO 的主力协议，一旦绕过，影响面是整个组织的所有应用——这是它比单个应用的漏洞严重得多的原因。SAML 之所以脆弱，根子在于它用 XML 签名：XML 有 canonicalization（规范化）、namespace、注释、DTD 等一堆特性，导致"签名覆盖了哪部分内容"这件事出奇地难判断，历史上 XML Signature Wrapping 系列漏洞反复出现。防御建议很实际：不要自己实现 SAML 验证，用经过审计的成熟库并保持更新；配置上锁定预期的 IdP 证书（不接受断言里自带的证书）；有条件的话迁到 OIDC——它基于 JWT，签名覆盖范围明确得多。
42. SAML roulette: the hacker always wins
来源：PortSwigger Research。
读它解决什么：SAML 实现问题的另一组案例。
要点：
- SAML 相关的攻击研究，标题暗示成功率之高
- 与第 41 条同一研究方向
我的补充："庄家总赢"这个说法不夸张——SAML 的实现空间大，多数部署里总能找到某个环节的处理差异。给防御方的具体检查清单：断言的签名是否被验证（有实现在某些配置下会跳过）、签名覆盖的是否是整个断言（而不是只有一部分，剩下的部分可被篡改）、Recipient/Audience/NotOnOrAfter 是否被校验（不校验受众等于允许把给 A 应用的断言拿去登 B 应用）、断言 ID 是否做了重放检查。这四项里任何一项漏掉都能导致完整绕过，而它们在配置里通常都是可关的。
43. Introducing SignSaboteur: forge signed web tokens with ease
来源：PortSwigger Research。
读它解决什么：一个用于测试签名令牌强度的工具。
要点：
- 发布 SignSaboteur 工具，用于伪造签名的 Web 令牌
- 定位是安全测试工具
我的补充：这类工具存在的意义是证明弱密钥的可行性——它主要针对的场景是签名密钥太弱（默认值、短字符串、可爆破）。防御要点：签名密钥必须是足够长的随机值，从密钥管理服务读取而不是写在配置文件里（更不能写在代码里——这个博客的 git 历史里就躺着两个泄露的第三方 API key，同一个教训）；令牌里的算法字段要服务端强制，不能信任令牌自称的 alg（alg: none 和 RS256 降级成 HS256 用公钥当 HMAC 密钥，是 JWT 最经典的两个坑）；密钥要能轮换，设计时就得支持多密钥并存（kid 字段）。
Cookie 安全
44. Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
来源：PortSwigger Research。
读它解决什么：__Host- 与 __Secure- 前缀本该提供额外保证，这条讲它们如何被绕过。
要点：
- 绕过
__Host-和__Secure-cookie 前缀的保护 - 这两个前缀的设计目的是强制浏览器施加额外约束
我的补充：先说这两个前缀本来的作用：__Secure- 要求 cookie 必须带 Secure 标志，__Host- 额外要求不能带 Domain 属性（也就是不能被子域覆盖）。它们解决的是子域名 cookie 投毒——攻击者控制了 evil.example.com 就能给 example.com 写 cookie，覆盖掉主站的 session。这条研究说明这层保护也有绕过。防御含义：这两个前缀该用（成本为零），但不能当唯一防线。真正的根本措施是不要让不可信内容跑在你主域的任何子域上——用户内容放独立域名（这也是为什么 GitHub 用 githubusercontent.com、Google 用 googleusercontent.com）。
45. Stealing HttpOnly cookies with the cookie sandwich technique
来源：PortSwigger Research。
读它解决什么：HttpOnly 本该让脚本读不到 cookie，这条讲一种绕过技术。
要点：
- 用"cookie 三明治"技术窃取
HttpOnlycookie HttpOnly的设计目的是阻止 JS 读取 cookie
我的补充：这条打破了一个非常普遍的依赖：很多人认为"设了 HttpOnly，XSS 也偷不走 session"。技术上说 HttpOnly 只阻止 document.cookie 读取，绕过路径包括让服务端把 cookie 回显出来、或者利用解析差异让 cookie 的边界错位。但更根本的一点：即使 HttpOnly 完全有效，XSS 也不需要偷 cookie——攻击者可以直接在用户的浏览器里以用户身份发请求（cookie 会自动带上），该做的操作都能做完。所以正确的心态是：HttpOnly 降低损失，不改变"有 XSS 就已经失守"这个结论。别把它当作可以容忍 XSS 的理由。
46. Bypassing WAFs with the phantom $Version cookie
来源：PortSwigger Research。
读它解决什么：一个 cookie 相关的 WAF 绕过手法。
要点：
- 利用
$Versioncookie 属性绕过 WAF $Version来自早期 cookie 规范，现已基本废弃
我的补充：这里的机制是历史遗留特性造成的解析分歧：WAF 按现代规范解析 cookie，而某个后端组件还认老规范里的 $Version 语法，于是同一个 cookie 头被两边切成不同的键值对。WAF 检查的和后端接收的不是同一个东西，规则自然失效。防御上的通用结论：WAF 是缓冲不是修复。它给你争取打补丁的时间，但绕过手法层出不穷（这一整卷里 WAF 相关的绕过就有好几条），所以别用"WAF 挡着"作为不修漏洞的理由。同时值得清点：你的技术栈里还有哪些组件在支持早已废弃的协议特性。
47. Protecting Cookies with Device Bound Session Credentials
来源：Google 安全博客，2026 年 4 月。
读它解决什么：cookie 被盗后如何让它在攻击者机器上失效。
要点：
- 介绍设备绑定会话凭据（DBSC）
- 目标是让窃取到的 cookie 无法在其他设备上使用
我的补充：这是这一卷里最有价值的防御性条目，因为它针对的是当前最主流的攻击形态。现在的信息窃取木马不再费劲破密码——直接偷浏览器里的 session cookie，绕过所有 MFA（cookie 代表的是已认证状态，不需要再过一次验证）。DBSC 的思路是把 session 绑定到设备上的私钥（理想情况在 TPM 里），服务端定期要求用私钥签名来证明"还是那台设备"，于是拷走 cookie 的人用不了。这是近年 Web 认证领域最实质的进展之一，方向上和 passkey 一致：让凭据不可复制。有条件的话跟进它的部署，同时短期内可做的是缩短 session 有效期加上异常地理位置/设备指纹检测。
跨域凭据窃取
48. Detecting web message misconfigurations for cross-domain credential theft
来源：PortSwigger Research，2022 年。
读它解决什么：postMessage 配置不当如何导致跨域凭据泄露。
要点：
- 检测 web message（
postMessage）的配置错误 - 后果是跨域凭据被窃取
我的补充：postMessage 有两个方向都容易错，而且都很常见。发送侧：postMessage(data, '*') 里那个 * 意味着任何嵌入你的页面都能收到这条消息——如果 data 里含 token 就直接泄露了，正确做法是写明确的目标 origin。接收侧：onmessage 处理函数不校验 event.origin，于是任何页面都能给你发指令，等于开了一个无认证的 API。这两个都是一行代码的疏忽造成高危漏洞的典型。审计方法很直接：全局搜 postMessage( 看第二个参数，搜 addEventListener('message' 看有没有校验 origin。这是我做前端安全审计时的固定检查项。
49. Stealing passwords from infosec Mastodon - without bypassing CSP
来源：PortSwigger Research，2022 年。
读它解决什么：CSP 配置完好的情况下密码仍被窃取的真实案例。
要点：
- 从 Mastodon 实例窃取密码，且未绕过 CSP
- 标题强调"不需要绕过 CSP"
我的补充："不需要绕过 CSP"是这条的重点——它说明 CSP 的威胁模型不覆盖所有窃取路径。密码字段的内容可以通过表单行为、样式条件（第一卷第 18 条）等不涉及脚本执行和外部资源加载的方式泄露。防御上值得注意的是浏览器密码管理器的自动填充：它会往页面上任何长得像登录表单的地方填凭据，包括攻击者注入的隐藏表单。所以登录页面对 HTML 注入的容忍度必须是零——其他页面上的 HTML 注入可能是中危，登录页上就是高危。
50. Safari is hot-linking images to semi-random websites
来源：PortSwigger Research，2022 年。
读它解决什么：浏览器自身的行为导致的意外请求与隐私影响。
要点：
- 发现 Safari 会向半随机的网站请求图片
- 属于浏览器行为异常而非站点漏洞
我的补充：这条提醒的是浏览器自身也是攻击面的一部分。浏览器的一些"贴心功能"（预取、猜测补全、图标抓取）会发出你的代码没有请求过的网络请求，可能泄露用户在访问什么。对防御方的实际含义有两点：一是排查异常流量时要记得有这类来源，别一律当成攻击；二是如果你的 URL 本身带敏感信息（比如一次性重置链接放在 query string 里），任何这类意外请求都可能把它泄露给第三方——所以敏感令牌不要放 URL，放 POST body 或 header，URL 会出现在日志、Referer、浏览器历史和这类预取请求里。
51. Using Hackability to uncover a Chrome infoleak
来源：PortSwigger Research，2022 年。
读它解决什么：借工具探测 JS 环境，发现浏览器层面的信息泄露。
要点：
- 用 Hackability 探测工具发现 Chrome 的信息泄露
- Hackability 是用于枚举 JS 环境可达对象的工具
我的补充：这条的方法论值得学：枚举而不是猜测。与其猜某个环境里有什么可利用的对象，不如自动遍历整个对象图看能到达什么。这个思路可以正向用在防御上——如果你在做沙箱（iframe 隔离、vm 模块、插件系统），用同样的枚举方式检查自己的沙箱有没有意外暴露宿主能力，比人工审计可靠得多。沙箱逃逸的常见形态就是"某条不显眼的原型链或某个全局对象通往外面"，人眼看不全。
52. The curl quirk that exposed Burp Suite & Google Chrome
来源：PortSwigger Research，2023 年。
读它解决什么：一个 curl 的怪癖如何影响到两个成熟产品。
要点：
- curl 的一个行为怪癖影响了 Burp Suite 与 Chrome
- 说明基础工具的行为差异会传导到上层产品
我的补充：这条是依赖链风险的一个干净例证：底层库的一个不起眼行为，被两个高质量产品分别继承，成了两个漏洞。给防御方的含义：安全评审不能只看自己的代码，得看自己对依赖行为的假设是否成立。特别是那些"我以为它会拒绝非法输入"的假设——很多库出于向后兼容会容忍畸形输入并做出某种解释，而你的安全判断依赖于它拒绝。这也是 第二卷 那条主线在库层面的版本：不一致产生漏洞。
53. Drag and Pwnd: Leverage ASCII characters to exploit VS Code
来源：PortSwigger Research。
读它解决什么：编辑器也是攻击面，这条讲 VS Code 中的一类利用。
要点：
- 利用 ASCII 字符攻击 VS Code，涉及拖放操作
- 目标是开发者工具本身
我的补充：开发者的工具链是高价值目标——攻破一个开发者的编辑器，可能拿到源码、云凭据、以及往生产环境推代码的权限，性价比远高于攻击生产服务器。这类攻击的入口通常是"打开了一个不可信的项目"：VS Code 的 workspace 设置、任务定义、扩展推荐都可能在打开项目时自动生效。防御措施具体且有效：打开来源不明的仓库时用受限模式（Restricted Mode）、审查 .vscode/ 目录里的内容再信任工作区、开发机上的云凭据用短期令牌而不是长期 key。这条对天天 clone 别人仓库的人尤其相关。
研究方法与自动化
54. Hunting evasive vulnerabilities
来源：PortSwigger Research，2022 年。
读它解决什么：那些常规扫描发现不了的漏洞怎么找。
要点：
- 寻找"善于躲藏"的漏洞
- 前提是常规检测手段对这类问题无效
我的补充：这条对防御方判断自己的检测覆盖率很有用。规避型漏洞的典型特征是：没有明显的响应差异（所以扫描器的判定逻辑失效）、需要多步交互才能触发、或者依赖特定的时序。反过来说，如果你只依赖自动化扫描，这一整类问题在你的报告里是不存在的——这不是扫描器不好，是它的判定机制决定的。所以安全预算的分配要包含人工测试，而且要专门针对业务逻辑（自动化最难覆盖的部分）。
55. How to build custom scanners for web security research automation
来源：PortSwigger Research，2023 年。
读它解决什么：想把自己的检测思路自动化，这条讲怎么写自定义扫描器。
要点：
- 讲如何构建自定义扫描器以自动化研究
- 面向已有检测思路、需要规模化的人
我的补充：这条对蓝队同样适用，而且我认为价值更大。你最了解自己系统的特有风险（自研的鉴权中间件、特定的多租户隔离逻辑、内部约定的请求头），这些通用扫描器一定不覆盖。把这类检查写成自定义规则跑在 CI 或定期扫描里，是防御自动化里投入产出最高的部分——因为它检查的正是别人无法预知的东西。做法上从小开始：先把最近一次安全事故的模式写成一条检测规则，避免同类问题再次上线。
56. WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine
来源：PortSwigger Research。
读它解决什么：WebSocket 的安全测试工具，以及为什么 WebSocket 是"金矿"。
要点：
- 发布 WebSocket 测试工具，标题称 WebSocket 是未被充分挖掘的领域
- "goldmine" 指这里漏洞密度高
我的补充：WebSocket 漏洞密度高有明确原因：它绕过了大部分为 HTTP 建立的防护。WAF 通常只检查握手请求，不检查后续消息帧；CSRF 防护、CORS、速率限制这些机制大多是围绕 HTTP 请求设计的；而开发者在 WebSocket 消息处理里常常假设"能连上就是已认证的"。防御检查清单：每条消息都要做授权检查（不只在握手时检查一次，因为 session 可能在连接期间失效）、握手时校验 Origin（WebSocket 不受同源策略约束，CSWSH 攻击就靠这个）、消息级别的速率限制、以及消息内容的输入校验（很多人对 HTTP body 做了校验，对 WebSocket 消息完全没做）。
57. Repeater Strike: manual testing, amplified
来源：PortSwigger Research。
读它解决什么：怎么把手工测试的经验放大成可复用的自动化。
要点：
- 增强手工测试效率的工具与方法
- 定位是放大人工测试而非替代
我的补充："放大手工测试"这个定位是对的方向：判断力来自人，规模来自机器。纯自动化漏掉业务逻辑问题（第 54 条），纯手工覆盖不了规模。可迁移到防御侧的做法：把每次人工排查中"发现问题的那个判断"沉淀成自动化检查。比如你手工发现某个接口越权了，那就写一条自动化用例，用 A 的 token 去访问 B 的资源，断言必须 403——然后把这个模式套用到所有同类接口上。人工找到模式，机器负责覆盖全部实例。
58. Shadow Repeater: AI-enhanced manual testing
来源：PortSwigger Research。
读它解决什么：AI 怎么增强手工安全测试。
要点：
- 用 AI 增强手工测试的工具
- 与第 57 条同属提升测试效率的方向
我的补充：AI 在安全测试里目前最靠得住的用途是变体生成：你手工发了一个请求，它自动衍生出一批相邻的变体（改编码、改大小写、换参数位置、加冗余字段）去试。这一步纯人工做很枯燥且容易漏，而判断"哪个响应异常"仍然由人来做。这个分工和 编程卷第 90 条 说的 TDD 与代理的关系是一致的：让 AI 做覆盖，人保留判定权。要警惕的是别让它自动判定"这个不是漏洞"——假阴性在安全领域的代价比假阳性高得多。
59. Document My Pentest: you hack, the AI writes it up!
来源：PortSwigger Research。
读它解决什么：渗透测试报告写作的自动化。
要点：
- 用 AI 自动生成渗透测试文档
- 分工是人做测试、AI 写报告
我的补充：报告写作在渗透测试里占的时间比很多人以为的多（经常是三到四成），而且它是价值传递的唯一环节——发现了问题但报告写不清楚，开发方就不会修，整个测试就白做了。这类工具的合理用法是让它生成初稿（复现步骤、请求响应的整理、影响描述），人来核对技术准确性并补上优先级判断和修复建议。后两项是 AI 最容易写得空泛的部分，而恰好是收报告的人最需要的。别让它代笔严重性评级——那需要理解业务上下文。
60. Top 10 web hacking techniques of 2023
来源：PortSwigger Research，2024 年初。
读它解决什么：2023 年 Web 攻击面进展的年度综述。
要点：
- 2023 年度十大 Web 黑客技术评选结果
- 与第 20、40 条同一系列
我的补充：把 2023、2024、2025 三届连起来读，能看到一个清晰的趋势：竞态条件和协议层解析差异的比重在上升。这两类的共同点是它们都不在单个代码文件里——你 review 任何一个函数都看不出问题，问题存在于组件之间和时间维度上。这对安全评审的组织方式有直接含义：只做代码级 review 会系统性地漏掉这两类。需要补的是架构层面的 review（各层协议一致性、缓存键设计）和数据层面的 review（哪些操作依赖"先查后改"）。
本卷小结
三个带走的结论：
HttpOnly不是 XSS 的解药。 就算它完全有效，攻击者也能在受害者浏览器里直接以其身份发请求。它降低损失，不改变"有 XSS 就已失守"这个判断。- 偷 cookie 已经是主流攻击方式，MFA 挡不住。 session cookie 代表已认证状态，被拷走就绕过了所有验证。DBSC（第 47 条）和 passkey 走的是同一条路：让凭据不可复制。
postMessage两侧都要检查。 发送写明确 origin 而不是*，接收必须校验event.origin。这是一行代码的疏忽造成高危漏洞的典型，也是最容易自动化审计的一项。
上一卷： ← ② HTTP 协议与请求走私 · 下一卷： ④ 漏洞研究与利用链 →