Bypassing Cloudflare WAF: XSS via SQL Injection

Humble beginnings: SQL injection

October 2022 – while surfing the web, for some divine reason, I tried to play with the search query parameters on a pretty .well-known Estonian site that sells computer parts and IT accessories.

It turned out you can change the perpage URL parameter to any arbitrary number outside the intended selection, e.g. to 1, and it indeed does have an effect:

"Hmm.," mine own mind wenteth, and mine own dram nasty fing'rs append'd a doubleth quote " to the perpage paramet'r without much bethought...

... and voilà! You have an error in your SQL syntax

Actually, more like uh-oh – seems like a possible SQL injection attack vector (possibly via the LIMIT clause). We get broken styling and an error message educating us of the database management system in use, MariaDB.

Are we in this easily to a website this big?

No, we're not in yet. (The damn WAF!)

While manually trying to get some light info like the database version, to my surprise, Cloudflare's WAF (Web Application Firewall) page popped up:

I'm not sure what were their intentions having a WAF in place – were they already aware of the fact there was a possibility to do harm? Or just in case?

Most importantly, with having such a firewall in place, did we arrive at a dead end?

Reflected XSS to the rescue

Let's recap. We got:

1. an error message displaying our input;
2. any SQL commands getting filtered out by the Cloudflare WAF.

Let's look at 1. again and concentrate on our input.

The most important realization of the century this case was that while we couldn't use SQL commands, we could insert any other arbitrary text (like 1"lalala test <div/> 123) into the above discussed perpage parameter, also meaning into the error message. And guess what? The error message was not escaped! Meaning almost any HTML could be injected.

Success: bypassing Cloudflare WAF

Cloudflare still didn't like the <script> tag and some other shenanigans I tried (like the <img> tag), so I had to resort to my last lifeline... getting in contact with Google Search.

This is what I found:

<Svg Only=1 OnLoad=confirm(1)>

So the final payload was:

perpage=1"><Svg Only=1 OnLoad=confirm(document.domain)>

And (drumroll...) it worked!

Possible risks & consequences

I got changing location to google.com (notice the backticks) and using fetch to work, but stopped there. Redirect example:

perpage=1"><Svg Only=1 OnLoad=document.location.assign(\`//google.com\`)>'

What else? Well, anything we can do with JavaScript™, right? Some ideas:

• Steal credentials: redirect the victim to a fake duplicate of the site's user/admin login, Facebook login, or some Estonian banking site login
• Steal money: redirect the victim to a fake duplicate site of [redacted] or inject some rogue JS that attaches itself to the real site, to gain illicit benefit from users ordering
• Plain old adware/malware

Plus a chance there's some clever WAF-bypassing SQL payload to drop all the database tables or do something else damaging to the business, its people, and its customers.

Time to report!

Seeking contact

I emailed them responsibly (asking for the right person to talk to about their website's security) twice in October 2022.

I got a reply to my second attempt that they forwarded my message to the correct department, but that was the last time I heard from them.

The (implied) reason for ignoring the messages became apparent in January 2023: they had totally Pimped Up their site.

The Big Revamp

Surprise, surprise! New site, new tech stack, vulnerability no more.

That at least seems to be the reason I was ignored, because why bother with a random dude "wanting to talk security" if you're getting a new site soon? We have Cloudflare WAF anyway, right? If something's not burning, why bother?

One last oopsie – I didn't take any screenshots.

Getting the screengrabz

I postponed writing about this, since I was not going to share an active exploit in the wild. Then the Great Website Leap Forward came out of nowhere and I didn't have any actual Proof of Concept (PoC).

Their main site, [redacted].ee, was indeed totally upgraded, but most fortunately for our beloved readers, I did a bit of a googling again and stumbled upon a nice one – they still had their old site up on a few other domains like [redacted].lv, which is the one used in the screenshots above. Yay!

5 lessons learned

1. Google it. Might help! (after:YYYY-MM-DD search operator was useful here)
2. Take screenshots & save logs while testing things out. Things might change, pages might get wiped out.
3. Perseverance and combining attacks may lead to a nice pwn.
4. Don't always expect a positive reaction or an answer at all.
5. And most importantly, I shall have not inserted a random double quote into a query parameter on a page I do not have permission to mingle with :)
   I.e. that doesn't have any Responsible Vulnerability Disclosure Program (RVDP) or a bug bounty program.

I have done light redactions to demonstrate the technicalities of the attack, not highlight a particular business. Their new webpage is quite fab actually, so nice work!

Feature image made with DALL·E 2 by OpenAI + a little Photopea, a nice online Photoshop alternative I can honestly recommend.