Reflective XSS via search box [Bypassing Cloudflare WAF].

Friendly
3 min readAug 25, 2021

--

On August 1, 2021 I decided to hunt a program on Hackerone — Redacted.

Like every bug hunter should, take a look at what’s in scope. I saw their main domain was in scope REDACTED.COM/. So I decided to take a look at their search box — Like every other bug hunter, I decided to try an HTMLi and I did get a result.
(Not too sure why no one continued to try and pry open this to XSS.)

I saw that I got an HTML injection where you can potentially get XSS. Decided to try some payloads and got WAF’d by their Cloudflare.

I then decided to look for

what kind of special or regular characters get filtered, removed or acts differently from their waf in place.

I decided to try a bunch of special character — !@#$%^&*()_+
I quickly noticed that anything after & and # was acting differently.

I then decided to see how each symbol works one by one — the & symbol in the search box turned to &=undefined and # removes everything after it.

Now I saw that and decided to craft a payload — The payload I made was “%3E%3Csvg onmouseover%3d”confirm(1"/%3E
TRANSLATION —
“><svg onmouseover=”confirm(1"/>

The reason for using URL Encoding is because the site rendered them in and wasn’t giving off any implications of the WAF being triggered. That being said, I had a full fledge working payload for XSS.

Though I ran into some issues when adding a parentheses at the end — “><svg onmouseover=”confirm(1)”/> didn’t want to trigger XSS, Cloudflare once again got into my way. Now remember those characters that were acting strange on the site? Yes & and #, I decided to then incorporate that into my payload with also using some 7 dec. The 7 dec wasn’t rendering in and the &# symbols were pawns to not removing or modifying my reflective xss inputs.

Now, the final payload looked a little something like this —

%22%3E%3Csvg%20onmouseover%3d%22confirm%26%230000000040document.domain)

Which finally lead to the almighty divinity alert —

I’d like to remind you all that this payload bypassed THEIR security waf and that’s because how this site handles inputs, characters and parsing. Yes it did bypass their WAF, but you also need to keep in mind that it won’t work on most sites because every site handles every input differently, that includes their regex.

Cool, bounty right? Turns out the report is duplicated and on their program — they decided not to fix the issue. The issue is till on going for 2 years.
People have reported HTMLi injections — but haven’t really pushed for XSS. The guy who reported it, got $250 but the issue is still at hands.

Nevertheless, this is the full report and how it was done.

Two years. . . Worth disclosing.

Check out the server — Discord.gg/bugbounty

--

--