Prevención de ataques de falsificación de solicitud entre sitios (XSRF/CSRF) en ASP.NET Core

Por Fiyaz Hasan y Rick Anderson

La falsificación de solicitud entre sitios es un ataque contra aplicaciones hospedadas en web, en el que una aplicación web malintencionada puede influir en la interacción entre un explorador cliente y una aplicación web que confía en ese explorador. Estos ataques son posibles porque los exploradores web envían automáticamente algunos tipos de token de autenticación con cada solicitud en un sitio web. Esta forma de exploit también se conoce como ataque con un clic o secuestro de sesión porque el ataque aprovecha la sesión autenticada previamente del usuario. La falsificación de solicitudes entre sitios también se conoce como XSRF o CSRF.

Ejemplo de un ataque de CSRF:

1. Un usuario inicia sesión en www.good-banking-site.example.com con la autenticación de formularios. El servidor autentica al usuario y emite una respuesta que incluye una autenticación cookie. El sitio es vulnerable a ataques porque confía en cualquier solicitud que reciba con una cookie de autenticación válida.

2. El usuario visita un sitio malintencionado, www.bad-crook-site.example.com.

   El sitio malintencionado, www.bad-crook-site.example.com, contiene un formulario HTML similar al ejemplo siguiente:

   <h1>Congratulations! You're a Winner!</h1>
   <form action="https://www.good-banking-site.example.com/api/account" method="post">
       <input type="hidden" name="Transaction" value="withdraw" />
       <input type="hidden" name="Amount" value="1000000" />
       <input type="submit" value="Click to collect your prize!" />
   </form>
   

   Observe que el action del formulario publica en el sitio vulnerable, no en el sitio malintencionado. Esta es la parte "entre sitios" de CSRF.

3. El usuario selecciona el botón Enviar. El explorador realiza la solicitud e incluye automáticamente la cookie de autenticación para el dominio solicitado, www.good-banking-site.example.com.

4. La solicitud se ejecuta en el servidor de www.good-banking-site.example.com con el contexto de autenticación del usuario y puede realizar cualquier acción que un usuario autenticado pueda realizar.

Además del escenario en el que el usuario selecciona el botón para enviar el formulario, el sitio malintencionado podría:

• Ejecutar un script que envíe automáticamente el formulario.
• Enviar el envío del formulario como una solicitud AJAX.
• Ocultar el formulario mediante CSS.

Estos escenarios alternativos no requieren ninguna acción ni entrada por parte del usuario aparte de visitar inicialmente el sitio malintencionado.

El uso de HTTPS no impide un ataque de CSRF. El sitio malintencionado puede enviar https://www.good-banking-site.example.com/ una solicitud tan fácilmente como puede enviar una solicitud no segura.

Algunos ataques se dirigen a puntos de conexión que responden a solicitudes GET, en cuyo caso se puede usar una etiqueta de imagen para realizar la acción. Esta forma de ataque es común en sitios de foros que permiten imágenes pero bloquean JavaScript. Las aplicaciones que cambian el estado de las solicitudes GET, en las que se modifican variables o recursos, son vulnerables a ataques malintencionados. Las solicitudes GET que cambian de estado no son seguras. Un procedimiento recomendado es no cambiar nunca el estado en una solicitud GET.

Los ataques de CSRF se pueden producir en las aplicaciones web que usan cookies para la autenticación porque:

• Los exploradores almacenan cookies emitidas por una aplicación web.
• Las cookies almacenadas incluyen cookies de sesión para los usuarios autenticados.
• Los exploradores envían todas las cookies asociadas con un dominio a la aplicación web en cada solicitud independientemente de cómo se generó la solicitud a la aplicación en el explorador.

Sin embargo, los ataques CSRF no se limitan a aprovechar las vulnerabilidades de las cookies. Por ejemplo, la autenticación básica y Digest también son vulnerables. Una vez que un usuario inicia sesión con la autenticación básica o implícita, el explorador envía automáticamente las credenciales hasta que finaliza la sesión.

En este contexto, la sesión hace referencia a la sesión del lado cliente durante la cual se autentica el usuario. No está relacionado con las sesiones del servidor ni con el middleware de sesión de ASP.NET Core.

Para protegerse contra las vulnerabilidades de CSRF, los usuarios pueden tomar precauciones:

