0

I know there are some questions around open redirects but with this one I have some additional questions. In order to not release the assets I am going to replace the asset with "exampleeee.com".

There is a vulnerable parameter redirectURL that leads to an open redirect on an asset. When going to let us say: https://www.exampleeee.com/Test?redirectURL=https://www.exampleeee.com:[email protected], we will be redirected. So it is vulnerable.

When we delete the ":80", we get an error page as it should be. So: https://www.exampleeee.com/Test?redirectURL=https://[email protected], will not work.

Why will ":80" make it work and do we have a combination of a SSRF attack and an open redirect attack?

Sorry for this question but I can't figure it out.

Thanks in advance!

1 Answer 1

2

Without the source code for the server in question, nobody can say for sure what's going on. However, the most likely answer is that somebody got a little carried away with URL parsing, and added support for a mostly-deprecated feature of URLs but didn't account for it when writing their redirect validator.

URLs can contain a username and (optionally) a password between the scheme and the domain. The overall format looks like this:

[scheme:][//[username[:password]@]domain[:port]]path[?key=value[&key2=value2[...&keyN=valueN]]][#fragment]

Since the password portion is optional (and rarely used; I think no modern browser even supports it anymore) even when the username portion (itself quite rare) is used, it's strange that the redirect works with that but fails without it. Any URL-parsing library that understands the format above should be able to correctly identify "maliciouswebsite.com" as the domain in both URLs you supplied. I suppose it's possible somebody rolled their own parser and they made the same mistake you did, thinking that the colon is only used to denote the port, and therefore they didn't need to keep scanning for the @ sign?

Good find on the open redirect, though. It's almost certainly not an SSRF - the server presumably either rejects the URL outright or returns it to your browser in a Location: header; in neither case is it likely to make the request itself - but you can test for that. Point it at a listener you have set up and see if the server tries to connect. Also, I'm curious whether, if you put :443 (the actual port for HTTPS; 80 is for plain HTTP), that changes the behavior at all.

You must log in to answer this question.

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