Add antiforgery (anti-csrf) support to minimal endpoints

[halter73]

Today, Antiforgery is implemented as a filter in MVC. There's an attribute that also acts as an auth filter. It reads the form and performs a validation. Razor Pages add an implicit antiforgery filter that is active for all non-idempotent (POST / PUT / DELETE etc) requests. We'd like to enable Antiforgery to become available outside of MVC. My goal was to continue relying on these attributes, but as metadata that indicated if the user intended to perform antiforgery validation for that endpoint.

In minimal endpoints, this might look like:

app.MapPost("/post", (IFormFile formFile) => { ... })
    .ValidateAntiforgery(); // Maybe we can infer this based on the presence of things that come from a HTTP form.

Generating the antiforgery token that goes in to the form is still tied to the app framework. MVC will generate if you're using the form tag helper / Html.BeginForm(). For a form post using minimal, a user can use the IAntiforgery service to produce it. This PR doesn't attempt to make that experience better.

#38314 (comment)

Thanks @pranavkm for the Antiforgery middleware PR and the nice description in the comments. And extra thanks to @martincostello for adding support for form file parameters to minimal endpoints with #35158!

Now that it is possible to accept IFormFile and IFormFileCollection parameters in minimal actions, we will need to require an antiforgery token for all authenticated endpoints taking these parameter types. Right now, because we don't check for an antiforgery token on these endpoints, we reject any request with a cookie, cert or auth header.

I don't think we'll end up needing the .ValidateAntiforgery() extension method, but maybe that would be useful for endpoints manually consuming a form from the HttpRequest.

Since minimal endpoints are not opinionated about the client app language or framework, having a single solution for generating and sending the antiforgery token is difficult. The current IAntiforgery service interface is built around idea that the client will be performing a request before posting form data and will be able to send a cookie set during that prior request during the actual POST. This makes sense for web clients, but we want to make uploading files easier for non-web clients as well because "multipart/form-data" is one of the most widely adopted ways to upload files over HTTP.

My understanding is that the cookie is there to prevent an attacker from laundering an antiforgery token meant for a different user. It would be more convenient if this could be done without a cookie and instead with a single token tied to the IPrincipal in some other way.

@blowdart

[blowdart]

The whole point of our CSRF is a dual token approach, and it's a well understood approach. The cookie is there both for user checks, and also for things coming from other sites, which can happen with shared domain suffixes such as azurewebsites.net

However if you want to propose something different @GrabYourPitchforks and I will listen.

[davidfowl]

This isn't just for minimal APIs right? It's also for ApiControllers as well?

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[GrabYourPitchforks]

As a reminder, CSRF is only a concern for endpoints that use "ambient" authentication. By "ambient" I mean something that flows automatically as part of the request without active consent by the user: cookies, NTLM auth, client certs, etc.

For things like standard API calls, where authentication flows as part of a manually added Authorize request header, CSRF is not a concern and no checks are needed.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.