Home / Knowledge hub / Dangling markup
Knowledge hub
Dangling markup
Injected HTML that never closes, swallowing the page after it and sending it out.
What it means
Dangling markup injection is a way to steal content using HTML that is deliberately left unclosed. The attacker injects something like an image tag with an open quote, and the browser treats everything up to the next matching quote as part of the address, then requests that address from the attacker's server.
No script runs. The page text after the injection point, which might hold a token or a private message, simply travels out inside a web address.
Why it matters
It matters when script injection is blocked but HTML injection is not. A strict content security policy may stop scripts, yet an image or form request to an outside host can still leak data such as an anti-forgery token or an email address.
That can be enough to make the next step possible, for example using a stolen request token to complete a forged action. Teams that closed the XSS hole and forgot the HTML injection behind it are exposed.
How it shows up
It appears wherever user input is written into a page without proper encoding, particularly in a spot followed by sensitive content: a name above a form, a banner above a token. Email clients and admin pages that show user text are common places.
The mistakes repeat. Output is encoded for text but not for attributes. The policy restricts scripts but leaves images and form targets open. Check output encoding in every context, and add img-src and form-action rules so a stray tag cannot send content to arbitrary hosts.
Questions people ask
Dangling markup, answered
Is dangling markup the same as XSS?
No. XSS runs script in the victim's browser. Dangling markup only needs HTML to be injected, and it leaks data through an ordinary request.
It is often used when a policy blocks script.
Does a content security policy stop it?
Partly. Limiting where images, forms and other resources can load from, through directives such as img-src and form-action, narrows the routes for sending data out. A script-only policy does not.
Encoding output is still the primary fix.
Do browsers protect against it?
Some. Browsers have added protections such as refusing to load resources whose address contains raw newlines and less-than characters in some cases. That raises the cost for attackers but does not remove the flaw.
Do not rely on it.
What data can it steal?
Anything in the page after the injection point and before the next matching quote: tokens, email addresses, messages, hidden form values. It cannot reach data held elsewhere, such as cookies marked HttpOnly.
The risk depends on page layout.
How do we find it?
Look for places where user input appears in the page just before something sensitive, then test whether an unclosed tag causes the following content to be sent to another host.
It is easiest to spot when you can read both the code and the rendered page.
Sources
Where this comes from
Related
Terms that sit next to this one
HTML injection
Getting your page to render markup an outsider supplied, even without running scripts.
XSS
An attacker's script running in your pages, in your customers' sessions.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Content Security Policy
A header telling the browser which scripts a page may load.
CSRF token
A secret value in each form that proves the request came from your own page.
What sits below your user input?
Injection points that look harmless can still leak data. We find vulnerabilities in web apps and APIs, prove each by exploiting it, and show the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.