0

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

var userControlled=substring of URL;
window.location="/abc/xyz?param="+userControlled;

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

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

Or the URL 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.

Improve this question
5
  • 2
    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
    Commented Nov 21, 2011 at 13:16
  • @Hendrik Brummermann♦ don't worry about it man, this js snip isn't vulnerable to dom based xss.
    – rook
    Commented Nov 21, 2011 at 15:33
  • @Rock, that's why I am asking for the relevant parts of the code.
    – Hendrik Brummermann
    Commented Nov 21, 2011 at 17:02
  • 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
    Commented Nov 22, 2011 at 23:01
  • The question title is very confusing. It sounds like this has nothing to do with the DOM. (However, I can't tell what "used using DOM" means. If the only use of the DOM is setting window.location = ..., then that's not what is usually considered DOM-based XSS.)
    – D.W.
    Commented Nov 23, 2011 at 0:57

4 Answers 4

Reset to default
4

This snippet of code 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

&start-world-war-iii=true

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);
Improve this answer
2
  • 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.
    Commented Nov 23, 2011 at 0:58
  • @D.W. Quite right. Edited.
    – Mike Samuel
    Commented Nov 23, 2011 at 1:23
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.

Improve this answer
3
  • Ok lets leave DOM XSS aside, do you see any thing else that is wrong with this?
    – Sachin Kumar
    Commented Nov 22, 2011 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
    Commented Nov 22, 2011 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?
    – Andrei Botalov
    Commented Sep 4, 2013 at 7:07
1

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>";
document.write(s);

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.

Improve this answer
-1

Yes, your sample is exploitable for DOM-based XSS to redirect a user. Here is a sample of a payload:

make_a_js_error;</script><meta http-equiv="refresh" content="0;URL='http://test.com/hack.html" />

We can make a js error on the page to stop regular JS behaviour on the page. Then user can be redirected with meta tag.

Here is a full sample:

<?php

$hostMain = '//test.com';
$myFile=basename(__FILE__);

$payload =
    <<<PLD
make_a_js_error;</script><meta http-equiv="refresh" content="0;URL='http://test.com/hack.html" />
PLD;
?><!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>XSS Sample</title>
</head>
<body>
<script>
    <?php if(isset($_GET['param'])):?>
        window.location = "<?php echo $hostMain . '/' . $myFile;?>/?param="+<?php echo urldecode($_GET['param'])?>;
    <?php endif;?>
</script>
<a href="<?php echo $hostMain  . '/' . $myFile . "?param="; echo urlencode($payload);?>">do redirect</a>

</body>
</html>
Improve this answer
1
  • I believe the point is that JavaScript is reading the URL parameter and setting window.location directly. As a result there is no room for escaping. You show the server processing the parameter and sending broken HTML. That would be a standard reflected XSS vulnerabilitiy which the OP said this is not
    – Conor Mancone
    Commented Nov 2, 2018 at 22:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .