Modern apps try to make everything easy. A feedback feature feels pretty harmless, right? Yeah, I thought the same until curiosity led me to something much bigger.

It Started with a Simple Observation

While testing an application, I came across a feedback submission feature.

The workflow was straightforward:

• A user submits feedback via a form
• The application processes it
• The same feedback is emailed back to the user

At first glance, nothing unusual. No sensitive action. No visible reflection. No obvious impact.

But in security testing, "nothing interesting" is often where things begin

Digging Deeper: What Happens to My Input?

I started with basic input testing. Instead of plain text, I tried injecting HTML:

<a href=https://google.co.in><b>malicious link</b></a>

Observation:

• The application accepted HTML without sanitization
• The payload didn't reflect on the web UI
• But it rendered perfectly inside the email

That changed things.

Now, the application was: 1. Taking my HTML 2. Embedding it into an email 3. Sending it from a trusted source

First Crack: HTML Injection in Emails

This wasn't just HTML injection it was HTML injection inside a trusted communication channel.

That means:

• Clickable attacker controlled links
• Delivered via legitimate application emails
• No suspicion from the victim

Still, this alone felt like low to medium impact.

So I kept digging.

Second Crack: Something Felt Off with Requests

Next, I shifted focus to request behavior.

I captured the feedback submission request and generated a CSRF Proof of Concept (PoC).

POC:

To validate:

• I created the PoC using Account A1
• Then executed it while logged in as Account A2

Result:

The request was accepted.

The application:

• Did not validate CSRF tokens properly
• Relied on weak or missing cookie protections
• Allowed cross user request execution

This confirmed a classic: CSRF vulnerability due to improper request validation

The "Aha" Moment Chaining the Bugs

Individually:

• HTML Injection = Low/Medium
• CSRF = Medium

But together? That's where things got interesting.

Full Exploitation Flow

Here's how the attack unfolds:

1. Attacker crafts a feedback payload with a malicious HTML link
2. Generates a CSRF PoC for the feedback endpoint

POC

3. Tricks the victim into visiting the malicious page

4. CSRF silently submits the feedback on behalf of the victim

5. Application processes it as legitimate

6. Victim receives an official email from the application

7. Email contains the attacker controlled clickable link

Why This is Dangerous

This is not just a bug. It's a trust abuse chain.

The victim:

• Receives an email from a trusted application
• Sees content that appears to be their own submission
• Clicks a link that feels completely safe

This opens doors to:

• Phishing attacks
• Credential harvesting
• Redirection to malicious websites
• Social engineering at scale

The Key Insight

The most important lesson here: Impact is not defined by individual vulnerabilities, but by how they interact.

What looked like:

• A harmless feedback feature
• A non reflective input field

Turned into:

• A fully weaponized attack chain using trust, automation, and user behavior

How to Fix This

To stop this kind of attack, a few simple things can make a big difference:

1. Handle User Input Safely

• Always clean (sanitize) and encode user input
• Don't allow raw HTML in emails

2. Add Proper CSRF Protection

• Use strong CSRF tokens
• Check origin and referer headers
• Set cookies with proper SameSite settings

3. Secure Your Emails

• Treat email content as untrusted
• Avoid adding user controlled HTML directly into emails

Until next time, if you like this blog, stay connected. I'll keep sharing knowledge here don't forget to follow.

https://medium.com/@abhisheksutar730