Open Redirect
In this chapter, we are going to learn about open redirect vulnerabilities.
Type of vulnerability: Client-Side / Server-Side
Chances to find: Common; Open redirect vulnerabilities are part of “Broken Access Control” ranked #1 in the “OWASP Top-10 Vulnerabilities“
TL;DR: Open redirect vulnerabilities enable an attacker force the web application to redirect to a URL of the attacker’s choice
What is an open redirect vulnerability?
Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. (src: OWASP)
Let’s have a look at an easy example. You go to a search engine for videos, searching for the term “Intigriti” and get a list presented of all Intigriti’s Hackademy videos. Once you click on one of them, you will get redirected to Youtube.
An example HTTP request could look like this:
GET /video?redirectURL=youtube.com%2Fwatch%3Fv%3D_PhqZ2mmzlY HTTP/1.1
Host: example.com
An attacker could now try to exchange the intended URL with a URL of his choice.
GET /video?redirectURL=attacker.com%2Fhacked HTTP/1.1
Host: example.com
If the application blindly follows the URL inserted by an attacker, then it is prone to unvalidated open redirects. However, that alone is not a vulnerability in itself. Open redirects are usually used in a vulnerability chain.
How do I chain and exploit an open redirect?
To answer that question, we first have to look at different redirect “variants”:
Javascript redirect (e.g.
window.location
)In a client-side redirect, an attacker could try to insert a Javascript payload, potentially leading to XSS (e.g.
javascript:alert(document.cookie)
)
Response header (
Location: <URL>
)oAuth: An attacker could try to manipulate the
redirect_uri
parameter to steal the oAuth access token obtained during login e.g. via Facebook as 3rd-party identity provider.SSRF: An attacker could try to bypass SSRF controls by relying on an open redirect to obtain access to internal domains.
There is one more argument that divides the security community if none of the vulnerability chains above work => Open redirects can always be used to conduct phishing scams. The team at Google came up with a pretty good statement, why they don’t see that as an issue:
"
Some members of the security community argue that [...] redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.
Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways. For this reason, we invest in technologies to detect and alert users about phishing and abuse instead.
" -
Google Bughunters
See here for some write-ups demonstrating impact:
How to prevent open redirect vulnerabilities?
Let’s have a look at various techniques to protect yourself against this vulnerability type:
Avoid using redirects
Validate the redirect URL by using a whitelist (specifying allowed URLs)
Do not rely on user input as the redirection target
Show a warning when a user is redirected to an (un)trusted domain (example: https://www.google.com/url?rct=j&url=https%3A%2F%2Fwww.intigriti.com%2F)
Additional resources:
Let’s have a look at a video example of a file upload vulnerability:
Also check out this wonderful visual overview by PwnFunction:
Following links are valuable to learn more about file upload vulnerabilities: