Live Proof of Concept
Hello — this page is by Ali Faleh
A live demonstration of a content-injection vulnerability on our Shanashel platform. The page you are reading right now is hosted on our own production domain. Look at the address bar above.
I created this page on the Shanashel domain from an agent user.
Anyone with an agent user can do this.
Imagine if someone with some agent user creates a login page on our domain, but this page is designed to look like our real login page and steal our users' credentials, and he shares it via WhatsApp, email, or SMS.
Also imagine if he uses cross-site scripting to steal the session tokens of our users who click the link.
Many other possibilities exist.
How this is possible
The image-upload endpoint that agents use to attach property photos accepts any file and any declared Content-Type. When the file is fetched, our server returns it with whatever Content-Type the agent chose. If the agent declares text/html — the browser renders it as a webpage. This is exactly what you see now.
The URL points to our real domain. The padlock icon shows our real TLS certificate. To a user and to a victim, everything looks legitimate.
Concrete attack scenarios
→
Credential phishing on our own domainAn attacker creates a page that looks identical to our real login screen, then shares the link. The victim sees our domain and our brand — and enters their credentials, which go straight to the attacker.
→
Session-token theftThe attacker embeds code that exfiltrates the session cookie of any user who opens the link. They then impersonate that user across our system.
→
Open redirectsA page that automatically redirects to a malicious site, bypassing any system that allow-lists our domain as trusted.
→
Reputation laundering and malware stagingHosting malicious downloads under our TLS certificate. Browsers, antivirus engines, and reputation services trust our domain.
→
Search-engine poisoningCrafted pages can be indexed by search engines as part of our brand, damaging trust and SEO.
Why our existing defenses are not enough
Our Web Application Firewall blocks payloads that contain well-known malicious patterns, but it cannot stop arbitrary HTML rendering. A phishing form contains no malicious keywords — it is just HTML. The fix has to live in our application code, not in the WAF.
Recommended fix
Force the file-serving endpoint to respond with a safe Content-Type (such as application/octet-stream) and a Content-Disposition: attachment header. The browser then downloads the file instead of rendering it. This is a small, focused code change with a complete fix.
— Ali Faleh
This page was created as an internal demonstration for management awareness. Please escalate to the security team for remediation.