Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was trying my hands at DOM based XSS. I came across a scenario where user controlled string from the URL is included in javascript as below

var userControlled=substring of URL;

URL is something like http://mydomain/param1=qwerty where I can enter any value for param1 and system would not complain

Note: Value of param1 does not directly appear anywhere in the response but it is used using DOM

or can be http://mydomain/param1=qwerty#sadsdsdsd

I was just wondering is there a way to redirect user to a different domain or execute a script or anything which can help me execute a successful XSS attack. Or any other attack for that matter.

share|improve this question
Hello Sachin, please give some more details as it is quite of hard to guess, what you are aiming at. DOM means "Document object model" and is basically the hierarchical collection of all the elements and attributes that make up an HTML document. Therefore it is unclear what you mean by something being part of the DOM but not part of the response. Is it written to the DOM by JavaScript code? If yes, what does the code look like? –  Hendrik Brummermann Nov 21 '11 at 13:16
@Hendrik Brummermann♦ don't worry about it man, this js snip isn't vulnerable to dom based xss. –  Rook Nov 21 '11 at 15:33
@Rock, that's why I am asking for the relevant parts of the code. –  Hendrik Brummermann Nov 21 '11 at 17:02
Thanks @Rook Hendrik –  Sachin Kumar Nov 22 '11 at 5:40
I'm not so sure it's not vuln. to XSS (we don't how if the string is properly escaped). I see 3 potential vectors here: (1) get out of string [param1=";alert(1) ] , (2) start new script param1=[/script][script]alert(1)[/script], (3) maybe you can put object instead of string [ param1={valueOf:function(){alert(1)}} ] –  Krzysztof Kotowicz Nov 22 '11 at 23:01

3 Answers 3

This snip of JS is not vulnerable to DOM based XSS. I recommend using the DOM Snitch plugin for auditing applications for DOM based XSS.

share|improve this answer
Ok lets leave DOM XSS aside, do you see any thing else that is wrong with this? –  Sachin Kumar Nov 22 '11 at 7:01
@Sachin Kumar if window.location was being fully controlled then it would be an invalidated redirect, but as it stands its completely safe. –  Rook Nov 22 '11 at 7:44
All downloads for DOM Snitch are marked as deprecated at its site. Can you recommend other methods for finding DOM-based XSS? –  Andrey Botalov Sep 4 '13 at 7:07

This snippet of code suffers does not have an XSS flaw but it does suffer from parameter splitting. It allows the user to specify extra GET parameters which can allow escalation of privileges when the request carries credentials such as a CSRF token in an earlier parameter or authorization cookies.

For example, if userControlled is


then the browser will GET /abc/xyz?param=&start-world-war-iii=true with the user's cookies.

It's probably low risk since assigning window.location leads to a GET request which rarely have side-effects that can be abused by the carried credentials.

To mitigate this, userControlled should be normalized:

window.location="/abc/xyz?param=" + encodeURIComponent(userControlled);
share|improve this answer
Good explanation, great solution to fix this. A nitpick: "leads to a GET request which rarely carries credentials" - I suspect you mean "which rarely causes side effects". GET requests often carry credentials, via the cookies that are sent along with GET requests. –  D.W. Nov 23 '11 at 0:58
@D.W. Quite right. Edited. –  Mike Samuel Nov 23 '11 at 1:23

While Mike's answer is correct in that the provided example is not vulnerable to DOM-based XSS, his proposed attack is unnecessary as an attacker who can get a user to click his particular link could also just get a user to visit the /abc/xyz?param=&start-world-war-iii=true location directly.

If for example the code looked more like this, it would be vulnerable to DOM-based XSS:

var userControlled = document.location.hash.slice(1);
var s = "<script>document.location='/path/to/thing/" + userControlled + "';<\/script>";

Then there are several things you can do. While it might be immediately obvious to use something like /path/to/target?param=value#alert('xss');' to break the location change while still being able to execute JavaScript, one can also use something like /path/to/target?param=value#'%2b(alert('xss2'),'value')%2b' which will still perform the location change but will also run JavaScript while concatenating together the new location string.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.