0

I'm trying to protect my code from XSS. I used a tool to identify risks and it alerted the following code part as a possible injection case.

var urlParams = new URLSearchParams(window.location.search);
var param = urlParams.get('param');
var newUrl = "/" + param + "/goto";
document.write("<a href="+newUrl+">Link</a>");

I played a little bit around with some payloads but I was not able to break out and inject any code which is executed*. I wonder if this was a false positive or did I just missed a payload which executes code?

Also, in the course of this I have changed my code a little to

var param = window.location.search.split('param=')[1];

I noticed that in the latter case the parameter is url-encoded, whereas this is not the case in the first example.

Does this happen with the split() method? I want to understand the differences.

Example with ?param="; alert(1);

First case: console.log(param) prints "; alert(1);

Second case: console.log(param) prints %22;%20alert(1);

*Update: I was able to find two payloads that work:

\\"<svg/onload=alert(1)>
</script><script>alert(1);</script>

But why doesn't they work for window.location.search.split('param=')[1]? It is save to just use this approach instead of the first one or are there possible payloads to bypass, too?

3
  • 2
    All what you show is an assignment to newURL which includes a user defined and unchecked value. This assignment by itself is not a problem, relevant is instead how newURL will be used after this assignment. But you don't show this part and thus the question cannot be answered. Commented Mar 14, 2020 at 9:11
  • 1
    Indeed, as Steffen says the important point is how you use it. The listed sections would require a vulnerability in JavaScript itself to cause issues. The only time this code could cause problems would be if it was on the backend. This wouldn't work for front end JavaScript Commented Mar 14, 2020 at 11:41
  • Thanks, I added how to use the newURL.
    – nullpointr
    Commented Mar 15, 2020 at 13:43

1 Answer 1

2

As Steffen pointed out in his comment already, you do not specify how you use the variable newUrl. An actual XSS vulnerability would trigger when using this variable in an insecure fashion in the HTML output.

You must also be careful when using the new code you are experimenting with:

var param = window.location.search.split('param=')[1];

This will return everything after param=. If there as another variable in the URL behind param, the full string will be returned, as you can see below:

URL:     http://example.com/?x=1&param=2&z=3
Command: window.location.search.split("param=")[1]
Result:  "2&z=3"

Depending on the actual usage of the variable, this might open up further exploit potential (e.g. circumventing filters). If an XSS attack is actually possible, must be evaluated based on the usage scenario.

1
  • The url assignment is only used to create a link in the form of document.write("<a href="+newUrl+">Link</a><br/>"); After playing around a bit I found two Javascript playloads that get executed in the first case: </script><script>alert(1);</script> and \\"<svg/onload=alert(1)> But they are not executed on the parameter obtained by window.location.search.split(), probably because it is automatically url-encoded. Is it secure or are there payloads to get around this?
    – nullpointr
    Commented Mar 14, 2020 at 18:06

You must log in to answer this question.

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