I am debugging some code and there is this check (in an ASP.NET MVC controller)
if (Url.IsLocalUrl(returnUrl))
So I check the documentation and it says
Returns a value that indicates whether the URL is local.
But what does that mean, 'the URL is local'?
If I hit a webserver, when does the webserver say 'the URL is local' ?
In the ASP.NET MVC blog Preventing Open Redirection Attacks (C#) you can find an explanation of why you should use it, but, as is tradition with MVC's documentation, it's not explained how it works.
You can read that from the source presented there though: it checks whether an URL starts with / or ~/, meaning: whether it is a relative URL which thereby points to the same domain.
Related
I have two different MVC applications. They are both using cookieless session states and both use this line to determine the application's root:
var root = '#Url.Content("~/")';
For some reason one application recognizes the cookieless parameter and provides a proper root url containing the cookie parameter (Something like: /(S(03lyoc2mzcq5cyqqqzgritk2))/). The other application just has the root url as /.
I have found a work around for the application that only provides /:
var root = '#Url.Action("Index", "Home")';
The application that properly provides the cookieless parameter combines both webforms and MVC. Any ideas on where my inconsistency might be?
After some research and testing it was the version of MVC that made the difference. It appears that in MVC 4, the cookie parameter will be included, however, in MVC 5 the cookie is no longer added to the url.
If someone has a more detailed answer as to why this feature was removed I'd be happy to accept it as the answer. I have a feeling it's because Microsoft isn't wanting to support cookieless anymore, but I have no proof to support that. This may be a clue...
https://stackoverflow.com/a/21652454/386856
Why do I continuously receive "The provided value for the input parameter 'redirect_uri' is not valid."?
My site is hosted in Azure. I'm trying to Login via the Microsoft sign-in button. I haven't really made many changes from the default ASP.Net MVC out-of-the-box template. All I've really changed was to uncomment the app.UseMicrosoftAccountAuthentication line and add the clientId and clientSecret.
Do I have the Redirect URL set up incorrectly?
Site: http://mysite.azurewebsites.net
Redirect URL: http://mysite.azurewebsites.net/
I read somewhere that you need to specify a Redirect URL in the form of http://www.mysite.azurewebsites.net. Can anyone confirm or deny that? I do not need the www in my current set up.
The error I consistently receive is:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The provided value for the input parameter 'redirect_uri' is not valid. The expected value is 'https://login.live.com/oauth20_desktop.srf' or a URL which matches the redirect URI registered for this client application.&state=SomeLongPossiblyEncryptedString
This message is displayed on the page returned after an attempt to login:
Microsoft Account
We're unable to complete your request
Microsoft account is experiencing technical problems. Please try again later.
3/26/2014 Update: No luck so far, here's some screen shots of my settings in case it helps.
Basic Information
API Settings
Is this a problem on Microsoft's side or am I doing something wrong?
From the default MVC what works for me (just tested about 5 minutes ago) for the redirect URL is
http://testcrap.azurewebsites.net/signin-microsoft
All the documentation I've found says to use
http://testcrap.azurewebsites.net/login/microsoftaccount
But that doesn't work for me...
signin-microsoft does
OR if that doesn't work then use something like firebug to see what the request to the oauth provider looks like and then whatever the redirecturi is inside of that request is what you need to use..
For web application you need to set the redirect url in the Live Connect Developer Center.
In API Settings->Redirect URLs you must set:
http://www.yourdomain.com/signin-microsoft
Hope it's helpful :)
You need to provide the redirect url in the Live Connect Developer Center. I've attached a screenshot. This is part of the application validation to prevent malicious applications.
It seems Microsoft change the url again. This what works for me
.auth/login/microsoftaccount/callback
My redirect url is
https://yyyyyyyy.azurewebsites.net/.auth/login/microsoftaccount/callback
To get this url, use Fiddler or any http debug tool and look for request to login.live.com. The redirect_url is in the query string.
https://login.live.com/oauth20_authorize.srf?client_id=00000000551716B9&redirect_uri=https%3A%2F%2Fyyyyyyyyyy.azurewebsites.net%2F.auth%2Flogin%2Fmicrosoftaccount%2Fcallback&response_type=code&scope=wl.basic+wl.offline_access+wl.signin+wl.birthday+wl.calendars+wl.calendars_update+wl.contacts_birthday+wl.contacts_create+wl.contacts_calendars+wl.contacts_photos+wl.contacts_skydrive+wl.emails+wl.events_create&state=nonce%3Dfe7e6b678b8844f48f079cceadf1f426_20151206145117%26redir%3D%2F
Since I need 3 more reputation points to write a comment to your post I have to ask it here. Sorry about that.
Are you getting this error while trying it out on the real domain or while testing it from your localhost?
If the second is the case you need to setup a DNS entry for a dummy hostname in your local host file that points to 127.0.0.1 and use that dummy name when registering with live. Furthermore it needs IIS, not IIS Express.
Not sure if it is a clean way nor if it is complete, but it is the furthest I got when trying out the new ASP.NET Identitiy Provider. Sadly there is only a example in the official documentation which shows how to use it with google...
I, too, would appreciate a clean answer to this.
Redirect URIs are "SSL sensitive" and you probably always want the SSL version.
I have a question about the returnUrl querystring parameter that is appended by ASP.Net when attempted to hit a page that requires authentication. In looking at Microsoft NerdDinner Sample's LogOn action (along with every other 'sample authentication code' I see on the 'net), it just has the ReturnUrl parameter declared in the action's signature and uses it directly in a Redirect() call. However, back in the WebForms days and using Membership Controls, we use to use the FormsAuthentication.GetReturnUrl() call. Besides returning the 'default url' if no url was specified in the querystring, it also does a few security checks (Cross App Redirect and 'IsDangerousUrl()'). Are those no longer a concern or are all the sample 'log on' actions I'm seeing all over the 'net just ignoring those issues?
I'm not sure about the samples that you've looked at, but it's entirely possibly to use Forms Authentication as is in MVC and benefit from the checks performed in The FormsAuthenticationModule processing (or using the FormsAuthentication class directly).
IIRC, the default MVC application in Visual Studio includes an adapter around forms authentication (AuthenticationService) which can be easily adapted to use the ReturnUrl querystring.
I imagine the samples in question have simply overlooked XSR attacks.
ASP.NET MVC web app that exposes "friendly" URLs:
http://somesite.com/friendlyurl
...which are rewritten (not redirected) to ASP.NET MVC-style URLs under the hood:
http://somesite.com/Controller/Action
The user never actually sees any ASP.NET MVC style URLS. If he requests one, we hard 404 it. ASP.NET MVC is (in this app) an implementation detail, not a fundamental interface.
My question: how do you examine an arbitrary incoming URL and determine whether or not that URL matches a defined ASP.NET MVC path?
For extra credit: how do you do it from inside an ASP.NET-style IHttpModule, where you're getting invoked upstream from the ASP.NET MVC runtime?
Thanks!
why do you have the "hard" urls in the first place then? just change your routing, it seems kind of odd to rewrite something you have complete control over.
If you can't, you probably want something along these lines
Response.StatusCode = (int)HttpStatusCode.NotFound;
return View("NotFound");
So far, my https deployments have commonly involved a naive lockdown of the entire site with https and provide an http-to-https redirect on the web server.
I now plan to have a single ASP.NET MVC site (on the cloud) that will contain both http and https pages. So, the site will have 2 conceptual (not physical) zones providing for both secure and non-secure requests.
Configuration-wise, I have set up input ports for both 80 and 443 and the site accepts both requests.
Is there any way I can flip protocol to https for any call that goes to an action that belongs in the secure zone? For instance, the kind of things that action filters can do.
Thanks much.
edit: Please note that the whole idea of this is to avoid using absolute urls on the form action attribute because of portability issues and because the user will not see the https:// assurance visual cues on the browser.
P
You might want to take a look at the MVC futures assembly from Microsoft available for download here.
This has a FilterAttribute, RequireSslFilterAttribute that allows you to easily tag Action methods in your controller that require SSL - e.g.
[RequireSsl(Redirect=true)]
public ActionResult LogOn()
{
return View();
}
The optional redirect parameter will cause the request to be redirected to the same URL but via https instead of http if required.
WARNING: As Daniel points out though, by the time you hit this Action it may already be too late if data was posted to a non secure version of the page - it is already potentially compromised, so you still need to exercise care when using this and make sure all sensitive data is sent via https. (I just noticed your comment to Daniel, you obviously understand this, I'll leave the warning here for anyone else who stumbles upon this though!)
EDIT: As Luke points out, in MVC2 this attribute is now part of the core framework and is renamed to [RequireHttps]
Is there any way I can flip protocol to https for any call that goes to an action that belongs in the secure zone?
The short answer is no, once the request has come via http, it has already been potentially compromised. You can require that certain calls come via the HTTPS (not sure how to do that as I have not done ASP.Net for awhile) and send an error if they do not. The key is to decide when you want the application to make the jump, ie during login and choose the HTTPS as the action for those forms. Is that what you meant by 'action filters'?