4

It appears that calling Url.IsLocalUrl(returnUrl) is producing different results given what seems to be the same value for returnUrl. How is this possible?

MVC app targeting framework 4.7.1. In trying to prevent open redirection attacks, I have the code below. Pretty simple and generic.

When I try to go to our landing page without being logged in and I'm redirected back to our login page, my URL is: https://ourdomain.com/I/Login?ReturnUrl=%2fI%2fHome. When I login, the URL I find myself at is: https://ourdomain.com/I/Home. Perfect. As expected. This works for 99.9+% of our users, else we'd be getting flooded with errors, and we're not.

However, we have at least one user that is getting an error here. Our error logs say: "An open redirection attack was detected. User was going to login and then be returned to: %2fI%2fHome."

My working returnUrl and the one in our error logs are the exact same, and it works 99.9+% of the time for the same value. I'm unable to reproduce the error myself. Why would this produce different results on rare occasions? Thanks in advance for any suggestions!

if (!string.IsNullOrWhiteSpace(returnUrl) && !Url.IsLocalUrl(returnUrl))
{
    throw new Exception($"An open redirection attack was detected.  User was going to login and then be returned to: {returnUrl}.");
}
Clayton
  • 41
  • 1
  • Can you paste the URL which works and URL which has errors in the question ? I believe this may have to do with encoding probably... – Manoj Choudhari Jan 22 '19 at 21:19
  • I'm sorry, Manoj, but I don't understand. I believe all of the information you requested is in my original post, so I'm not sure what else I can give you. And I don't see how it can be encoding, since, like I said, it works 99.9+% of the time with that value...except when it doesn't... – Clayton Jan 23 '19 at 10:46
  • 1
    what i was asking is the URL for which you are getting errors may have some characthers probably encoded using some encoding - somehow thats why IsLocalUrl check is failing. – Manoj Choudhari Jan 23 '19 at 10:48

1 Answers1

0

Here's the code involved in what is determined a local url, nothing to surprising.

https://github.com/aspnet/AspNetCore/blob/321327f84b2b22dcff2e9beb06a9a64236c5cced/src/Mvc/src/Microsoft.AspNetCore.Mvc.Core/Routing/UrlHelperBase.cs#L44

However there is an old stating non ASCII characters are not supported, I'm not sure if this is the case anymore as we're in a UTF8 world: https://stackoverflow.com/a/12643655/141022

I can't imagine ASP.net core doesn't support non-ASCI: https://stackoverflow.com/a/22357686/141022

I'd also suggest what Manoj is, thats is likely true that the url has a whitespace character or something else (there's lots of UTF-8 hidden chars) which isn't being logged in your logger perhaps.

Alex KeySmith
  • 16,657
  • 11
  • 74
  • 152
  • Hi Alex, and thanks for your thoughts on this! I'm going to need some time to dig into what you two are telling me and see if this helps me get to the bottom of this. Probably won't be today, but I'm definitely coming back to this soon. We think we've also been able to track down the user, so we reached out to them via email to see if they can provide us some additional information. We'd love to be able to reproduce this. Stay tuned, and thanks again! – Clayton Jan 23 '19 at 18:41
  • As an FYI, the customer hasn't responded to our email asking for more information, and we're still unable to reproduce the problem on our own. I'm not sure where we go next. The problem doesn't appear to be prevalent, which is good. We may have to wait until we can get more information on what "people" are doing to make this happen, whenever that may be. Thanks for your insights, though, Alex and Manoj. We'll definitely keep this in mind if/when this happens again. – Clayton Jan 31 '19 at 12:17
  • Thanks for the update, if you haven't done already it might be worthwhile trying to reproduce on the exact browser they are using detected from their user agent. The user agent will likely be misleading as it'll report every browser under the sun, but a tool like https://userstack.com/ (haven't used it myself) will help identify the real user agent or through Google Analytics. – Alex KeySmith Jan 31 '19 at 13:56
  • I've seen some very strange behaviour over the years from browsers! One of the most interesting is on IE7 in an intranet environment (triggered when on an non FQDN) the JavaScript engine behaves entirely differently. – Alex KeySmith Jan 31 '19 at 13:58