+1  A: 

As long as you use one of the variants of Redirect that uses controller and action parameters or a route name, you should be alright, provided you have adequate security controls on your controller methods.

The concept being, whatever you use for your redirect must go through the routing engine and be validated by matching a route.

But I suspect that the real vulnerability is Cross-Site Scripting. Unless your malicious user can inject some Javascript into the page, they have no way of manipulating the return Url, or any of its parameters (since you otherwise control all of the server and browser code).

Robert Harvey
Please see my update - I chose to parse the returnUrl, ensuring that it isn't an absolute URL.
Brad B.
+1  A: 

You could always keep a record of the previous page with TempData when the user is not authenticated and use that to redirect to the previous page instead of a url parameter.

Mike Geise
I don't think this would work - TempData only persists through 1 redirect. In this instance, a person tries to hit a secured URL which causes their browser to redirect to the login. After typing in the username/password, they login and are redirected back to the originally requested page. This is two redirects, so TempData can't work. A better idea might be to attach the redirect URL to the Session?
Brad B.
+1  A: 

Yes this is a vulnerability. Before redirecting you need to inspect the returnUrl string parameter by passing it to a Uri object and make sure that the target domain is the same as the requesting domain. You should also take into account the case when returnUrl is a relative address like /admin. No problem in this case as the redirect will be to the same application.

Darin Dimitrov
Thanks for this suggestion - seems to be working fine so far! Please see my update to the original question for details on how I'm parsing the returnUrl.
Brad B.