This post was originally featured on my blog.
NOTE: The content in this post is solely for educational purposes. Do NOT attack entities that did not provide consent beforehand.

The Repl.it team was kind enough to allow me to disclose this vulnerability. As stated by the title, I found an Open URL Redirection vulnerability in the company's web application. If you want to learn more about the nature of this type of vulnerability, here's an article that explains it.

Discovery

In the Computer Science department at my university, we regularly use Repl.it for rapid testing of ideas for our programming assignments, and in some classes we use it for official assignment submission. While logging in to the platform one time, I took note of a goto parameter in the login URL. The URL followed the form repl.it/login?goto={target_endpoint}, where {target_endpoint} is the location to which the user is redirected after logging in.

Exploitation

Because post-authentication redirection schemes that look like this are, at times, susceptible to Open URL Redirection, I tried visiting the URL repl.it/login?goto=https://example.com and logging in. To my surprise, I was redirected to example.com! Now that this case was validated, I tried finding methods of obscuring the destination URL. This is because a victim may notice the second, potentially malicious URL and choose not to visit the link. With that said, I tested several different ways to encode an URL and saw that most of the variations worked in place of the plain https://example.com.

Impact

Vulnerabilities of this type are typically used in a chain with others to exploit victims, but conceptually this can be used to redirect users to phishing sites or sites that exploit browsers to install malware on a victim's device. A bit more detail here.

(Not) Increasing the Impact

Some Open Redirect Vulns can also lead to Cross Site Scripting (XSS) attacks if the payload or, in this case, the destination URL is valid JavaScript. Fortunately, injecting script tags or javascript:{some-code-here} as the parameter value didn't appear to have an effect.

Demo

Here's a video demo of the this vulnerability being exploited before the patch. I don't consider it a proof of concept, as I demonstrate the exploitation with a benign redirection location.

In Conclusion

I raised this issue with medium severity, as opposed to the typical low severity, given the nature of Repl.it's REPL sharing feature and the ease of a user mistaking a malicious login link for shared REPL or other asset. The Repl.it team was very considerate in finding time to fix this vulnerability. They're a relatively small team with a lot of responsibilities, so their diligence was appreciated.

Timeline

Oct 24, 2019 - Initial email asking for preferred means of disclosure
Dec 31, 2019 - Response from Repl and disclosure of vulnerability details
Unknown - Full patch
Mar 03, 2020 - Discovery of patch and request to fully disclose findings
Mar 04, 2020 - Permission to fully disclose findings granted