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?
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
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.
I have forms authentication on my MVC site and the default route is set to send users to /home/index. Home/index is excluded from the login requirement, via a Web.config location section. if I type in http://Example/home/index, I go to the home page as expected, but if I just do http://Example, I get redirected to the logon page.
If I turn off authentication and do http://Example, the default route works fine, and I'm sent to the home page.
Why is authentication not respecting the default route? Thanks!
You shouldn't be using the <location> element in web.config to handle authorization in an ASP.NET MVC application as it might clash with your routes. This is used in standard WebForms applications but it is considered bad practice in MVC.
The recommended way to handle this is to decorate your controllers/actions with the [AuthorizeAttribute]. So get rid of all location elements in web.config and decorate.
For me, the problem was the MachineKey. It's required to decrypt/encrypt the cookie if you are doing that (for example: a web farm). Because the app couldn't decrypt the cookie, even though it was getting passed back and forth, the app acted like the cookie wasn't even there. Adding this setting to web.config fixed it for me:
<machineKey compatibilityMode="Framework20SP2" validationKey="some_hard_coded_long_key" decryptionKey="another_hard_coded_long_key" validation="SHA1" />
See this article for more on the machinekey.
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.