How can i cause a redirect in browser?

Question

I'm able to edit a parameter which is then reflected inside a link. I'd like to know how and if it's possible to cause a redirect. In shorts when i edit the parameter example like this example=/test.com that value is reflected in generated link like: www.example.com/test.com but when i open the link the browser loads www.example.com- Is it possible to make it load test.com instead?

I tried using @test.com but that generates a 500 error message. It seems that there's a check in place that blocks everything if you don't use the slash symbol first. For example /@test.com is accepted but not @test.com - How can i inject in a way that once the link is clicked i get a redirect to test.com?

Breaking down the request/responses:

For /@test I receive a 500:

{
    "statusCode":500,
    "error":"Internal Server Error",
    "message":"An internal server error occurred"
}

And if I try with /@test.com I get this:

{
    "success":true,
    "link":"https://www.example.com/@test.com"
}

Answer 1

It looks like the have some basic input checking going on that is rejecting your response (although it is always possible that your @ is actually generating an error on their end for some strange reason).

Since it allows a request with an @, just not as the first character, I'd try a few things:

1. Try using a URL-encoded @ which is %40. If their input checking logic has some flaws it make make it through and allow a valid payload.
2. Also, credentials can come with a username and password. A colon is used to separate the password. Therefore try this something like this: :[email protected]. If you're lucky that will result in https://www.example.com:[email protected] which should accomplish what you want.
3. Like before, also try with an encoded colon, just in case: %3Auser%40newdomain.com

However, I'm just guessing at what their input validation rule is. In cases like this it becomes a guess-and-check to try to figure out what they are checking for, and then some more guess-and-check to find a payload that circumvents their rules and also gives you something useful.

It's possible that the actual rule is that the URL must begin with a front-slash. In that case you are probably left modifying the URL to only point to arbitrary URLs on the target domain, which is less fun. I check this by attempting simple payloads like test (without any special characters or slashes). If that also gives a 500 then they probably require starting with a front-slash, in which case I think you will be stuck. It's also possible that they always concatenate your payload with a forward-slash, in which case (again), you are probably stuck. That would be the case if you inject test and they return https://www.example.com/test.