Browsers tormented by open roll vulnerability

If you got to this blog post after taking a longer look at the Rick Rolled tweet we shipped for April Fools’ Day… nice work! If you didn’t, check out the link we tweeted out to get in on the joke.

“Never click unexpected links!” Ever hear someone yell this? Virtually every person in tech has a healthy suspicion of random links; it is for a good reason. Every now and then there are huge leaks from industry leaders as a result of a targeted campaign. One of the most reliable ways to “phish” someone, or exfiltrate their credentials, is to abuse an open redirect vulnerability in a safe-looking website and redirect the victims to a malicious one. While we only mentioned credentials theft, it is also worth noting that open redirect vulnerabilities can actually open the door to more sophisticated vulnerabilities.

What are open redirects and how do they work?

The basic form of an open redirect vulnerability is simple. An attacker crafts a URL to a known site, i.e. www.snyk.io, but then adds a parameter, query string, or a path component that when sent to the server will make the server redirect the request (and the client) to an allegedly-intended URL or endpoint. As this is the base part for any HTTP request, the vulnerability introduces itself if the server doesn’t verify the to-be-redirected-to URL, and just blindly redirects the request. Given such a scenario, an attacker can simply select which URL they’d like to redirect victims to and send the malicious link to a victim. Such an attack will take form in a URL such as [www.snyk.io?nextUR](http://www.snyk.io?nextURL=)L=//malicious.com. Assuming we build and style malicious.com to look exactly like www.snyk.io — an unsuspecting victim will have a very hard time differentiating between the two sites and will likely get exploited by the attacker.

Although it may seem like the impact of an open redirect is not a technically severe issue, the implication it has on eroding the trust of dedicated users is significant. At the end of the day, the victims are customers of a product, and if a product loses its clients’ trust, eventually it’ll fall out of favor (as customers will leave and no new customers will join). So, while technically the vulnerability isn’t severe, product-wise and integrity-wise it is severe and may impact the whole product.

To add more coffee to our “this is fine” mug, one may chain an open redirect vulnerability to other web-related vulnerabilities, such as XSS, resulting in far greater impact and potentially a critical threat. Twitter, as an example, received a report of an open redirect resulting in XSS back in March 2018. If you’ll take a look into the report, the researcher found that when invoking the open redirect vulnerability, they’ve got access to perform an XSS, which, when combined with the open redirect resulted in a full compromise of the victim’s domain-related data (such as cookies, local storage, etc). Twitter rewarded the researcher with $1,120 for this finding.

Similarly, server-side request forgery (SSRF) is a vulnerability that can easily compromise a server. Since open redirects vulnerabilities can help an adversary bypass filtering mechanisms, chaining these two together go together like a beer at a ball game — it is a perfect match! If any requests made by a server utilize user input, this is a juicy target for an attacker. Once the adversary understands how the specific endpoint is handling user input, all it takes is some creativity and trial and error until a viable path to SSRF is identified. When the adversary finds an open redirect, they will plug away at the URL parameter in question, trying to access critical internal endpoints, services, or even reach out to external malicious assets!

Keep open redirects out of your applications

Some of you are probably ready to go hunting for those open redirects right now! To resolve these issues consider the following. Validate all user input, especially if user-controlled data will be reflected in the URL. Enable strong authentication measures on services that do not have it enabled by default. Utilize an allowlist to restrict the potential destinations for a referral. You can read more about remediating these issues on this OWASP Cheat Sheet.

In conclusion, we’d urge you to not overlook open redirect vulnerabilities due to their less technical appearance. Their impact on clients, and the residual damage this may produce, can be severe. Leaving open redirect vulnerabilities unresolved is like leaving doors and windows open while hoping someone will not enter your home uninvited, it just doesn’t make sense!