53
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 ...
12
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:
<iframe
src="http://www.domxss.com/...
5
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 ...
5
Yes, it is vulnerable if document.theform.reference[id].value can be a value controlled by another user.
If this value was set to javascript:alert('xss') by an attacker then the line
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.
5
Updated browsers will encode the referrer URL.
So your examples will not work to trigger XSS nowadays.
Try this:
<div id="cat"></div>
<script>
document.getElementById("cat").innerHTML = decodeURIComponent(document.referrer);
</script>
JSFIDDLE:
http://jsfiddle.net/y4afy8h9/1/?<img%20src=x%20onerror=alert(9)>?
4
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>');
4
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 ...
3
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:
<p&...
3
$("div[id="+t+"]")
That's not JavaScript injection. For it to be JS injection, the attacker-supplied value would have to be written into the JavaScript code from the outside (for example in a server-side templating language or eval in JS itself). That's not happening here, there is no dynamically-generated JavaScript. There's just a plain string ...
3
There's more than just normal Hex encoding! There's also Hex Entities.
<script>alert("xss")</script>
Is equal to:
<script>alert("xss")</s&...
3
No it's not vulnerable to XSS based on the provided information. The interpolated URL query parameter token has quote marks escaped (\" instead of just ") so you cannot break out of the string. Because of this it is impossible to inject executable code, opposed to simply changing the content of a JavaScript string variable.
As you pointed out, it is also ...
3
This is more injection than XSS, but Mailto links have a few features that you can abuse. For example, instead of the email program popping up with just the TO filled out, you can pre-fill the CC, BCC, Subject, and Body. This is done by editing the query string, e.g. ?subject=xyz&cc=other@example.com.
My first thought was that window.location.hash would ...
2
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 ...
2
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.
e.g. https://www.example.com/foo/bar/<script>alert('foo')</script>
2
The method .text() seems more adequate/safer to solve the functional requirement of echoing the window.name in the page DOM.
<script>
$("div").text(window.name);
</script>
from jquery docs:
http://api.jquery.com/text/
We need to be aware that this method escapes the string provided as
necessary so that it will render correctly in HTML. To ...
2
To put it simply, you can't because your your payload bob); alert(1 is a string, and JavaScript knows its a string so it won't execute it. The parenthesis and semi-colon characters can be inside the string without being executed. This code could be vulnerable if, for example, you tried to concatenate the payload into an eval() statement. This is because eval ...
2
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 ...
2
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>?
No.
Reflected XSS means that your injected payload is reflected into the answer delivered by the server and executed ...
2
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 ...
2
The page you refer to has the following code:
<p id="p1">Hello, guest!</p>
<script>
...
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&...
1
You would maybe be able to do it if the charset was not atypical, and then you may be able to get a valid result by using a multibyte character converting into an equals sign, but you can't change the charset yourself as it will probably appear in the server response header, or default to UTF-8.
In Section 12.1.2.1-3 of the HTML standards, tags have to be ...
1
I haven't used the new DAST scanner, but it seems like it injected (dkezib%2527%2522``'"/dkezib/>xrpjqc&) into the input field / variable, ran the javascript, and found that it reached the eval() without being escaped. Usually that's all the ingredients you need for javascript injection.
I would start playing with variations of alert(1) and see if ...
1
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.
1
First the browser hands over the incoming data to the HTML parser, that starts working from the top of the document and down. This can happend even before the document has finnished downloading. As soon as the HTML parser comes to a script tag, it hands over the content to the JavaScript engine that start executing the code right away.
If the script ...
1
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:
http://example.com/'onerror='payload/..%2Fpath/...
1
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.
The vulnerable code is in Javascript:
<script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href....
1
This was a pretty common XSS attack vector in jQuery, and can still affect sites using an outdated version of jQuery.
https://bugs.jquery.com/ticket/9521
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 &...
1
This won't be problem as long as st_val is NOT under the client control. As you know, if you are setting value of the window.location.href variable it will redirect current page to the new value. If attacker set javascript:alert(1) value to the st_val this will be end up with DOM XSS.
For example;
<html>
<meta charset="utf-8"/>
Hello
<script&...
1
The string t is not being eval'd, it is a literal string. String concatenation just creates a new string, you have a similar situation to a simple var y = 'Hash: ' + location.hash.slice(1); which doesn't open an XSS vector. It just assigns the hash to a variable in Javascript.
The result works the same as:
$("div[id=#message]\");alert('test');//]").text("...
1
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
