Tag Info

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: <iframe src="http://www.domxss.com/...

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. 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.

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)>?

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: <p&...

$("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 ...

There's more than just normal Hex encoding! There's also Hex Entities. <script>alert("xss")</script> Is equal to: &#x3C;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3E;&#x61;&#x6C;&#x65;&#x72;&#x74;&#x28;&#x22;&#x78;&#x73;&#x73;&#x22;&#x29;&#x3C;&#x2F;&#x73;&...

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 ...

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. e.g. https://www.example.com/foo/bar/<script>alert('foo')</script>

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 ...

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 ...

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>? No. 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> <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&...

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 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 ...

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.

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 ...

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/...

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....

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 &...

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&...

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("...

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 ...

If you need to take this approach then why not remove everything apart from alphanumerics and the space character? i.e. go for a whitelist rather than a blacklist. You do not know how standards in HTML and JavaScript may change in future so only allow the characters likely to be good instead of disallowing known bad. I do not necessarily have control over ...