Some start with curiosity.
While testing a financial research platform, I was casually exploring features like a normal user. One feature that caught my attention was the Note — a place where users can upload files and save content while researching companies.
File uploads always raise security concerns. So I decided to dig a little deeper.
👀 Where the Suspicion Began
I started testing the file upload functionality step by step:
- Uploading images (
.png,.jpg) → ✅ worked as expected - Uploading dangerous files (
.php,.svg) → ❌ correctly blocked
Everything looked secure… until I tried something simple.
I uploaded a .html file.
No error. No warning. Upload successful.
That single moment changed everything.
💥 Why Allowing HTML Is Dangerous
HTML files are not harmless documents.
They are active web content.
If a web application allows users to upload HTML files and later serves them back with a text/html content type, the browser will execute any JavaScript inside the file.
That's exactly how Stored Cross-Site Scripting (XSS) happens.
📋 Proof of Concept (Sanitized for Public Disclosure)
⚠️ All domains are intentionally replaced with
example.com
Step 1: Access the Feature
- Log in to the application
- Search for any company
- Open the Note section
Step 2: Upload a Malicious HTML File
Create a file named xss.html with the following content:
<img src=x onerror="
alert('You have been hacked!');
window.location='https://example.com';
">Upload this file and save the Note.
Step 3: Trigger the Vulnerability
Click on the uploaded file.
✅ Result
- JavaScript executed immediately
- Alert popup appeared
- Browser redirected
🎯 Stored XSS confirmed
🚨 Real-World Impact
This vulnerability was far more serious than a simple popup.
An attacker could:
- Steal user session cookies
- Perform actions as the victim
- Redirect users to phishing pages
- Launch CSRF attacks
- Abuse trust inside a financial platform
All it takes is one uploaded file and one click.
🛠️ How This Can Be Fixed
Some simple but effective fixes include:
- Blocking
.html,.htm,.xhtmlfiles - Allowing only whitelisted MIME types
- Forcing downloads using
Content-Disposition: attachment - Never serving user uploads as
text/html
💰 The Reward
I responsibly reported the issue with a clear proof of concept and impact analysis.
🎉 Bounty awarded: ₹7,500 INR
A reminder that even simple logic flaws can have real-world impact and real rewards.
🧠 Lessons Learned
- File uploads are attack surfaces
- Blocking a few extensions is not enough
- HTML should never be trusted
- Server-side validation is mandatory
- Curiosity finds bugs faster than tools
🎯 Final Thoughts
This vulnerability wasn't discovered using advanced scanners or complex exploits.
It was discovered by:
- Exploring features like a real user
- Testing assumptions
- Asking a simple question: "What if?"
Sometimes, that's all it takes.
Happy hacking 🛡️🔥