In my asp.net MVC appplication i have below line of code in default.cs page which is present by default and every ASP.NET MVC application should have this line.
HttpContext.Current.RewritePath(Request.ApplicationPath, false);
Now the issue is Ounce is reporting that is security issue saying CrossSiteScripting.Reflected ..
Please advice
It isn't a security breach at all. All this code does is ensure that the current request is re-issued using MVC's request handler, instead of ASP.NET's. This code exists to handle cases where MVC fails to handle the request by default as a result of the server's configuration.
It sounds to me like Ounce is reporting a false positive.
Related
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 was wondering about the following:
i can define in IIS what to do with page not founds / 404, and also in my app i can put it in my CustomErrors section or just handle it in code.
Now as i assume IIS always gets the request first, when does it handle the 404 for itself, and when does it let it pass through to my app?
And a side-question: can IIS actually know if a request in asp.net MVC is a 404 because it might or it might not me mapped via any route?
IIS looks at the request extension. If there is a module registered to handle the type of request that came in, then it will forward the request to that module.
For example, if you request foo.jpg from your server, then IIS has a module built in to handle image/jpg content. If that module can't find the file then it returns a 404.
Same thing here. Whatever your MVC handlers don't look for (ie: images), then IIS will take care of in another manner.
can IIS actually know if a request in asp.net MVC is a 404 because it might
or it might not me mapped via any route?
I think it all depends on how your controller factory handles the unmapped request. The DefaultController factory seems to throw an HttpException with code 404 when it cannot find a route and let IIS handle the error display. You can play with this and see it in action by creating your own controller factory.
For example, add the following line to your Application_Start
ControllerBuilder.Current.SetControllerFactory(new TestControllerFactory());
and add this class to a brand new MVC project:
public class TestControllerFactory : DefaultControllerFactory
{
protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
{
if (controllerType == null)
{
//throw new Exception("Oops!"); // yellow screen of death
throw new System.Web.HttpException(404, "Oops not found!"); // bubbles up to IIS
}
return base.GetControllerInstance(requestContext, controllerType);
}
}
Navigate to your project to http://localhost/MvcApplication1/unmapped and see what happens when you throw an HttpException with code 404 versus when you throw a regular Exception (or even an HttpException with a code other than 404)
Make sure you are running your project under IIS (rather than the VS Dev Server) as the they handle these things different.
Now as i assume IIS always gets the request first, when does it handle the 404 for itself, and when does it let it pass through to my app?
Although the request is initially handled by ISS, it passed through to the MVC application. If a file is not found, an HttpException is thrown which bubbles back to IIS. If a file is found, it is served directly bypassing routing.
However, you can modify the behaviour by adjusting the the RouteExistingFiles property. If I'm not mistaken though you will need to create a route to handle all static content when the property is set to true (default is false). However, as a post here suggests, as per Steve Sanderson, that the routing system will first check if the file exists on disk. (See this related SO question which provides better clarification, especially the comments).
Try it yourself. Use the Application_Error() and Application_EndRequest() events in the Global.asax file and inspect the HttpContext.Current.Response object to to see what the final responses are when content is being served.
And a side-question: can IIS actually know if a request in asp.net MVC is a 404 because it might or it might not me mapped via any route?
This is where route configuration comes into play. Since MVC will check to see if the file exists first, if it does, it gets served directly and routing is bypassed. With regards to Controllers and actions, the same will apply. Eg. /SomeController/ActionThatDoesExist is first checked to verify if it is a physical file. Clearly this is not a file and a 404 exception will be returned from the application.
The third aspect I think that may be related to this question is how MVC and IIS work together. By this I am referring to Integrated Mode and Classic Mode. An awesome explanation can be found here.
IIS always handles the request and then forwards it to the MVC application. This is where it is basically decided how to handle it.
If their is already a physical file on the disk, then the whole Routing is bypassed and the file is served. If it can't find the file then it tries matching the Routing. If nothing works then the MVC application may handle the 404 otherwise it throws the HTTPException and IIS handles the 404.
I believe even in Webforms, the 404 scenario is pretty much the same internally. Only difference being the target is always a physical disk but the request still goes to ASP.NET Webforms, incase you want to handle the 404 yourself.
You will want to keep the execution within your MVC app and like others have said, usually IIS will pass the request into MVC first and only then if MVC passes a 404 exception up high enough will IIS get it back and apply it's decision making process.
The key is: handle 404's in MVC properly!
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");
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.