It's not client-side HTML injection. For it to be HTML injection, there would have to be attacker markup content written to the DOM. There's not here, only the static string
The DOM is now loaded and can be manipulated. which is written using the safe method
text() which does not permit markup.
There is an injection problem happening here, but it's only Selector Injection. The JS string variable
t is being copied into a CSS selector attribute value at JS runtime. Characters that are special here include
] (which ends the attribute value) and backslash (which introduces CSS escapes).
That's still a bad thing, but the worst you can do with a selector injection is make the application select the wrong element, for example:
resulting in the selector
which would, because of the reference to
<body>, replace the whole page with the text
The DOM is now loaded and can be manipulated.
Selector injections don't normally lead to DOM XSS. It's conceivable if you could target an element that the application then trusted to execute as code, such as a
<script type="text/template">. But when you don't have control of the string
The DOM is now loaded and can be manipulated. then there's not exploitation you can do, just annoyance.
You can fix selector injection by
\xxx-escaping characters in
t that are special in CSS. Better, where possible, is to avoid selector strings and their escaping problems by going straight to the element ID:
$(document.getElementById(t)) // works for any character in t
However in this case it seems hardly worth it as the attacks you can do with selector injection are by and large no worse than the deliberate functionality of letting an attack replace any named div with the text.