Stack trace occuring with a crawler or hacker

[MCFHTAGENTS]

I am seeing the following stack trace in my log on a site running 3.1.2 - I think because either a crawler or would be hacker is trying to access the site with bad paths rather than any proper use of the site.

Please can it be handled better.

2020-03-14 22:20:23.415 +00:00 [ERR] An unhandled exception has occurred while executing the request.
System.InvalidOperationException: The path contains null characters.
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeCore(Int32& sourceIndex, Int32& destinationIndex, Span`1 buffer, Boolean isFormEncoding)
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeInPlace(Span`1 buffer, Boolean isFormEncoding)
   at Microsoft.AspNetCore.WebUtilities.FormPipeReader.GetDecodedString(ReadOnlySpan`1 readOnlySpan)
   at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ParseFormValuesFast(ReadOnlySpan`1 span, KeyValueAccumulator& accumulator, Boolean isFinalBlock, Int32& consumed)
   at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ParseFormValues(ReadOnlySequence`1& buffer, KeyValueAccumulator& accumulator, Boolean isFinalBlock)
   at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ReadFormAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgeryTokenStore.GetRequestTokensAsync(HttpContext httpContext)
   at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.ValidateRequestAsync(HttpContext httpContext)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.ValidateAntiforgeryTokenAuthorizationFilter.OnAuthorizationAsync(AuthorizationFilterContext context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Joonasw.AspNetCore.SecurityHeaders.Csp.CspMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)

[blowdart]

What would you expect to happen here? An exception isn't harmful, it isn't bringing your site down.

[MCFHTAGENTS]

It results in the log files becoming very large with the stack traces especially as it looks like some form of automated process is hitting the site - so some form of information to allow me to block it if malevolent or at least an expected error that doesn’t need a stack trace would be helpful

[blowdart]

That's fair, at least lack of stack trace anyway.

[davidfowl]

I'm not sure what it would do instead.

[MCFHTAGENTS]

I think just trap the exception - generate a error message without the stack trace and ideally tell us something about the bad request so we can block it or feedback the fault

[davidfowl]

Your code can do that. Today the exception handler middleware is logging the exception, you can disable that with the following logger configuration:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None"
    }
  },
  "AllowedHosts": "*"
}

[MCFHTAGENTS]

Thank you for that - this looks like it will block any logging from the ExceptionHandlerMiddleware component which feels a bit broadbrush to me in that it would stop any errors from this component and there may be others generated that are of value to me.

I also think it useful to know someone is up to something on the site - and as this is an expected exception think it probably should be handled.

[davidfowl]

So to be extremely specific. If this component cannot read the form for some reason it should log a different error and swallow this exception? That’s what you want ?

[MCFHTAGENTS]

David, Thansk I have changed one word on your summary:

If this component cannot read the form for some reason it should log an error and swallow this exception?

[Tratcher]

This falls into the class of things that the caller (MVC/Antiforgery) should be handling and generating a 400 response. It already does this for other types of AntiForgery errors in this callstack. @pranavkm

aspnetcore/src/Mvc/Mvc.ViewFeatures/src/Filters/ValidateAntiforgeryTokenAuthorizationFilter.cs

Lines 45 to 50 in 715ed24

	await _antiforgery.ValidateRequestAsync(context.HttpContext);
	}
	catch (AntiforgeryValidationException exception)
	{
	_logger.AntiforgeryTokenInvalid(exception.Message, exception);
	context.Result = new AntiforgeryValidationFailedResult();