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.
Related
I had an old asp.net website (aspx) and have redesigned it with asp.net MVC using SSL. Anyway, after I promoted the new site I saw a ton of errors which were being generated by bots looking for old pages; the errors were looking something like this: The controller for path '/blablabla/moreBlalbalba/page.aspx' was not found or does not implement IController. So, I updated my error handling to return a 301 response and redirect to the home page and added a sitemap. The google 404 console errors went away for around a month, but now have a ton of 404 errors and they are all pointing to the old site structure. As a side note, the new MVC/SSL site has no 404 errors in the webmaster console, all the errors are on the non SSL site. So, what is the best way to update the bots for the new site structure.
Thanks!
I would suggest you to redirect all traffic from HTTP to HTTPS, using this example. This may solve your problem already.
And secondly create a sitemap for Google to check the relevant pages of the website, example here
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?
i'm trying to goto the following url :-
http://user1:pass1#localhost:1234/api/users?format=xml
nothing to complex. Notice how i've got the username/password in the url? this, i believe, is for basic authentication.
When I do that, the Request Headers are MISSING the 'Authorize' header. Er... that's not right :(
I have anonymous authentication only setup on the site. I don't want to have anon off and basic turned on .. because not all of the site requires basic.. only a few action methods.
So .. why is this not working? Is this something to do with the fact my code is not sending a 401 challenge or some crap?
For What It's Worth, my site is ASP.NET MVC1 running on IIS7 (and the same thing happens when i run it on cassini).
Update:
If this is an illegal way of calling a resource using basic auth (ala security flaw) .. then is this possible to do, for an ASP.NET MVC website .. per action method (and not the entire site, per say)?
If you want to use basic authentication, the first request to the resource needs to return a HTTP 401 error code, and set a WWW-Authenticate header. This will instruct the browser to actually send those credentials.
You mentioned you're using ASP.NET MVC. You might be able to do this via the web.config, but I'm not sure on the exact mechanics.
My company makes a product called the Neokernel Web Server (http://www.neokernel.com), it is an ASP.NET web server with support for basic authentication among other features.
You specify protected resources in an apache-style config file so you could put your "protected" actions in a folder requiring authentication and put everything else in the root / unprotected. Look at the "http.authentication" file installed in the Neokernel root directory for an example, or at the authentication samples in the demos.zip file.
ASP.NET MVC 2 app
I have two actions on my controller (Toons):
[GET] List
[POST] Add
App is running on IIS7 integration mode, so /Toons/List works fine. But when I do POST (that redirects to /Toons/List internally) it redirects (with 302 Object Moved) back to /Toons/Add.
The problem goes away if I use .aspx hack (that works in IIS6/IIS7 classic mode).
But without .aspx - GET work fine, but POST redirects me onto itself but with GET.
What am I missing?
I'm hosting with webhost4life.com and they did change IIS7 to integrated mode already.
EDIT: The code works as expected using UltiDev Cassini server.
EDIT: It turned out to be trailing-slash-in-URL issue. Somehow IIS7 doesn't route request properly if there is no slash at the end.
EDET: Explanation of the behavior
What happens is when I request (POST) /Toons/List (without trailing slash), IIS doesn't find the handler (I do not have knowledge to understand how exactly IIS does URL-to-handler mapping) and redirects the request (using 302 code) to /Toons/List/ (notice trailing slash).
A browser, according to the HTTP specification, must redirect the request using same method (POST in this case), but instead it handles 302 as if it is 303 and issues GET request for the new URL.
This is incorrect, but known behavior of most browsers.
The solution is either to use .aspx-hack to make it unambiguous for IIS how to map requests to ASP.NET handler, or configure IIS to handle everything in the virtual directory using ASP.NET handler.
Q: what is a better way to handle this?
You have control over your code.
change all pages that make a post without the trailing slash to post to the correct page.
if its 3rd party clients, than return an exception, that they should fix the bug.
this is expected behaviour, and its not your job to recover everything that can happen.
but you should give good hints (e.g. exception message, instead of a weird error or redirect.)
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'?