Everything You Need To Know About Open-Redirects
Background, Detection, Exploitation, Impact
Open Redirect
An open redirect vulnerability occurs when an application allows a user to control a redirect or forward to another URL. If the app does not validate untrusted user input, an attacker could supply a URL that redirects an unsuspecting victim from a legitimate domain to an attacker's server.
Example:
change xyz.com -> attacker.com
The Need For Redirection?
Often websites need to redirect after a performed action
- login
- reset password
- and others
Server Side Redirection
Header-based being a location-header sent from the server. The benefit with this, for an attacker’s perspective, is that the redirect always works even if JavaScript is not interpreted. A server side function that gets a URL as input will follow the redirect and end up somewhere else.
But there is also Client Side Redirection using Javacript or HTML
When the redirect instead happens in Javascript it only works in scenarios where Javascript is actually executed. It might not work for server-side functions, but it will work in the victim’s web browser.
Javascript case would probably be found using the
window.location
While HTML will probably be those meta tags.
<meta>
The Threat
In this image we see the link pointing to google.com when in reality it will access attacker.com
Now many people will still notice that little trick... but what about this one
Imagine the following scenario.
Here an innocent link actually directs the user to a file that is downloaded from a malicious website. The file gets downloaded to the unsuspecting user and they think it came from google, after all they get redirected back to googles Thank You page.
Other Exploitation Methods
Leaking Tokens
Above we saw a snippet of PHP code which clearly didnt require any validation whatsoever on the input from redirect_to
Take this example from Flask:
In the following example the reset-password url contains both the token and redirect url
If the redirection gets pointed to an attacker controlled webserver, the referrer header will leak the token
SSRF
portswigger.net/web-security/ssrf/lab-ssrf-..
It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability.
In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.
For example, suppose the application contains an open redirection vulnerability in which the following URL:
/product/nextProduct?currentProductId=6&path=http://evil-user.net`
returns a redirection to:
http://evil-user.net
You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin`
This SSRF exploit works because the application first validates that the supplied stockAPI
URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.
Referrer Check Bypass
One way of protecting against CSRF is to check the referrer header to confirm that the request originated from the website itself.
However, with an open redirect it might be possible to trick this by running the CSRF-attack against the open redirect that in turn redirects to the correct page. It will look like the CSRF originated from the open redirect-page, which are hosted on the same domain and is allowed to do such requests.
How To Find Entry Points To Test
- Burp Proxy history & Burp Sitemap (look at URLs with parameters)
You can use the Site map filter to search for any redirects or forwards used by the Site map.
Click the "Filter" bar to bring up the filter options menu.
In this example we will "Filter by status code".
In this instance we are looking for the "3xx" class of status codes. These status codes indicate that further action has to be taken by the user agent to fulfil a request.
The "Site map" table should now only show HTTP requests of the "3xx" class.
You can now manually step through these requests to look for “interesting” URLs. These include any items in which the redirection target appears to be specified within a request parameter.
Google dorking. E.g:
inurl:redirectUrl=http site:target.com site: inurl:redir | inurl:url | inurl:redirect | inurl:return | inurl:src=http | inurl:r=http
Functionalities usually associated with redirects:
- Login, Logout, Register & Password reset pages
- Change site language
- Links in emails
- Read JavaScript code
- Bruteforcing
- Look for hidden redirect parameters, for e.g.:
/redirect?url={payload}
&next={payload}
&redirect={payload}
&redir={payload}
&rurl={payload}
&redirect_uri={payload}
Responses To Look For When Fuzzing
- HTTP redirect status codes
- Alert box popping up
DOM Based URL Redirection
Tools like Burpsuite can provide assistance in identifying combinations of JavaScript sinks and redirection functions, but these are very often false positives.
To understand DOM-based open redirects, we have to first understand JavaScript sinks. Remember that JavaScript can obtain data directly from the browser.
A URL in your web browser such as example.com/#dashboard, does not send #dashboard to the application. However, dashboard is accessible to JavaScript already loaded in your browser by window.location.hash.
We can confirm this with the browser console:
If the page uses JavaScript such as the following:
// use substr() to remove the '#'
window.location = window.location.hash.substr(1)
This would be open redirection.
An attacker could create a link example.com/#https://www.virtuesecurity.com and phish example users! By using DOM attributes, this vulnerability may even be missed by pentesters who are only looking at Burp traffic.
Tools For Testing
use paramspider than take results and feed it to openredirex
Note : The "FUZZ" is important and the url must be in double qoutes !
python3 openredirex.py -u "https://vulnerable.com/?url=FUZZ" -p payloads.txt --keyword FUZZ
or
python3 openredirex.py -l urls.txt -p payloads.txt --keyword FUZZ
OneLiners
OneLiner
1. waybackurls target.com | grep -a -i \=http | qsreplace 'http://evil.com' | while read host do;do curl -s -L $host -I|grep "evil.com" && echo -e "$host \033[0;31mVulnerable\n" ;done
2. subfinder -d http://acme.com -silent | waybackurls | gf redirect | qsreplace 'http://example.com' | httpx -fr -title -match-string "Example Domain'
Tips
- Try using the same parameter twice:
?next=whitelisted.com&next=google.com
- Try ?redirecturl=google.com@evilsite.com (Nahamsec)
- Try target.com/@attacker.com. In this case the interpretation will be like, the target.com is the username and attacker.com will be the domain. (s0cket7)
- Test for javascript Protocol javascript:confirm(1).
- Try target.com/?image_url=attacker.com/.jpg if there’s an image resource being loaded.
- You can also try target.com/?redirect_url=target.com.attacke.. to bypass weak regex implementations.
- If periods filtered, use an IPv4 address in decimal notation http://www.geektools.com/geektools-cgi/ipconv.cgi
- No slashes https:attacker.com.
- Back slashes http:/\/\attacker.com or https:/\attacker.com.
- Try a double-URL and triple-URL encoded version of payloads
- Try redirecting to an IP address (instead of a domain) using different notations: IPv6, IPv4 in decimal, hex or octal
- For XSS, try replacing alert(1) with prompt(1) & confirm(1)
- If extension checked, try
?image_url={payload}/.jpg
Try
target.com/?redirect_url=.uk` (or `[any_param]=.uk`).
If it redirects to target.com.uk, then it’s vulnerable! target.com.uk and target.com are different domains.
Payloads and Bypasses
\/yoururl.com
\/\/yoururl.com
\\yoururl.com
//yoururl.com
//theirsite@yoursite.com
/\/yoursite.com
https://yoursite.com%3F.theirsite.com/
https://yoursite.com%2523.theirsite.com/
https://yoursite?c=.theirsite.com/ (use # \ also)
//%2F/yoursite.com
////yoursite.com
https://theirsite.computer/
https://theirsite.com.mysite.com
/%0D/yoursite.com (Also try %09, %00, %0a, %07)
/%2F/yoururl.com
/%5Cyoururl.com
//google%E3%80%82com
java%0d%0ascript%0d%0a:alert(0)
j%0d%0aava%0d%0aas%0d%0acrip%0d%0at%0d%0a:confirm`0`
java%07script:prompt`0`
java%09scrip%07t:prompt`0`
Resources and Cheat Sheets
- github.com/swisskyrepo/PayloadsAllTheThings..
- pentester.land/cheatsheets/2018/11/02/open-..
- portswigger.net/support/using-burp-to-test-..
- youtube.com/watch?v=4Jk_I-cw4WE&list=PL..
- blog.detectify.com/2019/05/16/the-real-impa..
- EdOverflow Open Redirect CheatSheet
- cujanovic Open Redirect Payloads
- fuzzdb Redirect Url Templates
- virtuesecurity.com