Daily Bug Challenge: Cafe Club

Hey everyone — Yeti here
I recently joined a daily web-app challenge platform called Bug Forge, and they drop fresh daily and weekly hacking challenges to keep your skills sharp.

Naturally, I had to jump in.

Today I’m sharing my walkthrough of the Café Club challenge — a fun exercise that shows why staying flexible during testing matters.

Let’s dive in.

Step 1 Visit the site

When we land on the target, we’re greeted with a login page.

Nothing fancy — just a standard authentication portal.

That’s actually perfect.

Whenever approaching a new web app:

First goal = get legitimate access

Because authenticated access often exposes:

• additional endpoints
• APIs
• hidden functionality
• user-specific data

Step 2: Create an account

I registered a normal user account.

This is an important early pentesting habit:

Always understand the application as a real user first.

Jumping straight into attacks without understanding functionality often wastes time.

Step 3: Explore the site

After logging in, we see a coffee shop ordering interface.

Looks like we can:

• browse products
• view item pages
• place orders

Simple, clean, and realistic.

(Yeti approves of any app involving coffee ☕)

Step 4: Notice the item #

While browsing items, I spotted something interesting:

The URL included a numeric identifier, something like:

/product/4

This immediately raises two possibilities:

IDOR risk — Can we access other users’ resources by changing IDs?
Injection risk — Is this parameter safely handled by the backend?

At first, I leaned toward IDOR testing.

But good hunters don’t tunnel vision.

Step 5: Run Burpe Suite and capture the request

Next, I opened Burp Suite, enabled interception, and browsed the product page.

Burp captured an API request containing the product ID parameter.

This is where we shift into deeper testing.

Instead of guessing manually, I exported the request into a file:

req.txt

This allows us to use automated tools like SQLmap.

Step 6: Run SQLmap

Inside the request file, I placed a SQLmap injection marker (*) on the ID value:

That tells SQLmap:

“Test this parameter for injection.”

Then I ran:

sqlmap -r req.txt --batch --dump

SQLmap began testing the parameter and…

Boom. Vulnerable.

Step 7: Search for the flag

SQLmap confirmed the parameter was injectable and allowed database enumeration.

From there I was able to:

• list database tables
• dump user credential data
• locate the flag stored in the database

Mission accomplished.

Victory:

Challenge complete.
Points earned.
Coffee metaphorically consumed.

Why this is important

This was a great reminder that:

• Initial assumptions can be wrong
• Multiple vulnerabilities can exist
• Flexible testing wins

I started thinking:

“This might be an IDOR.”

But instead of locking onto one path, I pivoted to:

👉 Injection testing

And that’s what solved it.

Real pentesting isn’t linear.

It’s exploratory.

Final thoughts

Bug Forge seems like a fantastic platform for:

• daily web hacking practice
• building methodology
• sharpening tool usage

If this is the level of their challenges, I’ll definitely be doing more write-ups.

More snowstorms coming soon.

Stay curious. Stay sharp. Stay frosty. ❄️
— 404Yeti