A typical example for DOMXSS is that vulnerable code carelessly processes the part after the hash mark as in https://www.example.org/path/param1=val1&...#PAYLOAD_HERE without validation. For example, the string could be assigned via innerHTML to some DOM element. (Or one of many jQuery methods such as html(), before(), prepend() and several more.)
Now, comparing to Reflected XSS, where URL parameters, form parameters or other parameters (e.g. as part of a JSON-formatted body) may contain the payload, these are often input that can be entered into form fields. For instance, the URL https://www.example.org/?search=query is virtually always the result of the user entering query into a search field. (At least, that's the intended use case.) Now, it is possible to bypass the process of entering the query string into the form field by submitting the query-URL directly. Similar for POST, albeit this is a bit more complex (which is not the point here; for the sake of discussion I take it for granted that it is possible).
Thus, if the application is vulnerable to Reflected XSS through an input field, virtually always it is possible to craft a malicious URL that, when clicked, exploits the vulnerability.
However, it appears to me that this does not hold for DOMXSS. If an application had an input field that carelessly uses its content to update some DOM element without any validation whatsoever, then clearly one could inject arbitrary scripts into the DOM. Consider for instance a hypothetical app that has an input field with id input_field and a target element such as a p, div, span or whatever with id target, and JavaScript code with a line like this:
document.getElementById("target").innerHTML =
document.getElementById("input_field").value;
Here the content of the input field is not sent forth and back as would be for Reflected XSS.
The question for me is: Could that be exploited by an attacker (without exploiting a preceding XSS attack)?
