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
Related
My Asp.net core web app can generate a confirmation link successfully using
string confirmationLink = Url.Action("SetPassword","Account",
new
{
userid = userMaster.Id,
token = confirmationToken
},
protocol: HttpContext.Request.Scheme);
This roots the route using the root of the current controller's page.
Now I have moved out the logic to a web api and I would like to use the root of the calling page in the Url.Action statement in the webapi.
I want to achieve following points.
a) get the root of the current page and
b) having passed that root to the webApi how do I seed Url with it so that it is available to Url.Action?
Workaround: I am generating the confirmation link as a simple string.
string confirmationLink = ${this.config.p_ConfirmationURLRoot}/{this.config.p_ConfirmatonURLController}/{this.config.p_ConfirmationURLAction}?userId={ userMaster.Id}&token={ confirmationToken}";
This does not resolve the questions posed above, but if like me your end goal is a working link that may be used else where, this approach will satisfy that requirement.
It sounds like you're trying to work with request-routing for a front-end application using the routing of a separate API. This isn't a use-case for the ASP.NET routing systems; they are only interested in routes within the application domain. The front-end application has its routes and the API has its routes: both are completely separate concerns.
This is a good model, one you want to work with rather than against. The front-end application should be free to change its URLs without requiring changes in other applications.
By all means, have a separate API to perform logic like user-creation and validation of security tokens, but these are not concerns which should be intermingled with front-end routing.
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.
Is ASP.NET MVC 2 vulnerable to the oracle padding attack? If so, what workaround should be implemented? The instructions on Scott Gu's blog appear to only be for Webforms.
I tried this:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="/Home/ErrorPage" />
however, http://www.example.com/PageThatDoesNotExist still returns a standard 404 error page.
EDIT: I see that Scott Gu posted in the comments under his blog post that MVC is vulnerable, but it's still not clear to me exactly how to implement the workaround.
Yes - linkage to the comment by Scott Guthrie.
Saturday, September 18, 2010 9:00 PM by ScottGu
#Vijay,
Will the ASP.NET MVC too get affected?
Yes - all versions of ASP.NET are affected, including ASP.NET MVC.
Thanks,
Scott
I see that you've seen the comment, but if you run the vbs script on your server, it should tell you if it's still a problem.
Edit: Also, Scott has discussed FAQs in a new post here.
Under your default route you could/should add this for starters
routes.MapRoute("Catch All", "{*path}", new { controller = "Home", action = "ErrorPage" });
Edit 2
the problem lies in the part redirectMode="ResponseRewrite" without this, it works.
using the route though will fix 1 part of the problem, where the path cant be found (404)
the next part, like existing paths with bad ID's or other data, could be fixed with
<customErrors mode="On" defaultRedirect="/Home/ErrorPage" />
what exactly does redirectMode="ResponseRewrite" do?
Edit: what it does.
redirectMode
ResponseRedirect: Specifies that the
URL to direct the browser to must be
different from the original Web
request URL.
ResponseRewrite:
Specifies that the URL to direct the
browser to must be the original Web
request URL.
It only matters for .NET 3.5 SP1 and .NET 4.0.
Edit 101:
For redirectMode="ResponseRewrite" the ASP.NET calls Server.Execute(...) internally, which does not work with MVC routes, so for MVC this only works with a static HTML file.
<customErrors mode="On" defaultRedirect="~/Views/Shared/error.htm" redirectMode="ResponseRewrite" />
works.
This question is included in Scott Gu's Frequently Asked Questions about the ASP.NET Security Vulnerability:
Does this affect both ASP.NET Web Forms and ASP.NET MVC?
Yes – the publicly disclosed exploit can be used against all types of ASP.NET Applications (including both Web Forms and MVC).
I posted my full take on this (after extra research) on my blog.
Update note: moved the link to a post specific to asp.net MVC
I strongly believe the issue with the 404s is related to WebResources and ScriptResources (which can disable for asp.net MVC btw), as those probably give 404s when the corresponding resource isn't found (which would be the normal response to an valid padding that gives an invalid resource path/name).
Other error codes & messages could be an issue for other asp.net features, but ending with a 404 only because you hit an url non related to any special handler shouldn't be causing the issue.
Also note what I mentioned in this answer:
How serious is this new ASP.NET security vulnerability and how can I workaround it?
if the app is asp.net MVC we don't really need webresources.axd and/or scriptresources.axd, so those can be turned off. We also don't use viewstate.
asp.net membership provider 'caches' roles in cookies, turn that off.
The auth cookie is signed, and from the info in the paper they shouldn't be able to generate a signed cookie if they don't get to the actual keys (as they did in the video before forging the auth cookie).
As Aristos mentioned, for the session id in the cookie, that's random for the user session, so it'd have to be sniffed from an user with the target security level and cracked while that session is active. Even then if you are relying in authentication to assign/authorize the user operations, then the impact would be minimal / it'd depend a lot in what Session is used for in that app.
A patch for this bug has been released on Windows Update.
http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx
Do you have a route/controller action setup to return an error page for the /Home/ErrorPage route?
Using ASP.Net MVC v2.0, I am starting to research the use of the Html.AntiForgeryToken() method when submitting forms that process data. I can see it sets a hidden value in the form HTML and it sets the same value in a session cookie.
The question is will different web servers in a load balanced configuration create the same token in the HTML forms? It seems if they don't then the cookie and hidden form value wouldn't match and we would have a problem. Before I get into actually testing this in a LB configuration, wanted to check if anyone already has experience with this?
Thanks, Paul
If all machines across the farm share the same <machineKey>, everything will work. There are lots of resources on how to set this. There's also a tutorial on MSDN.
Note that the name <machineKey> is a bit misleading, since this is actually set per-application in ~/Web.config. So set the <machineKey> explicitly in your app's Web.config, then deploy across your farm.
This one is causing me a few nightmares as I'm on the live box trying to work out what is going wrong!
If someone accesses our ASP.Net MVC website with the full URL http://www..net all is OK. If they go to: http://.net then our custom error page is shown. This used to work OK before we moved the site to MVC.
We do have an Application_OnError event in the Global.asax but I know that is not being hit in this situation, as I log to the event log and that is not happening.
If I switch custom errors off in the web.config, the site behaves correctly!
We're using the MVC Beta at the moment. Edit: We're running on IIS6 and using the MVC routing for friendly URLs.
This is impossible to test locally which is fustrating as it only happens on live without the www. I wonder if it is something to do with routing......
Thanks!
The problem is too vague at this stage for me to be able to give you a good answer but I would look firstly at your URL rewriting - what version of IIS are you using? If IIS5 or 6, are you using Isapi Rewrite? This could be interfering with your response.
As for why the error goes away when you turn customErrors off, well, I have no idea sorry.
On a side-note, if you're concerned with Google ranking, you may want to use a rewriting tool (like Isapi Rewrite and I think built-in to IIS7) to send an automatic redirect (HTTP 301 response) that will send users from the non-www version to the www version. Google sees both of these as individual sites with duplicate content and this will dilute your Page-Rank. This will also avoid the problem you're experimenting altogether as users will only ever see the www version.
Also, I'm not sure if Application_Error is really the best way to deal with errors in ASP.Net MVC. Do some research into the HandleError Action Filter as this to see if this might provide you with a better approach to error handling. Check out Scott Gu's post on this for more info.
I hope this helps.
Cheers,
Zac
i was having the same problem in my MVC .net site but it worked out for me when i enter both domain.com and www.domain.com in the host header in IIS.