views:

385

answers:

3

I have a big problem. There are devices in live that send the URL "/updates ". It's a typo of the developer for those devices. In the server logs, it looks like "/updates+".

I have a ManageURL rewriting module that handles all requests without extension. But this request causes an HttpException:

System.Web.HttpException:

System.Web.HttpException
   at System.Web.Util.FileUtil.CheckSuspiciousPhysicalPath(String physicalPath)
   at System.Web.HttpContext.ValidatePath()
   at System.Web.HttpApplication.ValidatePathExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

As I see in the logs, the URL rewriting module does not even get this URL, so I cannot fix it there.

Is there a way to handle those URLs with ASP.NET?

A: 

If you have access to code why not just check for '+' at the end and remove it?

DroidIn.net
+1  A: 

According to some, this is in System.Web.dll:

internal static void CheckSuspiciousPhysicalPath(string physicalPath)
{
  if (((physicalPath != null) && (physicalPath.Length > 0))
    && (Path.GetFullPath(physicalPath) != physicalPath))
  {
    throw new HttpException(0x194, "");
  }
}

I guess you cannot change that, but can't one disable it in the IIS settings? Of course, that would also disable all other checks... :-(

Or write some ISAPI filter that runs before the above code? Writing your own module is said to be easy, according to Handle URI hacking gracefully in ASP.NET.

Or, create your own error page. In this page (like suggested in the URI hacking link above) search for specific text in exception.TargetSite.Name, such as CheckSuspiciousPhysicalPath and if found (or simply always) look at current.Request.RawUrl or something like that, clear the error and redirect to a repaired URL?

Arjan
Thanks.Sorry for not ansering so long.As temporary fix we create a 404 page.And find a way to change it on devices.Anyway this error pushed me to find a ISAPI module that can handle those issues.
AlfeG
Welcome back ;-) Actually, I guess Cheeso's answer about using an ISAPI rewriting filter might be an easy workaround. This would then hopefully run *before* the above code is executed -- but I think Cheeso is the author of that filter, and I trust the author knows best. The single upvote for Cheeso's answer is mine, so: did you read that answer?
Arjan
+1  A: 

you could run a URL-rewriting ISAPI, like IIRF.

Cheeso
IIRF was not an ideal solution for our application. I'm waiting for release of 2.0 version.
AlfeG
IIRF 2.0 is out and available, though not final. But there's nothing in the rewrite engine for IIRF v2.0 that you cannot get in IIRF v1.2.16.
Cheeso
Like I wrote in the comments of my own answer: I assume that IIRF runs prior to any built-in security in IIS? So, one could completely rewrite any URL (or: just strip an erroneous trailing space) before handling control to IIS, so before `CheckSuspiciousPhysicalPath` is invoked. Right? Seems like a good solution to me, but still the single upvote is mine. Am I missing the point here?
Arjan
@Arjan, no I don't think you are missing the point. You are correct that the ISAPI filter will run prior to System.Web.dll checking for a suspiscious path. My comment about IIRF v2.0 was directed to AlfeG, who said he was waiting for v2.0. I wanted to say, for rewrite purposes, there's no point in waiting. IIRF v1.2 or v2.0 will both accomplish the goal.
Cheeso
Exactly what I thought. (I did understand you were replying to AlfeG, but I just fail to understand why AlfeG thinks IIRF is *not* an easy solution, even if only to remove one space... Not such a big problem after all?)
Arjan