• Cierre la sesión de las aplicaciones web cuando termine de usarlas.
• Borra periódicamente las cookies del explorador.

Sin embargo, las vulnerabilidades de CSRF son fundamentalmente un problema con la aplicación web, no con el usuario final.

Aspectos básicos de la autenticación

La autenticación basada en Cookie es una forma popular de autenticación. Los sistemas de autenticación basados en tokens están creciendo en popularidad, especialmente para aplicaciones de página única (SPA).

Autenticación basada en Cookie

Cuando un usuario se autentica con su nombre de usuario y contraseña, se emite un token que contiene un vale de autenticación. El token se puede usar para la autenticación y autorización. El token se almacena como una cookie que se envía con cada solicitud que realiza el cliente. La generación y validación de este cookie se realiza con el middleware de autenticación cookie. El middleware serializa una entidad de seguridad de usuario en una cookie cifrada. En las solicitudes posteriores, el middleware valida la cookie, vuelve a crear la entidad de seguridad y asigna la entidad de seguridad a la propiedad HttpContext.User.

Autenticación basada en tokens

Cuando se autentica un usuario, se emite un token (no un token de antifalsificación). El token contiene información de usuario en forma de notificaciones o un token de referencia que apunta la aplicación al estado de usuario mantenido en la aplicación. Cuando un usuario intenta acceder a un recurso que requiere autenticación, el token se envía a la aplicación con un encabezado de autorización adicional en forma de token de portador. Este enfoque hace que la aplicación no tenga estado. En cada solicitud posterior, el token se pasa en la solicitud de validación del lado servidor. Este token no está cifrado; está codificado. En el servidor, el token se descodifica para acceder a su información. Para enviar el token en solicitudes posteriores, almacene el token en el almacenamiento local del explorador. Colocar un token en el almacenamiento local del explorador, recuperarlo y usarlo como token de portador proporciona protección contra ataques de CSRF. Sin embargo, si la aplicación es vulnerable a la inserción de scripts a través de XSS o un archivo javascript externo en peligro, un ciberdelincuente podría recuperar cualquier valor del almacenamiento local y enviárselo a sí mismo. ASP.NET Core codifica todas las salidas del lado servidor de las variables de forma predeterminada, lo que reduce el riesgo de XSS. Si invalida este comportamiento mediante Html.Raw o código personalizado con entradas que no son de confianza, puede aumentar el riesgo de XSS.

No se preocupe por la vulnerabilidad de CSRF si el token se almacena en el almacenamiento local del explorador. La CSRF es un problema cuando el token se almacena en una cookie. Para obtener más información, consulta el problema de GitHub El ejemplo de código SPA agrega dos cookies.

Varias aplicaciones hospedadas en un dominio

Los entornos de hospedaje compartidos son vulnerables al secuestro de sesión, a la CSRF de inicio de sesión y a otros ataques.

Aunque example1.contoso.net y example2.contoso.net son hosts diferentes, hay una relación de confianza implícita entre los hosts bajo el dominio *.contoso.net. Esta relación de confianza implícita permite que hosts que podrían no ser de confianza afecten a las cookies de otros hosts (las directivas de mismo origen que rigen las solicitudes AJAX no se aplican necesariamente a las cookies HTTP).

Los ataques que aprovechan las cookies de confianza entre aplicaciones hospedadas en el mismo dominio pueden evitarse si no se comparten dominios. Cuando cada aplicación se hospeda en su propio dominio, no hay ninguna relación de confianza implícita que se pueda aprovechar.

Antifalsificación en ASP.NET Core

Advertencia

ASP.NET Core implementa la antifalsificación mediante la Protección de datos de ASP.NET Core. La pila de protección de datos debe configurarse para que funcione en una granja de servidores. Para obtener más información, consulte Configuración de la protección de datos.

El middleware de antifalsificación se agrega al contenedor de inserción de dependencias cuando se llama a una de las siguientes API en Program.cs:

• AddMvc
• MapRazorPages
• MapControllerRoute
• AddRazorComponents

Para más información, consulte Antifalsificación con API mínima.

El elemento FormTagHelper inserta tokens antifalsificación en los elementos de formulario HTML. El siguiente marcado en un archivo de Razor genera automáticamente tokens de antifalsificación:

<form method="post">
    <!-- ... -->
</form>

De forma similar, IHtmlHelper.BeginForm genera tokens antifalsificación de forma predeterminada si el método del formulario no es GET.

