Security Unvalidated Redirects Introduction

security-unvalidated-redirects-and-forwards

// Security - Unvalidated Redirects and Forwards:

Open Redirect (unvalidated redirect) automatically send a user to a different 
web page.  They are often used to guide navigation to a web site or to enable 
multiple domain names belonging to the same owner to refer to a single web site.  
Unfortunately for developers, attackers can exploit unvalidated redirects if 
they are not implemented properly.

Open redirect (also known as arbitrary redirect) is a common web application 
vulnerability where values that are controlled by the user determine where the 
app redirects.  Here is an example of a vulnerable application:

http://vulnerable-site.com/redirect?url=http://some-site.com

In this URL, the vulnerable-site.com application automatically redirect the user 
to whatever the user provided as the value for the URL parameter.  An attacker 
can change the URL to:

http://vulnerable-site.com/redirect?url=http://evil-attacker.com

and email this URL to potential victims who may recognize the first part of the 
URL and choose to trust it without looking at the rest of the URL, or may not 
known enough about online security, and click on the URL.  This may be 
dangerous if the evil-attacker.com URL is spelled similar to the vulnerable-site 
and is made to look just like the vulnerable-site, and therefore the user will 
likely provide sensitive information such as username and password.  The 
evil site can also pretend to deface the original site, or steal information.

Consider anyone who can trick your users into submitting a request to your 
website. Any website or other HTML feed that your users use could do this.  
Attacker links to unvalidated redirect and tricks victims into clicking it. 
Victims are more likely to click on it, since the link is to a valid site. 
Attacker targets unsafe forward to bypass security checks.

Applications frequently redirect users to other pages, or use internal forwards 
in a similar manner. Sometimes the target page is specified in an unvalidated 
parameter, allowing attackers to choose the destination page.

Detecting unchecked redirects is easy. Look for redirects where you can set the 
full URL. Unchecked forwards are harder, because they target internal pages.

Such redirects may attempt to install malware or trick victims into disclosing 
passwords or other sensitive information. Unsafe forwards may allow access 
control bypass.

Example attacks:

1. The application has a page called “redirect.jsp” which takes a single 
   parameter named “url”. The attacker crafts a malicious URL that redirects 
   users to a malicious site that performs phishing and installs malware. For 
   example: http://www.example.com/redirect.jsp?url=evil.com

2. The application uses forwards to route requests between different parts of 
   the site. To facilitate this, some pages use a parameter to indicate where 
   the user should be sent if a transaction is successful. In this case, the 
   attacker crafts a URL that will pass the application’s access control check 
   and then forwards the attacker to administrative functionality for which the 
   attacker isn’t authorized.  For example:
   http://www.example.com/boring.jsp?fwd=admin.jsp

The best way to find out if an application has any unvalidated redirects or 
forwards is to:

1. Review the code for all uses of redirect or forward (called a transfer in 
   .NET). For each use, identify if the target URL is included in any parameter 
   values. If so, if the target URL isn’t validated against a whitelist, you are 
   vulnerable.

2. Also, spider the site to see if it generates any redirects (HTTP response 
   codes 300-307, typically 302). Look at the parameters supplied prior to the 
   redirect to see if they appear to be a target URL or a piece of such a URL. 
   If so, change the URL target and observe whether the site redirects to the 
   new target.

3. If code is unavailable, check all parameters to see if they look like part of 
   a redirect or forward URL destination and test those that do.

// Open Redirects:

If I invite you into my house, but someone else trick you to enter their house
without showing their face (you think that you enter my house, but you actually 
enter the attacker's house instead).

Sometimes refered to as "arbritary redirects", open redirects occur when an 
application performs an automatic redirect to a URL contained within a URL 
parameter without any validation. This attack is commonly used in phishing 
attacks to get unsuspecting users to malicious websites. 

The attacker could post something like:

https://login.salesforce.com/?
  startURL=%68%74%74%70%73%3a%2f%2f%65%76%69%6c%2d%68%61%63%6b%65%72%2e%63%6f%6d

to a page, and because the start of the URL look familiar, you may incline to 
click on it.   URL encoded has been used to reduce suspicion by end users.  
Browsers will automatically perform URL decoding where user's eyes cannot.

Salesforce validate its redirection, and will display an error page.  If 
Salesforce does not validate the redirection, you may see a page (controlled 
by the attacker) that ask you to enter your username and password, and if you 
hit the login button, your username and password is logged to the attacker's 
server log.

The impact of open redirect is not as immediately apparent as other types of 
web vulnerabilities. Some will even argue that open redirect is not a 
vulnerability at all, but a feature that is working as designed. Imagine if 
you will, a scenario, where you are logged into Salesforce, and someone emails 
you a URL containing a redirect to an external website, that has been obscured 
like this:

https://na17.salesforce.com/apex/visualforcePage?
 cancelURl=%68%74%74%70%73%3a%2f%2f%65%76%69%6c%2d%68%61%63%6b%65%72%2e%63%6f%6d

If you had a valid reason to look at the Visualforce page, you might not 
question the appearance of the cancelURl parameter. Were you to hit cancel, you 
would be redirected to the attacker controlled evil-hacker.com domain. If the 
attackers were smart (and many of them are), they would style evil-hacker.com to 
look like login page presented by Salesforce when your session expires. If you 
didn't look at the URL bar, you might enter your credentials and allow your 
environment to be compromised by attackers. Even if you are to paranoid too be 
tricked into entering your password, they might trick one of your colleagues. 
Attackers only need a single person to be tricked by the open redirect to gain 
access to an environment. It is much, much easier to lock down all open 
redirects to prevent this kind of scenario.

If you are interested in learning more about the impact of this sort of attack, 
check out BeEF, the browser exploitation framework. This is a tool attackers 
can use when you visit their webpage that gives them many wicked tools for 
further intruding into your environment. It should sufficiently scare you into 
believing that open redirect is a real vulnerability: http://beefproject.com/
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License