1

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"
}
5
  • You say that the parameter is reflected in the value but the fact that clicking the link goes to the wrong place makes me suspect that it may not actually be doing what you think. An important step in cases like this is to examine the raw response from the server - not what you see by using things like inspect element or even hovering over the link. The latter things show the browser's understanding of the returned HTML, and can hide small but important differences. Mar 11 '20 at 19:25
  • As a result it would help if you could include the actual HTML returned by the server (again, not by using something like inspect element - view source and copy, or use something like curl to retrieve it). Also note that you aren't trying to cause a redirect - you are simply trying to change a URL. A redirect would make the browser go to the new URL without any action from the user. Mar 11 '20 at 19:26
  • @ConorMancone, something like this would do the redirect www.example.com@test.com, the problem is that it only accepts www.example.com/@test.com. I'm trying to add something after www.example.com/ to redirect to test.com once the link is clicked. I tried with html code too but looks filtered.
    – apex
    Mar 11 '20 at 19:28
  • We can't see what you are seeing. Your best bet to getting an answer is to post the raw response. Ah, I also understand more now - you're trying to get the link to go to a different domain all together (by turning the actual domain into a username). Again, that's not called a redirect - your'e just trying to change the link. Regardless, please edit your question to include an example payload you are injecting in and the raw response from the server for the a tag in question. Mar 11 '20 at 19:31
  • @ConorMancone, If i try with @test.com the response is the following: {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"} While if i try with /@test.com i get this: {"success":true,"link":"https://www.example.com/@test.com"}
    – apex
    Mar 11 '20 at 20:39
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: :user@newdomain.com. If you're lucky that will result in https://www.example.com:user@newdomain.com 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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