La generación automática de tokens de antifalsificación para elementos de formulario HTML se produce cuando la etiqueta <form> contiene el atributo method="post" y se cumple alguna de las siguientes condiciones:

• El atributo action está vacío (action="").
• El atributo action no se proporciona (<form method="post">).

La generación automática de tokens de antifalsificación para elementos de formulario HTML se puede deshabilitar:

• Deshabilite explícitamente los tokens de antifalsificación con el atributo asp-antiforgery.

  <form method="post" asp-antiforgery="false">
      <!-- ... -->
  </form>
  

• El elemento de formulario se ha excluido de los asistentes de etiquetas mediante el símbolo de rechazo ! del asistente de etiquetas:

  <!form method="post">
      <!-- ... -->
  </!form>
  

• Quite FormTagHelper de la vista. FormTagHelper puede eliminarse de una vista mediante la adición de la siguiente directiva a la vista Razor.

  @removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers
  

Nota:

Las Razor páginas están protegidas automáticamente contra XSRF/CSRF. Para obtener más información, vea XSRF/CSRF y Razor Pages.

El enfoque más común para defenderse contra ataques de CSRF es usar el patrón de token del sincronizador (STP). El STP se usa cuando el usuario solicita una página con datos de formulario:

1. El servidor envía un token asociado a la identidad del usuario actual al cliente.
2. El cliente devuelve el token al servidor para su comprobación.
3. Si el servidor recibe un token que no coincide con la identidad del usuario autenticado, se rechaza la solicitud.

El token es único e imprevisible. El token también se puede usar para garantizar la secuenciación correcta de una serie de solicitudes (por ejemplo, garantizar la secuencia de solicitudes de: página 1 > página 2 > página 3). Todos los formularios de las plantillas de Razor Pages y de ASP.NET Core MVC generan tokens de antifalsificación. El siguiente par de ejemplos de vista genera tokens de antifalsificación:

<form asp-action="Index" asp-controller="Home" method="post">
    <!-- ... -->
</form>

@using (Html.BeginForm("Index", "Home"))
{
    <!-- ... -->
}

Agregue explícitamente un token de antifalsificación a un elemento <form> sin usar asistentes de etiquetas con el asistente de HTML @Html.AntiForgeryToken:

<form asp-action="Index" asp-controller="Home" method="post">
    @Html.AntiForgeryToken()

    <!-- ... -->
</form>

En cada uno de los casos anteriores, ASP.NET Core agrega un campo de formulario oculto similar al ejemplo siguiente:

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkS ... s2-m9Yw">

ASP.NET Core incluye tres filtros para trabajar con tokens de antifalsificación:

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• IgnoreAntiforgeryToken

Antifraude con AddControllers

La llamada a AddControllersno habilita tokens de antifalsificación. Se debe llamar a AddControllersWithViews para tener compatibilidad integrada con tokens de antifalsificación.

Varias pestañas del explorador y el patrón de token del sincronizador

No se admiten varias pestañas que inicien sesión como usuarios diferentes, o una que inicie sesión como anónima.

Configurar el sistema antifalsificación con AntiforgeryOptions

Personalice AntiforgeryOptions en el archivo Program de la aplicación.

builder.Services.AddAntiforgery(options =>
{
    // Set Cookie properties using CookieBuilder properties†.
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.SuppressXFrameOptionsHeader = false;
});

Establezca las propiedades de la cookie de antifalsificación mediante las propiedades de la clase CookieBuilder, como se muestra en la tabla siguiente.

Opción	Descripción
Cookie	Determina la configuración usada para crear las cookies de antifalsificación.
FormFieldName	Nombre del campo de formulario oculto utilizado por el sistema de antifalsificación para representar tokens de antifalsificación en vistas.
HeaderName	Nombre del encabezado utilizado por el sistema de antifalsificación. Si es null, el sistema solo tiene en cuenta los datos del formulario.
SuppressXFrameOptionsHeader	Especifica si se va a suprimir la generación del encabezado X-Frame-Options. De forma predeterminada, el encabezado se genera con un valor de "SAMEORIGIN". Tiene como valor predeterminado false.

