从SVG到XSS：如何发现真实漏洞赏金目标中的存储型XSS漏洞

第一步：创建两个账户 - 受害者与攻击者

为了测试应用程序，我创建了两个独立的账户：

受害者账户：模拟受漏洞影响的普通用户 攻击者账户：用于执行攻击和测试应用程序行为

每个账户都使用不同的电子邮件地址注册，并使用两个不同的浏览器会话（或无痕窗口）登录。这样可以让我从双方与系统交互而不受干扰。

这种设置很重要，因为我想模拟真实的攻击场景 - 攻击者注入恶意输入，受害者随后与之交互并触发有效载荷。

第二步：共享笔记功能与上传恶意SVG

设置好攻击者和受害者账户后，我开始测试应用程序中允许用户通过共享笔记进行协作的功能。

两个账户都被添加到同一个笔记中 - 这意味着它们都可以查看和交互其内容。这是测试用户生成的输入或上传内容是否可能被滥用的完美场所。

此时，我想测试平台如何处理文件上传，特别是像SVG文件这样不常见的类型（已知在未正确清理时支持嵌入脚本）。

✅ SVG上传被接受

令人惊讶的是，应用程序允许我上传.svg文件，没有任何客户端或服务器端验证阻止它。这是第一个危险信号。

因此，我制作了一个简单的恶意SVG文件，其中嵌入了以下XSS有效载荷：

1
2
3
4
5
6
7
8

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
  <script type="text/javascript">
    alert("XSS by Essam");
  </script>
</svg>

从攻击者账户上传SVG文件后，我导航到包含上传图像的笔记并执行以下操作：

右键单击 → 在新标签页中打开

立即… ✅📸 alert(“XSS by Essam”)按预期触发，确认SVG中的有效载荷成功执行，存储型XSS正在工作。

第三步：切换到受害者账户 - 有些不对劲

我切换到受害者账户并打开同一个共享笔记。但奇怪的是，图像不可见 - 没有缩略图，没有损坏的图标…什么都没有。

乍一看，似乎什么都没有。

但是然后…👀 当我在页面上移动鼠标时，我注意到一条细蓝线 - 悬停效果。

出于好奇，我将鼠标悬停并右键单击它 → “在新标签页中打开”

🚨 砰 - XSS有效载荷从受害者的角度执行。

第四步：尝试窃取Cookie 🍪

确认XSS有效载荷从受害者账户触发后，我想稍微提升影响。

因此我修改了原始有效载荷：

1
2
3
4
5
6
7
8

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
  <script type="text/javascript">
    alert(document.cookie);
  </script>
</svg>

🔥 这样，如果成功，我将能够泄露受害者的会话cookie - 这是更危险的影响。

但是… Cookie没有显示

当我再次在新标签页中打开图像时，警报触发… 但document.cookie为空。

因此我得出结论：

要么cookie设置了HttpOnly（无法通过JavaScript访问） 要么会话在新标签页中的图像加载中没有共享

仍然是有效的存储型XSS

尽管无法访问cookie，但这仍然是一个明确的存储型XSS漏洞。