C# - Unvalidated Redirects and Forward Access

Definition by OWASP:

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

·     The users are trick by the attackers making users to submitting request to attackers’ website unknowingly.
·        Attackers link the unvalidated redirect and trick user into clicking it.
·         Unsafe forward to bypass security checks by the attackers.
·         Target page is specified in an unvalidated parameter, allowing attacker to choose destination page.
·         Redirect will attempt to install malware and identify the sensitive information.
·         Unsafe forward may allow access control bypass.
·         Reputation of business can lost and business value of your users trust get affected 

How attackers achieve it

Unvalidated Redirects

Attackers find a page with a redirect on it:

http:/ / www.mytrustedsite.com/Redirect.aspx?Url=http://troyhunt.com

     

    Through phishing or some mechanism attackers get modify the above the URL link make the user to click the link              

 

http:/ / www.mytrustedsite.com/Redirect.aspx?Url=http://myuntrustedsite.com

Clicked on a URL which clearly had the host name of mytrustedsite.com, we’re now on myuntrustedsite.com. What’s more, there’s a logon form asking for credentials which you’d naturally expect would be handled properly under the circumstances.

The code behind the page simply takes the URL parameter from the query string, performs some arbitrary logging then performs a redirect which sends an HTTP 302 response to the browser:

var url = Request.QueryString["Url"];

 LogRedirect(url);

 Response.Redirect(url);

The above mytrustedsite.com is authorised domain so the user will click the URL this will lead to unvalidated redirects.

Redirect can be achieved by JavaScript:

• location
• location.href
• location.pathname
• location.search
• location.protocol
• location.hostname

• location.assign
• location.replace

/<![CDATA[ (function(g){   var a=location.href.split("#!")[1];   if(a){g.location=g.HBR=a;} })(window); //]]>

Unvalidated Forwards

               

                An application having login page and after successful login a protected page which is not accessible normally. Using Forward bypassing login page go directly access protected page

Avoid unvalidated redirects and forwards

·      To identify the vulnerability one should review the redirects and forwards of their site and verify the target URL in any redirection is an allowable destination.

 For eg:

Response.Redirect(“DestinationPage”);

Server.Transfer(“DestinationPage”);

·      Whitelist more important. All input must be validated against a whitelist of acceptable value ranges.

  var url = Request.QueryString["Url"];

 if (!Uri.IsWellFormedUriString(url, UriKind.Absolute))

{

              // Gracefully exit with a warning message

          }    

This validation will make the  untrusted data conforms to expected pattern of URL.

·         In the case of unvalidated redirects, we don’t need to have the URL in the query string, let’s try it like this:

http://mytrustedsite.com/Redirect.aspx?Id=AD420440-DB7E-4F16-8A61-72C9CEA5D58D

     

The entire code would then look something like this:

var id = Request.QueryString["Id"];

 Guid idGuid;

if (!Guid.TryParse(id, out idGuid))

{ // Gracefully exit with a warning message }

 var db = new MyTrustedSiteEntities();

var allowableUrl = db.AllowableUrls.SingleOrDefault(u => u.Id == idGuid);

if (allowableUrl == null)

{

// Gracefully exit with a warning message

 }

 LogRedirect(allowableUrl.Url);

 Response.Redirect(allowableUrl.Url);

We are still validate against the data type  and checking it against whitelist this code will provide extra protection and ensure against manipulation.

·      Create / use spider crawl your own website(Look at the Log statuses)

300 – Serious Statuses

302 – Old page moved from location

307 – Proper validation.

Prevent unvalidated redirects and forwards

               

·         Avoid using redirects and forwards.

·         If implemented, don’t use user parameter for identify the destination page. This can be usually done while developing.

·          If the destination parameter is unavoidable, ensure the parameter supplied is valid and verified by the user.

·          It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.

·         Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe.

Avoiding such flaws is extremely important as they are target of phishers trying to gain the user’s trust.

References:

http://scarybeastsecurity.blogspot.in/2010/06/open-redirectors-some-sanity.html

http://cwe.mitre.org/data/definitions/601.html

http://www.netcraft.com/security-testing/open-redirect-detection/

http://www.slideshare.net/RapPayne/a10-unvalidated-redirects-and-forwards

http://erlend.oftedal.no/blog/?blogid=136

Example Attack Scenarios

Scenario #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.

http://www.example.com/redirect.jsp?url=evil.com

Scenario #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.

http://www.example.com/boring.jsp?fwd=admin.jsp