Algunos exploradores no permiten que los puntos de conexión inseguros establezcan cookies con una marca "segura" o sobrescribir cookies cuya marca "segura" está establecida (para obtener más información, consulte Desuso de la modificación de cookies "seguras" de orígenes no seguros). Dado que la combinación de puntos de conexión seguros e inseguros es un escenario común en las aplicaciones, ASP.NET Core relaja la restricción de la directiva segura en algunas cookies, como la antifalsificación cookie, estableciendo el cookie de SecurePolicy en CookieSecurePolicy.None. Incluso si un usuario malintencionado roba un elemento de antifalsificación cookie, también debe robar el token de antifalsificación que normalmente se envía a través de un campo de formulario (más común) o de un encabezado de solicitud independiente (menos común), además de la autenticación cookie. Las cookies relacionadas con la autenticación o autorización usan una directiva más fuerte que CookieSecurePolicy.None.

Opcionalmente, puede proteger la protección contra falsificación cookie en entornos que no sean Development utilizando Capa de Conexión Segura (SSL), a través solo de HTTPS, estableciendo la siguiente propiedad AntiforgeryOptions.Cookie en el archivo de la aplicación Program.

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddAntiforgery(o =>
    {
        o.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Para obtener más información, vea CookieAuthenticationOptions.

Generación de tokens de antifalsificación con IAntiforgery

IAntiforgeryproporciona la API para configurar características de antifalsificación. IAntiforgery se puede solicitar en Program.cs mediante WebApplication.Services. En el ejemplo siguiente se usa middleware desde la página principal de la aplicación para generar un token de antiforgería y enviarlo en la respuesta como un cookie:

app.UseRouting();

app.UseAuthorization();

var antiforgery = app.Services.GetRequiredService<IAntiforgery>();

app.Use((context, next) =>
{
    var requestPath = context.Request.Path.Value;

    if (string.Equals(requestPath, "/", StringComparison.OrdinalIgnoreCase)
        || string.Equals(requestPath, "/index.html", StringComparison.OrdinalIgnoreCase))
    {
        var tokenSet = antiforgery.GetAndStoreTokens(context);
        context.Response.Cookies.Append("XSRF-TOKEN", tokenSet.RequestToken!,
            new CookieOptions { HttpOnly = false });
    }

    return next(context);
});

En el ejemplo anterior se establece una cookie denominada XSRF-TOKEN. El cliente puede leer esta cookie y proporcionar su valor como un encabezado adjunto a las solicitudes de AJAX. Por ejemplo, Angular incluye protección integrada contra XSRF que lee una cookie denominada XSRF-TOKEN de forma predeterminada.

Requerir validación de antifalsificación

El filtro de acción ValidateAntiForgeryToken se puede aplicar a una acción individual, un controlador o globalmente. Las solicitudes realizadas a las acciones que tienen aplicado este filtro se bloquean a menos que la solicitud incluya un token de antifalsificación válido:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Index()
{
    // ...

    return RedirectToAction();
}

El atributo ValidateAntiForgeryToken requiere un token para las solicitudes a los métodos de acción que marca, incluidas las solicitudes HTTP GET. Si el atributo ValidateAntiForgeryToken se aplica en los controladores de la aplicación, se puede invalidar con el atributo IgnoreAntiforgeryToken.

Validar automáticamente tokens de antifalsificación solo para métodos HTTP no seguros

En lugar de aplicar ampliamente el atributo ValidateAntiForgeryToken y, a continuación, reemplazarlo con atributos IgnoreAntiforgeryToken, se puede usar el atributo AutoValidateAntiforgeryToken. Este atributo funciona de forma idéntica al atributo ValidateAntiForgeryToken, salvo que no requiere tokens para las solicitudes realizadas mediante los siguientes métodos HTTP:

• GET
• HEAD
• Opciones
• TRACE

Se recomienda usar ampliamente AutoValidateAntiforgeryToken para escenarios que no son de API. Este atributo garantiza que las acciones POST estén protegidas de forma predeterminada. La alternativa es omitir los tokens de antifalsificación de forma predeterminada, a menos que ValidateAntiForgeryToken se aplique a métodos de acción individuales. Es más probable que en este escenario un método de acción POST se deje desprotegido por error, lo que hace que la aplicación sea vulnerable a los ataques de CSRF. Todos los POST deben enviar el token de antifalsificación.

Las API no tienen un mecanismo automático para enviar la parte del token que no es una cookie. La implementación probablemente depende de la implementación del código de cliente. A continuación se muestran algunos ejemplos:

Ejemplo de nivel de clase:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Ejemplo global:

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
});

