Server Error in '/' Application.
The resource cannot be found.Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled
correctly.
Requested URL: /dummy.aspx
my app is asp.net 3.5 and I put the following under <system.web>
I can not get this to work either with the ResponseRewrite set on the web.config CustomErrors element.
I suspect the reason is that my instance is an MVC application, and I have an Error controller that servers the error page for everything...
Thus, ResponseRewrite, which I think uses Server.Transfer, would not work if I am pointing at an MVC location since it doesn't use the same pipeline processing that would normally be used... Essentially, saying "Server, return the result of this request",
the server tries, says "Error/Generic doesn't exist on the filesystem! I'll just give you a generic 404 because of that", and now you're back to serving generic 404s for missing files.
I see two mitigations for that issue:
1. You server a static HTML file or a really simple Error.aspx file (This will work for some reason...)
2. You implement your own solution in Application_Error in the Global.asax file...
On option 2, perhaps someone can answer this: Is it safe to use Response.Redirect here, or does this give something away? If it DOESN'T, then why not use "ResponseRedirect" instead of "ResponseRewrite" in the customErrors section in the first place and side
step this entire MVC issue?
Be sure to also set the custom 404 error page in IIS to point to the same error page (/Error.aspx in your case).
The behavior you're seeing is probably due to a difference in how IIS handles extensionless URLs. For example, when I applied the fix, the following worked: http://mysite.com/dummy.aspx but the following did not work http://mysite.com/dummy/
After I updated the custom 404 page in IIS, it all worked.
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
I'm not sure, but that seems logical. I'm not entirely sure that that would be a problem though, depending on your implementation...
The exploit has to engage ASP.NET in order to have it check the crypto string that you are passing it, so I think that you really only have to worry about the error pages that ASP.NET itself is serving back. Even in the case where you use WebResource.axd
to decrypt a string, looking for a non-existent file, ASP.NET would be serving the 404 back, not IIS.
I think that putting the IIS redirect in is only going to really help in terms of user experience, if they happen to put in a request that somehow ISN'T handled by ASP.NET (Which for the purposes of this exploit shouldn't be an issue). All of this is, of
course, unless I'm missing something glaringly obvious that I hope Haacked will point out.
Premy
Member
130 Points
122 Posts
Workaround not working
Sep 20, 2010 06:26 PM|LINK
Hi there,
I tried the workaround as explained on http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
but when testing I still get the normal:
Server Error in '/' Application.
The resource cannot be found.Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /dummy.aspx
my app is asp.net 3.5 and I put the following under <system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
Setting customErrors mode=”remoteOnly” didn't make a difference either (still get the same page)
Oh yes, I also created error.aspx and uploaded it to the server.
Hope someone can shed a light??
Thanks
Premy
Rovastar
Member
182 Points
59 Posts
Re: Patch not working
Sep 20, 2010 06:30 PM|LINK
Use IIS's Failed request tracing to trace through to see what is happening. I suspect a misconfiguration somewhere.
Premy
Member
130 Points
122 Posts
Re: Patch not working
Sep 20, 2010 07:47 PM|LINK
Thank u for your answer, but like I said my app is on a hosted provider's server so no IIS access for me.
christoc
Star
8562 Points
1566 Posts
Re: Patch not working
Sep 21, 2010 04:07 AM|LINK
Are you using .NET 3.5sp1 or straight up .NET 3.5?
DotNetNuke Upgrades and Consulting
Premy
Member
130 Points
122 Posts
Re: Patch not working
Sep 21, 2010 01:55 PM|LINK
Well, on my dev machine I see under Add/Remove that I've got 3.5 sp1
Now on the server (shared host) I'm not so sure. I was wondering if there's an easy way to check this out?
mbanavige
All-Star
134944 Points
15413 Posts
ASPInsiders
Moderator
MVP
Re: Patch not working
Sep 21, 2010 02:14 PM|LINK
make sure you are using a very basic error page.
For example, if you try to access Session in the error page, then the rewrite wont work and you get the standard 404 page.
i8beef
Member
69 Points
45 Posts
Re: Patch not working
Sep 21, 2010 04:00 PM|LINK
I can not get this to work either with the ResponseRewrite set on the web.config CustomErrors element.
I suspect the reason is that my instance is an MVC application, and I have an Error controller that servers the error page for everything...
Thus, ResponseRewrite, which I think uses Server.Transfer, would not work if I am pointing at an MVC location since it doesn't use the same pipeline processing that would normally be used... Essentially, saying "Server, return the result of this request", the server tries, says "Error/Generic doesn't exist on the filesystem! I'll just give you a generic 404 because of that", and now you're back to serving generic 404s for missing files.
I see two mitigations for that issue:
1. You server a static HTML file or a really simple Error.aspx file (This will work for some reason...)
2. You implement your own solution in Application_Error in the Global.asax file...
On option 2, perhaps someone can answer this: Is it safe to use Response.Redirect here, or does this give something away? If it DOESN'T, then why not use "ResponseRedirect" instead of "ResponseRewrite" in the customErrors section in the first place and side step this entire MVC issue?
/ Michael /
Haacked
Contributor
6901 Points
412 Posts
Re: Workaround not working
Sep 23, 2010 07:10 AM|LINK
Be sure to also set the custom 404 error page in IIS to point to the same error page (/Error.aspx in your case).
The behavior you're seeing is probably due to a difference in how IIS handles extensionless URLs. For example, when I applied the fix, the following worked: http://mysite.com/dummy.aspx but the following did not work http://mysite.com/dummy/
After I updated the custom 404 page in IIS, it all worked.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
mbanavige
All-Star
134944 Points
15413 Posts
ASPInsiders
Moderator
MVP
Re: Workaround not working
Sep 23, 2010 12:52 PM|LINK
Even if IIS used the custom error page for the 404, wouldnt the response code remain a 404 if IIS handled it?
i8beef
Member
69 Points
45 Posts
Re: Workaround not working
Sep 23, 2010 03:00 PM|LINK
I'm not sure, but that seems logical. I'm not entirely sure that that would be a problem though, depending on your implementation...
The exploit has to engage ASP.NET in order to have it check the crypto string that you are passing it, so I think that you really only have to worry about the error pages that ASP.NET itself is serving back. Even in the case where you use WebResource.axd to decrypt a string, looking for a non-existent file, ASP.NET would be serving the 404 back, not IIS.
I think that putting the IIS redirect in is only going to really help in terms of user experience, if they happen to put in a request that somehow ISN'T handled by ASP.NET (Which for the purposes of this exploit shouldn't be an issue). All of this is, of course, unless I'm missing something glaringly obvious that I hope Haacked will point out.
/ Michael /