How We Discovered a Stored HTML Injection in a Chatbot System 🕷️
This write-up has been prepared under the guidance of Amish Patel, Lay Patel at Hacker4Help as part of our learning initiative on cybersecurity awareness.
🔍 Introduction
As budding cybersecurity enthusiasts, we’re always on the lookout for vulnerable systems that can help us learn and sharpen our skills. One casual evening of testing led us — Het Patel and Kaif Shah — to discover a Stored HTML Injection vulnerability in the chatbot feature of redacted.co.in, an AI-driven platform that connects users with verified professional experts across various categories.
So Let’s get started 😎
What is Stored HTML Injection? 💥
Before we dive into the juicy details, let’s break down what Stored HTML Injection actually is (because not everyone speaks fluent hacker 🤓):
Think of it like this: Imagine you’re at a restaurant and the waiter takes your order without questioning it. You ask for “spaghetti with a side of surprise ingredients” and the kitchen just… makes it. No questions asked. That’s essentially what happens with stored HTML injection! 🍝
Hence, Stored HTML Injection occurs when user-supplied HTML content is not properly sanitized and is saved in the application’s database. When this data is later rendered on a page, the HTML is executed directly, which could lead to defacements or further security issues such as phishing or XSS (if scripts are allowed).
This can lead to:
- 🎭 Page defacements (making websites look funky)
- 🎣 Phishing attacks (tricking users)
- ⚡ XSS vulnerabilities (if scripts sneak through)
The Setup: Where We Found It 🧪
While exploring the AI chatbot feature of pyng.co.in, we noticed an input field where users could send messages. At first, it seemed harmless — but our curiosity nudged us to test how it handled raw HTML.
Payload and Execution
We entered the following simple HTML tag as our message:
<h1>Hello from Het & Kaif</h1>To our surprise, when the chat history was loaded on page refresh or revisit, the message was rendered exactly as HTML — not escaped, not sanitized.
This confirmed a stored HTML injection — the HTML was being stored server-side and rendered client-side without any filtering.
We also tried several other payloads to confirm the injection:
<b style="color:red">XSS</b>
<i onclick="alert('XSS')">Click me</i>
<div style="background:red;padding:10px">Injected DIV</div>
<b style="color:red">XSS</b>However, since JavaScript execution was fully disabled, despite attempting multiple payloads and bypass techniques, we were unable to achieve any successful execution.
Screenshot of Payload Execution
📬 Responsible Disclosure
We followed responsible disclosure practices:
- Reported the bug to the redacted.co.in team.
- Shared steps to reproduce and suggestions to mitigate.
We did got the reply from support team:
They were already aware of the vulnerability so they marked our report as “Duplicate Submission” 😭