Invalidación de atributos de antifalsificación globales o de controlador

El filtro IgnoreAntiforgeryToken se usa para evitar tener que usar un token de antifalsificación para una acción determinada (o controlador). Cuando se aplica, este filtro invalida los filtros ValidateAntiForgeryToken y AutoValidateAntiforgeryToken especificados en un nivel superior (global o en un controlador).

[IgnoreAntiforgeryToken]
public IActionResult IndexOverride()
{
    // ...

    return RedirectToAction();
}

Actualización de tokens después de la autenticación

Los tokens se deben actualizar después de que el usuario se autentique al redirigir al usuario a una vista o página de Razor Pages.

JavaScript, AJAX y SPA

En las aplicaciones tradicionales basadas en HTML, los tokens de antifalsificación se pasan al servidor mediante campos de formulario ocultos. En las aplicaciones y SPA modernas basadas en JavaScript, muchas solicitudes se realizan mediante programación. Estas solicitudes de AJAX pueden usar otras técnicas, como encabezados de solicitud o cookies, para enviar el token.

Si se usan cookies para almacenar tokens de autenticación y para autenticar solicitudes de API en el servidor, la CSRF es un posible problema. Si el almacenamiento local se usa para almacenar el token, se podría mitigar la vulnerabilidad de CSRF porque los valores del almacenamiento local no se envían automáticamente al servidor con cada solicitud. El uso del almacenamiento local para almacenar el token de antifalsificación en el cliente y enviar el token como encabezado de solicitud es un enfoque recomendado.

Blazor

Para obtener más información, consulte AutenticaciónBlazor y autorización de ASP.NET Core.

JavaScript

Al usar JavaScript con vistas, el token se puede crear mediante un servicio desde dentro de la vista. Inserte el servicio IAntiforgery en la vista y luego llame a GetAndStoreTokens.

@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Antiforgery

@{
    ViewData["Title"] = "JavaScript";

    var requestToken = Antiforgery.GetAndStoreTokens(Context).RequestToken;
}

<input id="RequestVerificationToken" type="hidden" value="@requestToken" />

<button id="button" class="btn btn-primary">Submit with Token</button>
<div id="result" class="mt-2"></div>

@section Scripts {
<script>
    document.addEventListener("DOMContentLoaded", () => {
        const resultElement = document.getElementById("result");

        document.getElementById("button").addEventListener("click", async () => {

            const response = await fetch("@Url.Action("FetchEndpoint")", {
                method: "POST",
                headers: {
                    RequestVerificationToken:
                        document.getElementById("RequestVerificationToken").value
                }
            });

            if (response.ok) {
                resultElement.innerText = await response.text();
            } else {
                resultElement.innerText = `Request Failed: ${response.status}`
            }
        });
    });
</script>
}

En el ejemplo anterior se usa JavaScript para leer el valor de campo oculto del encabezado POST de AJAX.

Este enfoque evita tener que tratar directamente con la configuración de cookies del servidor o leerlas del cliente. Sin embargo, si no es posible insertar el servicio IAntiforgery, usa JavaScript para acceder a tokens en cookies:

• Acceda a tokens en una solicitud adicional al servidor, normalmente same-origin.
• Use el contenido de la cookie para crear un encabezado con el valor del token.

Suponiendo que el script envía el token en un encabezado de solicitud denominado X-XSRF-TOKEN, configure el servicio de antifalsificación para buscar el encabezado X-XSRF-TOKEN:

builder.Services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

En el ejemplo siguiente se agrega un punto de conexión protegido que escribe el token de solicitud en una cookie legible en JavaScript:

app.UseAuthorization();
app.MapGet("antiforgery/token", (IAntiforgery forgeryService, HttpContext context) =>
{
    var tokens = forgeryService.GetAndStoreTokens(context);
    context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken!,
            new CookieOptions { HttpOnly = false });

    return Results.Ok();
}).RequireAuthorization();

En el ejemplo siguiente se usa JavaScript para realizar una solicitud de AJAX para obtener el token y realizar otra solicitud con el encabezado adecuado:

var response = await fetch("/antiforgery/token", {
    method: "GET",
    headers: { "Authorization": authorizationToken }
});

