Yes, DOM-based XSS is still a concern. While some issues cannot be exploited due to URL encoding, there a number of situations where URL encoding will not stand in the way of exploitation.
The gist of the example is to form a hashbang query with injection
That's one example, but DOM-based XSS encompasses all XSS issues that result from insecurely ...
This page is taking input from an untrusted source, and directly outputs it in the browser as HTML.
In this case, the untrusted source is window.name. To the inexperienced programmer, this may seem harmless, but in reality, it can be set to any arbitrary value, because it's derived from the name of the frame:
setAttribute() is safe in that it does nothing more than setting the attribute's value. Even by using special characters in the string you cannot inject an additional attribute (as you attempted in your third snippet), let alone escape the HTML tag.
Some attributes are dangerous for some elements. As you demonstrated, on* attributes are vulnerable because ...
Yes, it is vulnerable if document.theform.reference[id].value can be a value controlled by another user.
window.location.href = url;
would cause the script to be executed in the context of the current domain for whichever user is currently using the site.
Updated browsers will encode the referrer URL.
So your examples will not work to trigger XSS nowadays.
document.getElementById("cat").innerHTML = decodeURIComponent(document.referrer);
The other way to get hold of another window is to pop it up. You can specify the window name in the second parameter:
var victim= window.open('http://example.com/vulnerable', '<script>alert("boom");<\/script>');
This code snippet is vulnerable to XSS in jQuery prior to 1.9 (and in conjunction with the jQuery Migrate plugin). Even now, it remains at least a bad practice.
The string argument to $() (shortcut for jQuery()) can be parsed either as a CSS selector or HTML code. Parsing the string as HTML implies an XSS vulnerability, just as document.write() would. On ...
This is reflected XSS, not DOM-based XSS.
The difference is subtle, but here are the key sentences.
OWASP - DOM Based XSS
the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
A classic example:
There's more than just normal Hex encoding! There's also Hex Entities.
Is equal to:
As you pointed out, it is also ...
The following code is vulnerable to DOM based XSS, because the attacker-controlled value of document.referrer is tracked by the browser:
<script src="' + document.referrer + '"></script>
The code above can be exploited using a page that upon first load redirects the browser to your target, on the 2nd load it returns an XSS payload. One way ...
Yes, if a path containing script tags is resolved to the page containing this code on your server (for example, via a rewrite rule) then script could be rendered in your page. This will be DOM based XSS as it will be your client-side code that is adding the script tag.
The method .text() seems more adequate/safer to solve the functional requirement of echoing the window.name in the page DOM.
from jquery docs:
We need to be aware that this method escapes the string provided as
necessary so that it will render correctly in HTML. To ...
XSS only happens when data is output.
In your code sample you are setting the variable myhash to the hash value in the address bar. As your code doesn't contain any sinks and your variable is not output, the above code, in isolation, is not vulnerable.
However, to check for XSS vulnerabilities you need to focus on output to your application rather than ...
DOM based XSS vs Reflected XSS
Should I interpret this as Reflected XSS means being able to injecting <script> tags in an HTML context, and DOM based XSS means being able to inject payload inside an already existing <script>?
Reflected XSS means that your injected payload is reflected into the answer delivered by the server and executed ...
Both codes are vulnerable, but neither is exploitable with most modern browsers.
In the first example, could exploit the echoing of REQUEST_URI. Exploitability depends on the browser not automatically encoding values before sending the request (see XSS via REQUEST_URI). Host Header Injection may also be possible.
In the second example, the code is ...
The page you refer to has the following code:
<p id="p1">Hello, guest!</p>
var username = searchParams.get('name');
document.getElementById('p1').innerHTML = 'Hello, ' + username + '!';
Your expectation is, that setting username to <script>alert(1)</script> should result in <p id="p1">Hello, <script&...
Is \ converted to \\? If not, break out of the string using \"; it'll be converted to \\", which will be treated as a sole (escaped) backslash and then a string-terminating quotation mark.
Inserting a newline will break the string, but also break the JS application. If you don't have some way to recover from that - such as the ability to insert a new script ...
I would start playing with variations of alert(1) and see if ...
That would be hard to exploit without combining it with another vulnerability. How would the exploit code get into the input? I suppose combining it with UI-redressing or something like that could have worked, but I dont see any clear way of exploiting it. Could be seen as a self-XSS.
If the script ...
Are there any other attacks that I didn't consider?
To prevent the single quote form getting encoded, you could try to sneak your payload into the path instead of the query string. For example, if the vulnerable page resides at http://example.com/path/vulnerable.php you could try something like this:
Since the payload is going from the victim's browser to the server and
coming back to the browser, how is this not reflected XSS instead?
In that example, it is not going to the server to come back as XSS.
This was a pretty common XSS attack vector in jQuery, and can still affect sites using an outdated version of jQuery.
Basically, if a string was an invalid selector, jQuery would assume it was HTML, and parse it as HTML. In jQuery version 1.9 jQuery mitigated this risk by only parsing a string as HTML if it started with &...
The result works the same as:
Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice.
Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers).
While zero day vulnerabilities may exist in the various browser rendering engines ...
I do not necessarily have control over ...