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.
can someone break my anti dom based xss from the window location ?
    function parseparameters()
    {
        var href = window.location.href;

        var id = href.indexOf('#');

        if (id < 0)
        {
            throw new Error("Error");
        }

        var hash = href.substring(id + 1);

        var spsp = hash.split('&');

        var thereturn = {};

        for (var i = 0; i < spsp.length; i++) 
        {
            spsp[i] = spsp[i].split('=');

            if (spsp[i].length == 2) 
            {
                thereturn[decodeURIComponent(spsp[i][0])] = decodeURIComponent(spsp[i][1]);
            }
        }

        return thereturn;
    }

thank you .

share|improve this question
4  
What are you doing with thereturn? This isn't an example of dom based xss, therefor there is nothing to break. thereturn can contain an xss payload. decodeURIComponent() is obviously not an escape function. –  Rook Mar 30 '13 at 20:42
add comment

closed as too localized by Rook, lynks, Terry Chia, Rory Alsop Mar 31 '13 at 19:59

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

You're basically asking, if your object creation through parameterized URL query can be exploited in such a way to load it with an XSS code. The short answer is not unless you plan on using this newly created object for anything. The long answer of course depends on what you plan on doing with this newly created object, will you be sanitizing its properties and function calls, and if you realize this code of yours has nothing to do with mitigation of XSS type attacks, and that it actually enables a potential exploiter to load any object you might be later referencing with malicious payloads and function calls. In essence, your code does nothing else but splits parameterized URL query after the # into an object structure:

this URL:

mywebsite.com#method1=document.location.href%3D%22do.not.ever.open.me%22

into this object:

var myObject = {
    method1 : "document.location.href=\"do.not.ever.open.me\""
};

Is this object safe to use? If you still don't know the answer, then my answer has to be: no!

Explanation:

As you didn't include how these values will be used later in your code, we can't really answer how safe they are to use. But you shouldn't consider them as any safer than a non-parsed hash part of your URI otherwise is, and at the same time does nothing for the rest of your URL, up until the # part of it.

Demonstration:

To demonstrate, where is the problem, imagine this scenario:

obj = new Object();
obj.something = parseparameters().method1;
eval(obj.something);

What happened is the web browser loaded the passed URI. Go ahead, it's safe to try it yourself, as I made it so it merely loads this location as a relative path to the opener document URL, resulting in mywebsite.com/do.not.ever.open.me location being requested. Changing it to fully qualified path, or indeed to change something else than merely load a new URI, is however still utterly trivial and using decodeURIComponent() doesn't change that a bit.

share|improve this answer
    
method1 is actually the string function(){document.location.href="do.not.ever.open.me"}. –  Gumbo Mar 31 '13 at 16:54
1  
@Gumbo - True, but that doesn't change anything for the answer. It all depends on how these properties will be later used, while the URL parsing itself does nothing to mitigate potential XSS type attacks. See Rook's comment if my answer is not as easy to follow. If you think the answer should be changed to be more factually correct, please feel free to suggest an edit, I certainly won't mind. But consider these strings will later be used somewhere, and we haven't got a clue how. Will OP be evaluating them? Loading as function calls? We just don't know, but fact remains:- it's not XSS safe. –  TildalWave Mar 31 '13 at 17:54
    
@Gumbo - OK I edited my answer to include further explanation why it does nothing to prevent XSS. I hope it's now clearer, even though it makes it a lot more speculative for the part where I had to assume a use-case for these strings being parsed into an object. Oh, and I cleared my answer from before a bit, so it's not confusing with for the example non-relevant strings. –  TildalWave Mar 31 '13 at 18:40
    
Your example still gives the wrong impression. Any user input is harmful if it’s evaluated. –  Gumbo Mar 31 '13 at 20:02
1  
@Gumbo - I find this to be a case of nitpicking now, really. What would you want me to add? All the possible XSS exploits for a code we don't have? I wanted to show this code from OP can carry a potentially malicious payload just as well as a URL that he's supposedly sanitizing with this code can. I believe I've managed to show that with, admittedly, speculative approach. Sadly, that's all we have to work with. If you have more information, then please don't hesitate to add your answer, but I'm done with mine. I don't feel there's anything left to say on the matter. –  TildalWave Mar 31 '13 at 20:39
show 1 more comment

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