if (response.ok) {
    // https://developer.mozilla.org/docs/web/api/document/cookie
    const xsrfToken = document.cookie
        .split("; ")
        .find(row => row.startsWith("XSRF-TOKEN="))
        .split("=")[1];

    response = await fetch("/JavaScript/FetchEndpoint", {
        method: "POST",
        headers: { "X-XSRF-TOKEN": xsrfToken, "Authorization": authorizationToken }
    });

    if (response.ok) {
        resultElement.innerText = await response.text();
    } else {
        resultElement.innerText = `Request Failed: ${response.status}`
    }
} else {    
    resultElement.innerText = `Request Failed: ${response.status}`
}

Nota:

Cuando el token antifalsificación se proporciona tanto en la cabecera de la solicitud como en la carga útil del formulario, sólo se valida el token de la cabecera.

Antifalsificación con API mínimas

Llame a AddAntiforgery y UseAntiforgery(IApplicationBuilder) para registrar servicios de antifalsificación en la inserción de dependencias. Los tokens de antifalsificación se usan para mitigar losataques de falsificación de solicitud entre sitios.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

app.MapGet("/", () => "Hello World!");

app.Run();

Middleware de antifalsificación:

• No cortocircuita la ejecución del resto de la canalización de solicitudes.
• Establece el IAntiforgeryValidationFeature en el HttpContext.Features de la petición actual.

El token de antifalsificación solo se valida si:

• El punto de conexión contiene metadatos que implementan IAntiforgeryMetadata donde RequiresValidation=true.
• El método HTTP asociado al punto de conexión es un método HTTP relevante de tipo POST, PUT o PATCH.
• La solicitud está asociada a un punto de conexión válido.

El middleware contra falsificación no interrumpe la canalización de solicitudes. El código de punto de conexión siempre se ejecuta, incluso si se produce un error en la validación de tokens. Para observar el resultado de la validación del token, resuelva el IAntiforgeryValidationFeature desde HttpContext.Features e inspeccione su propiedad IsValid o la propiedad Error para obtener detalles de la falla. Este enfoque es útil cuando los puntos de conexión requieren un manejo personalizado para la validación antifalsificación fallida.

Nota: cuando se habilita manualmente, el middleware de antifalsificación debe ejecutarse después del middleware de autenticación y autorización para evitar la lectura de datos del formulario cuando el usuario no está autenticado.

De forma predeterminada, las API mínimas que aceptan datos de formulario requieren validación de tokens antiforgería y producen un error antes de ejecutar código de aplicación si la validación antiforgería no se realiza correctamente.

Observe el método GenerateForm siguiente:

public static string GenerateForm(string action, 
    AntiforgeryTokenSet token, bool UseToken=true)
{
    string tokenInput = "";
    if (UseToken)
    {
        tokenInput = $@"<input name=""{token.FormFieldName}""
                         type=""hidden"" value=""{token.RequestToken}"" />";
    }

    return $@"
    <html><body>
        <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
            {tokenInput}
            <input type=""text"" name=""name"" />
            <input type=""date"" name=""dueDate"" />
            <input type=""checkbox"" name=""isCompleted"" />
            <input type=""submit"" />
        </form>
    </body></html>
";
}

El código anterior tiene tres argumentos, la acción, el token antifalsificación y un elemento bool que indica si se debe usar el token.

Observe el ejemplo siguiente:

using Microsoft.AspNetCore.Antiforgery;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

// Pass token
app.MapGet("/", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo", token), "text/html");
});

// Don't pass a token, fails
app.MapGet("/SkipToken", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo",token, false ), "text/html");
});

// Post to /todo2. DisableAntiforgery on that endpoint so no token needed.
app.MapGet("/DisableAntiforgery", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo2", token, false), "text/html");
});

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

app.Run();

