Last post Sep 24, 2010 11:37 AM by i8beef
Sep 24, 2010 11:37 AM|i8beef|LINK
Alright, I've had a lot of conversations now regarding this, asked in several locations, and haven't really heard any definitive answers from anyone. This is particularly important for any MVC apps out there, where ResponseRewrite and error pages served
by an error controller won't work. We know that being able to differentiate between a 404 and a 500 error is the key to this attack. A ResponseRedirect setting provides the necessary coverage of the 404 / 500 error page differentiation (An attacker sees two
header responses, a 302 redirect and a 200 Successful retrieval of the error page in BOTH cases).
What I believe this does NOT cover, however, is the timing attacks.
In this case, the failure occurs BEFORE the 302 redirect. So any random wait we have in our error page / controller action is completely moot: The attacker already has his data in how long it took to return that 302 redirect. Using Response.Rewrite gets
around this as the attacker only sees ONE response header, a 200 success status, because the server executes the error page (and any random wait command) and then just returns the result to the current request without the redirect, thus the mitigation for
the timing attack (Weak as it is) functions as expected here.
Ergo, if you need to use ResponseRedirect, either because you use MVC with an error controller returning the error pages and don't want to build a separate temporary basic ASPX error page, or your (temporary) error page uses HttpContext members like session,
etc., then a different method is needed to implement the random wait. Scott's solution seems to be meant as a drop-in solution, particularly aimed at those with a lot of sites that they might not control that needed a quick solution, and indeed, pushing the
web.config change with a nearly static temporary error page will do this.
If you are in this situation and are the application developer though, I think that if you simply move the random wait code into the Global.asax Application_Error event that it will allow you to use ResponseRedirect as safely as ResponseRewrite.
If I'm missing something, someone please correct me, but I thought it'd be helpful to anyone attempting to to implement something akin to Scott Gu's blog post.
mvc ResponseRewrite ResponseRedirect security Application_Error