locked
Workaround not working RRS feed

  • Question

  • User-962338856 posted

     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

     

     

     

     

    Monday, September 20, 2010 2:26 PM

Answers

  • User-158764254 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 10:14 AM
  • User1220545395 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, September 23, 2010 3:10 AM
  • User1220545395 posted

    I agree with Michael. I pointed out the IIS redirect as a means of providing a consistent user experience for file not found errors. Like Michael, I don't think it affects the security issue in a negative or positive manner. However, just to be sure, I've asked others on my team more versed in this security issue to review.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, September 23, 2010 11:21 AM

All replies

  • User-234406897 posted

    Use IIS's  Failed request tracing to trace through to see what is happening. I suspect a misconfiguration somewhere.

    Monday, September 20, 2010 2:30 PM
  • User-962338856 posted

    Use IIS's  Failed request tracing to trace through to see what is happening. I suspect a misconfiguration somewhere.

     

     

    Thank u for your answer, but like I said my app is on a hosted provider's server so no IIS access for me.

    Monday, September 20, 2010 3:47 PM
  • User564684961 posted

    Are you using .NET 3.5sp1 or straight up .NET 3.5?

    Tuesday, September 21, 2010 12:07 AM
  • User-962338856 posted

    Are you using .NET 3.5sp1 or straight up .NET 3.5?

     

    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?

    Tuesday, September 21, 2010 9:55 AM
  • User-158764254 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 10:14 AM
  • User1459398585 posted

    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 /

    Tuesday, September 21, 2010 12:00 PM
  • User1220545395 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, September 23, 2010 3:10 AM
  • User-158764254 posted

    Even if IIS used the custom error page for the 404, wouldnt the response code remain a 404 if IIS handled it? 

     

    Thursday, September 23, 2010 8:52 AM
  • User1459398585 posted

    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 /

    Thursday, September 23, 2010 11:00 AM
  • User1220545395 posted

    I agree with Michael. I pointed out the IIS redirect as a means of providing a consistent user experience for file not found errors. Like Michael, I don't think it affects the security issue in a negative or positive manner. However, just to be sure, I've asked others on my team more versed in this security issue to review.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, September 23, 2010 11:21 AM