class Todo
{
    public required string Name { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime DueDate { get; set; }
}

public static class MyHtml
{
    public static string GenerateForm(string action, 
        AntiforgeryTokenSet token, bool UseToken=true)
    {
        string tokenInput = "";
        if (UseToken)
        {
            tokenInput = $@"<input name=""{token.FormFieldName}""
                             type=""hidden"" value=""{token.RequestToken}"" />";
        }

        return $@"
        <html><body>
            <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
                {tokenInput}
                <input type=""text"" name=""name"" />
                <input type=""date"" name=""dueDate"" />
                <input type=""checkbox"" name=""isCompleted"" />
                <input type=""submit"" />
            </form>
        </body></html>
    ";
    }
}

En el código anterior se envía a:

• /todo requerir un token de antifalsificación válido.
• /todo2 no requieren un token de antifalsificación válido porque se llama a DisableAntiforgery.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Advertencia

La llamada .DisableAntiforgery() deshabilita la protección contra la falsificación de solicitud entre sitios (CSRF) para el endpoint. Esto solo se debe usar cuando un punto de conexión no es vulnerable a ataques CSRF, como:

• Puntos de conexión que no se pueden llamar desde un explorador (por ejemplo, API internas)
• Puntos de conexión protegidos con autenticación no basada en cookie (por ejemplo, tokens de portadora o claves API)
• Puntos de conexión internos o de infraestructura que no dependen de cookies de usuario

No deshabilite la validación antiforgería para los puntos de conexión accesibles para exploradores que dependen de cookies para la autenticación o que procesan los datos de formulario enviados por el usuario, ya que esto expone la aplicación a ataques CSRF.

Una MENSAJE para:

• /todo del formulario generado por el punto de conexión / se realiza correctamente porque el token de antifalsificación es válido.
• /todo del formulario generado por el error /SkipToken porque no se incluye la antifalsificación.
• /todo2 del formulario generado por el punto de conexión /DisableAntiforgery se realiza correctamente porque no se requiere la antifalsificación.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Cuando se envía un formulario sin un token de antifalsificación válido:

• En el Development entorno, se produce una excepción.
• En el Production entorno, se registra un mensaje.

Limitaciones del método HTTP e HttpMethodOverrideMiddleware interacción

Para el método antifalsificación basado en middleware, AntiforgeryMiddleware y UseAntiforgery() validan los tokens de antifalsificación solo para las solicitudes HTTP POST, PUT y PATCH. Otros métodos HTTP, como DELETE, no se validan automáticamente.

Para validar tokens antifalsificación para otros métodos HTTP, resuelva IAntiforgery desde DI y llame a ValidateRequestAsync o IsRequestValidAsync explícitamente:

app.MapDelete("/item/{id}", async (int id, IAntiforgery antiforgery, HttpContext context) =>
{
    await antiforgery.ValidateRequestAsync(context);
    // Process the DELETE request
});

Advertencia

Cuando HttpMethodOverrideMiddleware se configura con FormFieldName (modo de campo de formulario) y se coloca antes de AntiforgeryMiddleware, una solicitud POST puede sustituirse por DELETE (u otro método no validado). Dado que AntiforgeryMiddleware valida solo POST, PUT y PATCH, la solicitud invalidada omite la validación antiforgería.

Para proteger estos puntos de conexión:

• Es preferible colocar HttpMethodOverrideMiddleware después de la validación antifalsificación si tu flujo de procesamiento lo permite.
• Evite sobrescribir campos de formulario en los endpoints que dependen de la validación antifalsificación.
• Si la anulación del campo de formulario debe ejecutarse primero, valide explícitamente el token contra falsificación mediante IAntiforgery.ValidateRequestAsync.

Para obtener más información sobre la configuración, consulte ASP.NET Core middleware.

Autenticación de Windows y cookies antifalsificación

Al usar la autenticación de Windows, los puntos de conexión de la aplicación deben protegerse frente a ataques de CSRF de la misma manera que se hace para las cookies. El explorador envía implícitamente el contexto de autenticación al servidor y los puntos de conexión deben protegerse frente a ataques de CSRF.

Extensión de la antifalsificación

El tipo IAntiforgeryAdditionalDataProvider permite a los desarrolladores ampliar el comportamiento del sistema anti-CSRF mediante el recorrido de ida y vuelta de datos adicionales en cada token. Se llama al método GetAdditionalData cada vez que se genera un token de campo; el valor devuelto se inserta dentro del token generado. Un implementador podría devolver una marca de tiempo, un valor nonce o cualquier otro valor y, a continuación, llamar a ValidateAdditionalData para validar estos datos cuando se valida el token. El nombre de usuario del cliente ya está insertado en los tokens generados, por lo que no es necesario incluir esta información. Si un token incluye datos complementarios pero no se configura un IAntiForgeryAdditionalDataProvider, los datos complementarios no se validan.

Recursos adicionales

• Hospedaje de ASP.NET Core en una granja de servidores web