Hello guys,

My first post was about a 2FA bypass and people asked about the caching issue, so here it is.

Before I start, I saw some people downvoted my first post, all good but please leave a comment about what went wrong. It will help me improve my future writing.

This will be a long post explaining the logic behind the finding. You'll need a basic CDN knowledge. It is crucial to understand it instead of blindly trying random exploits.

Since I have many caching reports, this is one of my latest findings. It covers two issues. The first one I found was interesting but completely outside scope, so instead of moving on or reporting something out of scope, I dug further to find something acceptable. But let's start from the beginning.

I was testing caching behavior on a large e-commerce platform with regional domains across 30+ countries, I will call it redacted.

The first thing I noticed:

/%0a, which is a newline character, returned a completely different 404 than a normal one, from a different internal path. Could be from a WAF or different error handling, without the source code I can only guess. So what was interesting there? The headers. It showed public cache for 4 hours.

What should we test before moving on? Since I am testing caching issues, the thing to try is whether the CDN and backend agree on this path or not.

The first request I sent:

redacted/%0a/%2e%2e?buster

What happens here? The backend sees redacted/%0a/%2e%2e?buster and returns that different 404 page I mentioned earlier. The CDN on the other hand normalizes /%0a/%2e%2e and resolves it back to /, so from the CDN perspective this is just redacted/?buster. Since the response is cacheable, the CDN stores that 404 under the cache key redacted/?buster.

Now let's verify:

redacted/?buster

As expected, the same 404 error, while for example redacted/?blah returned the normal homepage, confirming the CDN cached that specific key.

Notice the ?buster, this is just a random param added by me for a cache key, it's important when testing these cases. Without it you could take the entire website down, which is very bad for you.

After checking their policy, DoS was outside scope. Now what?

Knowing the backend and CDN behave differently, web cache deception should be straightforward from here.

While authenticated I checked the 404 pages. They returned some user information but the responses were not cached, even with a static extension like /nonexistent.ico. After further investigation I noticed the CDN only cached static resources returning a 200 response. Knowing from the first finding that the backend and CDN disagree, it was easy to build on that:

redacted/blah/%252e%252e/favicon.ico

What do we have here? Ignore the double encoding for a second. %252e was necessary for the browser since it normalizes single encoding %2e to . before sending the request. With double encoding it arrives at the server exactly as intended:

redacted/blah/%2e%2e/favicon.ico

Anyone visiting this link will have their email and API token stored in the cached response for 4 hours. Why? The backend sees redacted/blah/%2e%2e/favicon.ico and returns a 404. But the CDN sees redacted/blah/../favicon.ico, so it normalize it to redacted/favicon.ico, an existing static file, exactly what we needed, so it caches it.

The user info exposed was not obviously sensitive at first, so I checked the source code to understand what the token was used for. It turned out to be for an external service managing your profile, purchase history, full name, email, lifetime spend, referral code, payout email and more. Since user interaction is required the CVSS impact is high. The bounty was somewhere between medium and high with no explanation, it's not much but it give good experience and at least they fixed both issues. The first finding I included as an additional note since for an e-commerce platform at that scale it should be fixed, and they agreed.

If you made it this far, I would love to hear what you want next. Some ATO writeups or findings I discovered just by reading disclosed reports?
What we learned:
Forget scanners

Test manually

Focus on logic flaws
Stop hunting broad, start going deep

Pay attention to responses that are not what you expect

xlord91

From a Weird 404 to Data Exposure