How i converted a self-only HTML injection with chain 3 vulnarabality

Executive summary

During routine testing I discovered a self-visible HTML injection in an employee login interface. By iterative testing I converted that self-only injection into a reflected / victim-triggered vector and chained it with CSRF and an open-redirect path. The chain allows an attacker to force an employee’s browser — from a trusted company domain — to land on an attacker-controlled phishing page, increasing the likelihood of credential harvesting and account compromise.

This write-up describes the transformation process (self → reflected), the chaining technique, the realistic attack scenario, the evidence collected (PoC video), and recommended mitigations.

Affected components

Employee login page (input reflected into page HTML)

An endpoint that accepts or echoes unvalidated input (source of HTML injection)

A redirection parameter or handler that permits external destinations (open redirect)

A POST/GET endpoint lacking CSRF protections (used to auto-trigger the injection)

Note: URLs and screenshots have been redacted for disclosure policy compliance. I can provide private PoC artifacts (Burp logs / video) to the security team on request.

Background & motivation

At first the vulnerability appeared as a self HTML injection: injected markup rendered only in my session and was not trivially exploitable. Self-injection (self-XSS style) is often considered low impact, but small contextual changes can turn it into a real threat. My goal was to determine whether I could escalate the impact by: (1) making the injection affect other users (reflected / stored behavior), and (2) combining it with other weaknesses to create a realistic credential-theft scenario.

Methodology (high level)

I followed a systematic approach:

Characterize the injection

Identify where input is reflected in the page (querystring, POST body, hidden field, error message).

Determine which HTML constructs are allowed (plain tags vs. script/event attributes) and what is filtered by the WAF.

Convert self → reflected

Locate a second request path that accepts input and reflects it in a way that can be triggered by a remote victim (for example: a POST endpoint with no CSRF checks, or a URL parameter that is rendered back into HTML).

Use a crafted request that injects the benign HTML payload via that path; then craft a remote trigger (CSRF or auto-submit form) such that a victim’s browser causes the server to render the injected HTML in the victim’s session.

Chain with redirection

Identify any open redirect or redirection mechanism that can be pointed at an external domain. If a dedicated redirect parameter exists, verify whether it is whitelisted or allows arbitrary external destinations.

Combine the injected HTML (or an injected <meta> tag or anchor) with the redirect to send victims to an attacker-controlled domain.

Proof of exfiltration (safe PoC)

Host a non-malicious demo page (attacker domain) that visually resembles a login (for demonstration only).

Capture a PoC video showing: victim clicks/visits the crafted link; browser follows the redirect from the trusted domain to the demo phishing page; fake credentials typed into the demo page are captured in a Burp Collaborator or other test sink (use only test accounts and dummy data).

Proof of Concept (summary, non-executable)

Initial observation: an input reflected HTML (self visible) rendered markup in the response. The WAF blocked direct script execution but allowed basic tags.

Reflected activation: by submitting the same payload via a different endpoint that can be triggered remotely (no CSRF token or predictable state), I forced the server to render the injected HTML in another user’s session. This turned the self injection into a reflected vector.

Redirection & phishing: the injected content triggered a redirect to an attacker domain (proof used evil.example as a placeholder). On the attacker domain, a benign demo login form collected test credentials and the PoC captured the HTTP request on Burp Collaborator.

Video evidence: a short recording shows the victim path: (1) visit legitimate company URL, (2) automatic redirection or click causes navigation to attacker demo page, (3) dummy credentials submitted and captured in Burp. No real employee credentials were used.

I can provide the Burp logs and video privately to the security team on request.

Impact

Credential theft: Because the initial trigger originates from a trusted company domain, users are much more likely to trust the landing page and enter credentials.

Phishing at scale: The chain can be automated (via CSRF) so victims do not need to actively paste or execute payloads — simply visiting a crafted URL or page can trigger the flow.

Internal compromise risk: Compromised employee credentials may allow access to internal systems, leading to privilege escalation, data exfiltration, and lateral movement.

Realistic exploitability: Although the WAF blocks script execution, HTML injection plus redirect and CSRF is sufficient to perform convincing phishing without requiring JavaScript.