Invalid form key returns internal server error

[Sanjidhalim]

When sending a request with content type application/x-www-form-urlencoded and a malformed key in the request body (e.g. [spc=123) ASP NET Core throws an Internal Server Error with the following stack trace:

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.ArgumentException: The key '[spc' is invalid JQuery syntax because it is missing a closing bracket. (Parameter 'key')
         at Microsoft.AspNetCore.Mvc.ModelBinding.JQueryKeyValuePairNormalizer.NormalizeJQueryToMvc(StringBuilder builder, String key)
         at Microsoft.AspNetCore.Mvc.ModelBinding.JQueryKeyValuePairNormalizer.GetValues(IEnumerable`1 originalValues, Int32 valueCount)
         at Microsoft.AspNetCore.Mvc.ModelBinding.JQueryFormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
         at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
         at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.TryCreateAsync(ActionContext actionContext, IList`1 factories)
         at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
         at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
         at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)         at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)         at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
         at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
         at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
         at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
         at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Bad user input should return a Bad Request response instead.

Repro steps

• Create a new ASP.NET Core Web API project (.NET 6) using the project template
• Modify the WeatherForecastController to Get method to:

      [HttpPost(Name = "GetWeatherForecast")]
      public IEnumerable<WeatherForecast> Get([FromForm] string spc)
      {
          return Enumerable.Range(1, 5).Select(index => new WeatherForecast
          {
              Date = DateTime.Now.AddDays(index),
              TemperatureC = Random.Shared.Next(-20, 55),
              Summary = Summaries[Random.Shared.Next(Summaries.Length)]
          })
          .ToArray();
      }

• Send the following HTTP request:

  
  POST https://localhost:7040/WeatherForecast HTTP/1.1
  User-Agent: Fiddler
  Content-Type: application/x-www-form-urlencoded
  Host: localhost:7040
  Content-Length: 8

[spc=123

[captainsafia]

Triage: Referencing this to https://github.com/dotnet/aspnetcore/issues/37857.

We're considering not registering the JQuery form validator by default in MVC applications. In the meantime, you can deregister it yourself by modifying the service collection when initializing MVC in your application.

Bad user input should return a Bad Request response instead.

The ApiController has a set of built-in defaults for how it handles 4xx validation cases. Applying the FromForm attribute to a parameter opts out of this behavior. To work around this, you can apply a filter to process this.

Marking as investigate to evaluate the intersection of model binding validation and 4xx response processing here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

Triage: cc: @brunolins16 for his interest in the area

[brunolins16]

@Sanjidhalim While we still working on the consideration described here #37857. you could remove the JQueryFormValueProviderFactory in your application if the JQuery support is not needed.

builder.Services.Configure<MvcOptions>(options => { 
    options.ValueProviderFactories.RemoveType<JQueryFormValueProviderFactory>();
});

That will produce the expected result:

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "traceId": "00-577f8b3ea47d08e2cd4f44f33043be22-9be5d970557866de-00",
    "errors": {
        "spc": [
            "The spc field is required."
        ]
    }
}

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.