未分类 · 2023年10月30日 0

XSS!一次对抗Akamai WAF的经历

背景介绍

本文将探索绕过Akamai WAF的复杂艺术过程,在本文中,不仅能够深入了解Akamai现有的安全机制,同时还将收获自己制作自定义Payload所需的知识与技能,希望通过阅读本文能让你像专业人士一样思考并增强你的Bypass技能。

故事开始

在一次渗透测试中,白帽小哥偶然发现了一个端点,其中的“returnUrl”成功的引起了他的注意!

file

作为渗透人员,每当遇到此类参数时都会顺手输入一个javascript:alert(1)

file

很遗憾,响应结果为403,显然是被拒绝了,于是白帽小哥开启分析模式,首先他将javascript:之后的所有内容做了删除,以此来检查是否有权访问javascript协议,幸运的是,端点并未对javascript进行屏蔽:

file

既然alert被阻止了,那么就尝试其它的看看:
javascript:prompt()
javascript:console.log()
javascript:eval()

遗憾的是,这些都被阻止了。看来该Web站点的安全措施还算不错的,当然,白帽小哥并未因此而放弃,他决定探索更为高级的JavaScript函数,以确定是否所有函数都被阻止,随后白帽小哥尝试了javascript:atob()String.fromCharCode(),结果依然被阻止。

经过很长一段时间的测试后,白帽小哥发现decodeURI()函数成功通过,这也为后续漏洞提供了潜在的可能。

file

来看看Mozilla关于该函数的说明:

decodeURI() 函数会对之前由 encodeURI() 或类似例程创建的统一资源标识符 (URI) 进行解码。

它的工作方式如下:本质上,当我们使用诸如 javascript:decodeURI("<h1>vita</h1>") 之类的函数,然后单击“Try Again”按钮时,我们可以看到解码后的 URI 的结果,该结果将显示如下:

file

现在是时候深入挖掘在 decodeURI 函数中插入 <img src=x onerror=alert(1)> 这样的Payload来实现 XSS了,但白帽小哥得到的响应却是:

file

即使没有onerror=alert(1) ,却仍然403,这表明 WAF 有效地过滤了恶意标签。

于是白帽小哥检查了所有标签,除了一个 <button> 标签外,所有标签都被阻止了!

file

于是白帽小哥尝试 <button>test</button> ,再次被阻止:

file

为了确定哪个处理程序触发了阻止响应,白帽小哥利用Intruder做了一次‘强力’测试:

file

只有onbeforetoggle能够bypass,接着白帽小哥利用PortSwigger网站,针对<button>标签和onbeforetoggle生成了Payloads列表,发现仅有两个可供利用:

file

白帽小哥立刻使用了这两个Payload做测试,但都没有成功,主要是因为 WAF 会阻止 alert(1) 。

如何解决这个问题呢?本质上,在“javascript:”之后,就可以声明变量了,于是白帽小哥发挥了一些创造力,将 alert() 函数划分为三个单独的变量,如下所示:
javascript: var a = 'ale'; var b = 'rt'; var c = '()'

然后,将这些变量连接到 decodeURI 函数内的字符串中,得到最终的Payload,如下所示:

javascript:var a="ale";var b="rt";var c="()";decodeURI("<button popovertarget=x>Click me</button><hvita onbeforetoggle="+a+b+c+" popover id=x>Hvita</hvita>")

file

bingo!