A10 Unvalidated Redirects and Forwards

Problem and Protection

Phishers Pwn eBay

o  If you got an email that said "80% off anything on eBay", would you be interested?

o  What if the click here link was this? •  http://Couponpalooza.com

o  Would you feel better if the link was this? •  http://cgi4.ebay.com/ws/eBayISAPI.dll?

MfcISAPICommand=RedirectToDomain&DomainUrl=http://www.Couponpalooza.com

o  World's biggest spammers were doing exactly this five years ago until eBay plugged the hole.

o  Many other sites have the same vulnerability.

Unvalidated Redirects and Forwards

o  But when combined with other threats, it is harmful.

o  When an attacker uses our website to redirect the victim to a malicious site.

o  Not a big deal in and of itself.

How attackers do it

Unvalidated Redirects o  He finds our page with a redirect on it: http://www.tic.com/validpage.aspx?name=Ralph& dest=tic.com/page2.jsp

o  Through phishing or something else, he gets the user to click on his link:

http://www.tic.com/validpage.aspx?name=Ralph& dest=www.evilSite.com/stealItAll.jsp

o  Because the domain is valid, the users are more likely to click on the link.

How attackers do it

Unvalidated Forwards o  Say a site has a login page and behind that

is Protected.jsp which isn't accessible normally. But the site also has a TrySomething.jsp page which says:

if (someCondition) response.sendRedirect(Protected.jsp);

else response.sendRedirect(DoSomethingElse.jsp);

o  Attackers can go directly to TrySomething.jsp and get access to Protected.jsp, bypassing the login page.

How we protect ourselves

o  Avoid redirects and forwards o  Don't take user input as a redirection target. o  Use white-lists o  Use mapping to translate the user-supplied

target

Avoid redirects and forwards

o  Review your code for: Response.Redirect(otherPage) Server.Transfer(otherPage)

•  Can you rewrite them? o  Create/use a spider to crawl your own site

•  Look at the logs for redirects •  300-series statuses

― 302 = old-school page moved ― 307 = proper redirection.

Don't take user input

o  After finding all redirects, look at the pages that generated them •  These will be in the spider's log

o  Try to change the URL by hand o  Try to brute-force change it via an HTTP re-

writer o  If either works, you have a vulnerability o  Solutions:

•  Modify the page to hard-code the destination •  If that isn't possible, only allow the user to choose

from a list

Use whitelists to limit where the user can go

o  Filter the allowed input so the user can't put in anything he wants.

o  Terrible: <input type="text" id="destURL" />

o  Better: <select id="destURL"> <option value="tic.com/AboutUs">About</option> <option value="tic.com/catalog">View our catalog</option> <option value="dwb.com/PartnerProgram">Partnership</option> <option value="failblog.com">Today's fail</option> </select>

o  Note that this option is still tamperable, so whitelist server-side as well.

Whitelists are better than blacklists

o  Two ways to filter: 1.  Blacklists

― "Any pattern is fine except these ..."

2.  Whitelists ― "Only these patterns are allowed..."

o  Whitelists apply in many security areas •  XSS •  Injection attacks •  More

Use mapping to limit where the user can forward

o  Client-side: <select id="destURL"> <option value="1">About</option>

<option value="2">View our catalog</option>

<option value="3">Partnership</option> <option value="4">Today's fail</option>

</select>

Use mapping to limit where the user can forward

o  Server-side: switch (ddlDestURL.SelectedValue)

{

case 1: Response.Redirect("tic.com/About");

case 2:

Response.Redirect("dwb.com/PartnerProgram");

...

case else: throw new Exception("Invalid value");

}

More concise mapping

o  Store the values and URLs in a database table called ValidURLs.

o  Create list: var validUrls =

dc.ValidURLs.ToDictionary(

v => v.ID, v => v.Description);

o  Pull user's choice from list: string url =

validUrls[ddlDest.SelectedValue];

Response.Redirect(url);

Summary

o  Unvalidated redirects and forwards leave a hole that attackers can use to send our users to malicious sites.

o  To protect them, we should: o  Eliminate all redirects and forwards. o  Failing that, at least provide a whitelist of

acceptable values. o  Map the values that the user sends us to

accepted URLs so the values can't be spoofed on the client side.

Oh, and one more thing ...

o  URL shortening services are being used as attacks: •  bit.ly •  goo.gl •  su.pr •  is.gd

o  Hint: Put "+" at the end of the bit.ly, su.pr and goog.gl to check its destination.

o  is.gd takes a "-"

Further study

o  eBay Redirect Becomes Phishing Tool •  http://bit.ly/EBayRedirectFlaw

o  WebScarab has a spider tool: o  http://bit.ly/WebScarab

o  Overview of AppSec/OWASP top 10: o  http://scr.bi/AppSecTop10

o  Google blog article on open redirects: •  http://bit.ly/OpenRedirects