Analytics Gone Wild

We recently encountered a fun interaction between an analytics solution and protections from Cloudflare. This isn't a particularly likely or impactful issue, but it is certainly an annoyance.

Creating a session based DOS with analytics cookies?

Ever wondered if you could take advantage of those tasty tracking cookies everyone uses for various purposes? So many of them exist, and modern analytics on sites track such a wide range of data. There are the obvious potentials for stealing information, but recently on an engagement we observed a method of creating a denial of service (DOS) condition with the behavior of an analytics cookie, and Cloudflare.

A very tiny background on Analytics

Analytics tools are pervasive in web applications, and are used to collect, measure, and analyze data about user behavior and interactions on a website. These tools help website owners understand how users engage with their site, what content is popular, and how to improve the user experience. One such example of this is the Adobe Experience analytics platform which just so happens to be what we took advantage of in our scenario. Now on to the fun part!

Using Cloudflare to cause a DOS condition

Cloudflare has a well know and highly effective web application firewall (WAF) utility within their services. If you have been working on testing an application and submit common SQLi or XSS payloads you will be familiar with this screen:

This is of course intended to stop an attacker from submitting these payloads, but as we know not all data comes from the same source so there is always a possibility that we may be able to get payloads into an application past the WAF. In our scenario this was possible, and the application did appropriately output encode the payloads so no XSS was present.

However, we found this block could trigger a new problem for users still. When navigating the site certain actions such as clicks were stored in a cookie from Adobe Experience, the cookie being called s_sq, and one area we could inject information was into comments which have a clickable box to show more information. Unfortunately, when a user goes to the list and clicks to see the comment they do not trigger the XSS itself, but store its payload into the s_sq cookie. At this point any further requests to the domain until the browser session is killed, or the container is destroyed, will send this cookie as a normal browser behavior, and Cloudflare will block the user from access.

While this particular issue was more educational than practical for most purposes, it is still a potential way to abuse the normal behavior of your applications against your users. Implementation flaws can happen anywhere, and unique interactions between various tools can lead to frustrating results at times for developers and users alike. At McCormack Cyber Solutions we strive to hunt down and eradicate as many unique flaws as possible in your systems. If you would like to learn more about how we can help you please reach out!

Are you looking for a security assessment for your network or applications? Send us an email at info@mccormackcyber.com