Finding Cookie Based XSS
网站注销处抓包
1 | https://example.com/login?redirect=/hello |
修改数据包
1 | REQUEST: https://example.com/login?redirect=asd';javascript:alert(document.domain) |
进行上述尝试之后,我们分析了其源代码,结果发现https://example.com/login
页面已刷新,并且GET
请求已发送到中继器。然后提交请求以查看页面的源代码。
在分析源代码时可以看到,利用前面URL中的参数redirect提交的值现在已经反射到了源代码中。这很奇怪,因为该请求是在没有任何重定向参数值的情况下向登录页面发出的。
在分析源代码过程中还可以看到,redirect
参数的值被存储到了cookie redirect
中。
1 | Request: |
现在,为了测试XSS漏洞,payload已被修改为在script
标记之间插入一个警报框,具体如下所示:
1 | Payload: asd ';alert(document.domain)//asd |
如果使用浏览器呈现Burp收到的响应,将会弹出警报框。
Converting Cookie-Based XSS to Reflected XSS
根据我们的观察,redirectTo
cookie会将自身的值设置为URL中参数redirect
的值。
1 | Flow: example.com/login?redirect=hello ---> 跳转到example.com/login (Cookie: redirectTo=/hello) |
所以,我们可以通过URL中的redirect
参数将cookie设置为payload。
如果直接将redirect
参数设置为payload的话,是无法直接触发该payload的。这是因为该应用程序具有如下所示的保护机制:
URL中有重定向参数:写入的脚本在登录后重定向到指定的路径
URL中没有重定向参数:写入的脚本重定向到cookie中指定的路径
因此,为了将基于cookie的XSS转换为反射型XSS,必须按顺序发送两个请求:
- 通过redirect参数设置cookie 。
- 再次打开登录页面,注意,这次不要使用redirect参数。
CSRF POC
1 | <script> |
上面的代码将执行以下操作:首先,它会将GET请求发送至https://example.com/login/?redirect=asd ‘;alert(document.domain)//asd
,后者会将 redirectTo cookie设置为/asd';alert(document.domain)//asd
。
经过一段时间后,它会向https://example.com/login
发送另一个GET请求,并附带cookie中的payload ,从而触发该payload,将其转换为反射型XSS。
至此,基于cookie的XSS就被转换成了反射型XSS。目前,这个漏洞已经被Synack接受,并且仍处于分类阶段。
本文至此就结束了,希望能够对大家有所帮助。
转自: