Marco de seguridad: Administración de sesiones

Producto o servicio Artículo
Azure AD
Dispositivo IoT
Azure Document DB
ADFS
Identity Server
Aplicación web
API web

Implemente el cierre de sesión correcto mediante métodos ADAL cuando use Azure AD

Título Detalles
Componente Azure AD
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Si la aplicación se basa en el token de acceso emitido por Azure AD, el controlador de eventos de cierre de sesión debe realizar una llamada.

Ejemplo

HttpContext.GetOwinContext().Authentication.SignOut(OpenIdConnectAuthenticationDefaults.AuthenticationType, CookieAuthenticationDefaults.AuthenticationType)

Ejemplo

También debe destruir la sesión del usuario llamando al método Session.Abandon(). En el siguiente método, se muestra una implementación segura del cierre de sesión del usuario:

    [HttpPost]
        [ValidateAntiForgeryToken]
        public void LogOff()
        {
            string userObjectID = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
            AuthenticationContext authContext = new AuthenticationContext(Authority + TenantId, new NaiveSessionCache(userObjectID));
            authContext.TokenCache.Clear();
            Session.Clear();
            Session.Abandon();
            Response.SetCookie(new HttpCookie("ASP.NET_SessionId", string.Empty));
            HttpContext.GetOwinContext().Authentication.SignOut(
                OpenIdConnectAuthenticationDefaults.AuthenticationType,
                CookieAuthenticationDefaults.AuthenticationType);
        } 

Use duraciones finitas para los tokens de SaS generados

Título Detalles
Componente Dispositivo IoT
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Los tokens de SaS generados para la autenticación en Azure IoT Hub deben tener un período finito de expiración. Mantenga las duraciones de los tokens de SaS en un mínimo para limitar el período de tiempo que se pueden reproducir en caso de que los tokens se vean en peligro.

Use duraciones mínimas de token para los tokens de recursos generados

Título Detalles
Componente Azure DocumentDB
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Reduzca el intervalo de tiempo del token de recurso a un valor mínimo necesario. Los tokens de recursos tienen un intervalo de tiempo válido predeterminado de 1 hora.

Implemente el cierre de sesión correcto mediante métodos WsFederation cuando use ADFS

Título Detalles
Componente ADFS
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Si la aplicación se basa en un token de STS emitido por ADFS, el controlador de eventos de cierre de sesión debe llamar al método WSFederationAuthenticationModule.FederatedSignOut() para cerrar la sesión del usuario. Además, se debe destruir la sesión actual, y se debe restablecer y anular el valor del token de sesión.

Ejemplo

        [HttpPost, ValidateAntiForgeryToken]
        [Authorization]
        public ActionResult SignOut(string redirectUrl)
        {
            if (!this.User.Identity.IsAuthenticated)
            {
                return this.View("LogOff", null);
            }

            // Removes the user profile.
            this.Session.Clear();
            this.Session.Abandon();
            HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
                {
                    Expires = DateTime.Now.AddDays(-1D),
                    Secure = true,
                    HttpOnly = true
                });

            // Signs out at the specified security token service (STS) by using the WS-Federation protocol.
            Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
            Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
            if (!string.IsNullOrEmpty(redirectUrl))
            {
                replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
            }
           //     Signs out of the current session and raises the appropriate events.
            var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
            authModule.SignOut(false);
        //     Signs out at the specified security token service (STS) by using the WS-Federation
        //     protocol.            
            WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
            return new RedirectResult(redirectUrl);
        }

Implemente el cierre de sesión correcto cuando use Identity Server

Título Detalles
Componente Identity Server
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias IdentityServer3-Federated Signout (Cierre de sesión federado en IdentityServer3)
Pasos IdentityServer admite la capacidad de federación con proveedores de identidades externos. Cuando un usuario cierra sesión en un proveedor de identidades precedente, según el protocolo que se use, podría ser posible recibir una notificación cuando el usuario cierre la sesión. Esto permite, a su vez, que IdentityServer notifique a sus clientes para que también cierren la sesión del usuario. Consulte la documentación en la sección Referencias para ver los detalles de la implementación.

Las aplicaciones disponibles a través de HTTPS deben usar cookies seguras

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos EnvironmentType - OnPrem
Referencias httpCookies (Elemento, Esquema de configuración de ASP.NET), Propiedad HttpCookie.Secure
Pasos Normalmente, las cookies solo son accesibles para el dominio a cuyo ámbito se limitaron. Lamentablemente, la definición de "dominio" no incluye el protocolo, así que las cookies que se crean a través de HTTPS son accesibles a través de HTTP. El atributo "secure" indica al explorador que la cookie solo debe estar disponible a través de HTTPS. Asegúrese de que todas las cookies establecidas a través de HTTPS usen el atributo secure. Para aplicar el requisito en el archivo Web.config, establezca el atributo requireSSL en true. Se trata del método preferido porque aplicará el atributo secure para todas las cookies actuales y futuras sin necesidad de que se realice ningún otro cambio en el código.

Ejemplo

<configuration>
  <system.web>
    <httpCookies requireSSL="true"/>
  </system.web>
</configuration>

La configuración se aplica incluso si se usa HTTP para tener acceso a la aplicación. Si se utiliza HTTP para tener acceso a la aplicación, la configuración la interrumpe porque las cookies están establecidas con el atributo secure y el explorador no las enviará de vuelta a la aplicación.

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms, MVC5
Atributos EnvironmentType - OnPrem
Referencias N/D
Pasos Cuando la aplicación web es el usuario de confianza y el proveedor de identidades es el servidor AD FS, se puede configurar el atributo secure del token FedAuth estableciendo requireSSL en True en la sección system.identityModel.services del archivo Web.config:

Ejemplo

  <system.identityModel.services>
    <federationConfiguration>
      <!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
      <cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
    ....  
    </federationConfiguration>
  </system.identityModel.services>
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias Atributo de cookie segura
Pasos Para mitigar el riesgo de divulgación de información por un ataque de scripting entre sitios (XSS), se incorporó un nuevo atributo (httpOnly) a las cookies, el cual es compatible con todos los exploradores principales. El atributo especifica que una cookie no es accesible a través de un script. Al usar cookies HttpOnly, una aplicación web reduce la posibilidad de que se robe mediante un script la información confidencial contenida en la cookie y se envíe al sitio web de un atacante.

Ejemplo

Todas las aplicaciones basadas en HTTP que usen cookies deben especificar HttpOnly en la definición de la cookie; para ello, se debe implementar la siguiente configuración en el archivo Web.config:

<system.web>
.
.
   <httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms
Atributos N/D
Referencias Propiedad FormsAuthentication.RequireSSL
Pasos El valor de la propiedad RequireSSL se establece en el archivo de configuración para una aplicación ASP.NET mediante el atributo requireSSL del elemento de configuración. Puede especificar en el archivo Web.config de la aplicación ASP.NET si se requiere Seguridad de la capa de transporte (TLS), conocido anteriormente como SSL (Capa de sockets seguros), para devolver la cookie de autenticación de formularios al servidor estableciendo el atributo requireSSL.

Ejemplo

En el ejemplo de código siguiente, se establece el atributo requireSSL en el archivo Web.config.

<authentication mode="Forms">
  <forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables MVC5
Atributos EnvironmentType - OnPrem
Referencias Windows Identity Foundation (WIF) Configuration – Part II (Configuración de Windows Identity Foundation: parte II)
Pasos Para establecer el atributo httpOnly para las cookies FedAuth, el valor del atributo hideFromScript se debe establecer en True.

Ejemplo

En el siguiente ejemplo se muestra la configuración correcta:

<federatedAuthentication>
<cookieHandler mode="Custom"
                       hideFromScript="true"
                       name="FedAuth"
                       path="/"
                       requireSsl="true"
                       persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>

Mitigue el riesgo de ataques de falsificación de solicitud entre sitios (CSRF) en páginas web ASP.NET

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos La falsificación de solicitud entre sitios (CSRF o XSRF) es un tipo de ataque en el que un atacante puede llevar a cabo acciones en el contexto de seguridad de una sesión establecida de un usuario diferente en un sitio web. El objetivo es modificar o eliminar contenido, si el sitio web de destino confía exclusivamente en cookies de sesión para autenticar la solicitud recibida. Un atacante podría aprovechar esta vulnerabilidad y hacer que el explorador de un usuario diferente cargue una dirección URL con un comando procedente de un sitio vulnerable en el que el usuario ya haya iniciado sesión. Hay muchas maneras de hacerlo, como hospedar un sitio web diferente que carga un recurso desde el servidor vulnerable o conseguir que el usuario haga clic en un vínculo. El ataque se puede evitar si el servidor envía un token adicional al cliente, requiere que el cliente lo incluya en todas las solicitudes futuras y comprueba que todas las solicitudes futuras incluyan un token asociado a la sesión actual, como con los métodos AntiForgeryToken o ViewState de ASP.NET.
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables MVC5, MVC6
Atributos N/D
Referencias XSRF/CSRF Prevention in ASP.NET MVC and Web Pages (Prevención de XSRF y CSRF en ASP.NET MVC y Web Pages)
Pasos En formularios anti-CSRF y de ASP.NET MVC: use el método del asistente AntiForgeryToken en vistas; incluya un elemento Html.AntiForgeryToken() en el formulario, como en el siguiente ejemplo.

Ejemplo

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 

Ejemplo

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Ejemplo

Al mismo tiempo, Html.AntiForgeryToken() proporciona al visitante una cookie denominada __RequestVerificationToken, con el mismo valor que el valor aleatorio de hidden mostrado arriba. A continuación, para validar un envío de formulario entrante, agregue el filtro [ValidateAntiForgeryToken] al método de acción de destino. Por ejemplo:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtro de autorización que comprueba que:

  • La solicitud entrante tenga una cookie denominada __RequestVerificationToken;
  • La solicitud entrante tenga una entrada Request.Form denominada __RequestVerificationToken;
  • Estos valores de cookie y Request.Form coincidan. Suponiendo que todo sea correcto, la solicitud entra de la forma normal. De lo contrario, aparece un error de autorización con el mensaje "No se especificó un token antifalsificación o el que se especificó no era válido".

Ejemplo

Anti-CSRF y AJAX: el token de formulario puede ser un problema para las solicitudes AJAX, porque estas podrían enviar datos JSON en lugar de datos de formulario HTML. Una solución consiste en enviar los tokens en un encabezado HTTP personalizado. En el código siguiente, se utiliza sintaxis de Razor para generar los tokens, que después se agregan a una solicitud AJAX.

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }

    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

Ejemplo

Cuando procese la solicitud, extraiga los tokens del encabezado de la solicitud. Después, llame al método AntiForgery.Validate para validar los tokens. El método Validate produce una excepción si los tokens no son válidos.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms
Atributos N/D
Referencias Cómo aprovechar las ventajas de las características integradas de ASP.NET para rechazar los ataques a través de Internet
Pasos Los ataques CSRF en aplicaciones basadas en formularios Web Forms se pueden mitigar si se establece ViewStateUserKey en una cadena aleatoria que varíe para cada usuario, como el id. de usuario o, mejor aún, el identificador de sesión. Por diversas razones técnicas y sociales, el id. de sesión es mucho más adecuado porque es imprevisible, agota el tiempo de espera y varía para cada usuario.

Ejemplo

Este es el código que debe tener en todas las páginas:

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Configure la sesión para la duración de la inactividad

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias Propiedad HttpSessionState.Timeout
Pasos El tiempo de espera de la sesión representa el evento que se produce cuando un usuario no realiza ninguna acción en un sitio web durante un intervalo (definido por el servidor web). El evento, en el servidor, cambia el estado de la sesión del usuario a "inválido" (por ejemplo, "ya no se usa") e indica al servidor web que lo destruya (se eliminan todos los datos que contiene). En el ejemplo de código siguiente, se establece el atributo de sesión de tiempo de espera en 15 minutos en el archivo Web.config.

Ejemplo

<configuration>
  <system.web>
    <sessionState mode="InProc" cookieless="true" timeout="15" />
  </system.web>
</configuration>

Habilitamiento de la detección de amenazas en Azure SQL

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms
Atributos N/D
Referencias Elemento forms para authentication (Esquema de configuración de ASP.NET)
Pasos Establezca el tiempo de espera de la cookie para el vale de autenticación de formularios en 15 minutos.

Ejemplo

<forms  name=".ASPXAUTH" loginUrl="login.aspx"  defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Formularios Web Forms, MVC5
Atributos EnvironmentType - OnPrem
Referencias asdeqa
Pasos Cuando la aplicación web es Usuario de confianza y ADFS es el STS, la duración de las cookies de autenticación (tokens de FedAuth) se puede establecer mediante la siguiente configuración en web.config:

Ejemplo

  <system.identityModel.services>
    <federationConfiguration>
      <!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
      <cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
      <!-- Set requireHttps=true; -->
      <wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
      <!--
      Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
      <serviceCertificate>
        <certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
      </serviceCertificate>
      -->
    </federationConfiguration>
  </system.identityModel.services>

Ejemplo

Además, la duración del token de notificación SAML emitido por ADFS se debe establecer en 15 minutos ejecutando el siguiente comando de PowerShell en el servidor de AD FS:

Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true

Implemente el cierre de sesión correcto desde la aplicación

Título Detalles
Componente Aplicación web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos Realice el cierre de sesión correctamente desde la aplicación, cuando el usuario presione el botón de cierre de sesión. Al cerrar la sesión, la aplicación debe destruir la sesión del usuario y también restablecer y anular el valor de la cookie de la sesión, así como restablecer y anular el valor de la cookie de autenticación. Además, cuando hay varias sesiones asociadas a una sola identidad de usuario, se deben finalizar colectivamente en el lado servidor cuando se agote el tiempo de espera o se produzca el cierre de sesión. Por último, asegúrese de que la funcionalidad de cierre de sesión esté disponible en todas las páginas.

Mitigue el riesgo de ataques de falsificación de solicitud entre sitios (CSRF) en las API web de ASP.NET

Título Detalles
Componente API Web
Fase de SDL Build
Tecnologías aplicables Genérico
Atributos N/D
Referencias N/D
Pasos La falsificación de solicitud entre sitios (CSRF o XSRF) es un tipo de ataque en el que un atacante puede llevar a cabo acciones en el contexto de seguridad de una sesión establecida de un usuario diferente en un sitio web. El objetivo es modificar o eliminar contenido, si el sitio web de destino confía exclusivamente en cookies de sesión para autenticar la solicitud recibida. Un atacante podría aprovechar esta vulnerabilidad y hacer que el explorador de un usuario diferente cargue una dirección URL con un comando procedente de un sitio vulnerable en el que el usuario ya haya iniciado sesión. Hay muchas maneras de hacerlo, como hospedar un sitio web diferente que carga un recurso desde el servidor vulnerable o conseguir que el usuario haga clic en un vínculo. El ataque se puede evitar si el servidor envía un token adicional al cliente, requiere que el cliente lo incluya en todas las solicitudes futuras y comprueba que todas las solicitudes futuras incluyan un token asociado a la sesión actual, como con los métodos AntiForgeryToken o ViewState de ASP.NET.
Título Detalles
Componente API Web
Fase de SDL Build
Tecnologías aplicables MVC5, MVC6
Atributos N/D
Referencias Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API (Prevención de ataques de falsificación de solicitud entre sitios [CSRF] en ASP.NET Web API)
Pasos Anti-CSRF y AJAX: el token de formulario puede ser un problema para las solicitudes AJAX, porque estas podrían enviar datos JSON en lugar de datos de formulario HTML. Una solución consiste en enviar los tokens en un encabezado HTTP personalizado. En el código siguiente, se utiliza sintaxis de Razor para generar los tokens, que después se agregan a una solicitud AJAX.

Ejemplo

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }
    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

Ejemplo

Cuando procese la solicitud, extraiga los tokens del encabezado de la solicitud. Después, llame al método AntiForgery.Validate para validar los tokens. El método Validate produce una excepción si los tokens no son válidos.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

Ejemplo

En formularios anti-CSRF y de ASP.NET MVC: use método del asistente AntiForgeryToken en vistas; incluya un elemento Html.AntiForgeryToken() en el formulario, como en el siguiente ejemplo.

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 
}

Ejemplo

La salida se parecerá a lo siguiente:

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Ejemplo

Al mismo tiempo, Html.AntiForgeryToken() proporciona al visitante una cookie denominada __RequestVerificationToken, con el mismo valor que el valor aleatorio de hidden mostrado arriba. A continuación, para validar un envío de formulario entrante, agregue el filtro [ValidateAntiForgeryToken] al método de acción de destino. Por ejemplo:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtro de autorización que comprueba que:

  • La solicitud entrante tenga una cookie denominada __RequestVerificationToken;
  • La solicitud entrante tenga una entrada Request.Form denominada __RequestVerificationToken;
  • Estos valores de cookie y Request.Form coincidan. Suponiendo que todo sea correcto, la solicitud entra de la forma normal. De lo contrario, aparece un error de autorización con el mensaje "No se especificó un token antifalsificación o el que se especificó no era válido".
Título Detalles
Componente API Web
Fase de SDL Build
Tecnologías aplicables MVC5, MVC6
Atributos Proveedor de identidades; ADFS, Proveedor de identidades; Azure AD
Referencias Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2 (Protección de una API web con cuentas individuales e inicio de sesión local en ASP.NET Web API 2.2)
Pasos Si la API web se protege con OAuth 2.0, espera un token de portador en el encabezado de solicitud de autorización y concede acceso a la solicitud solo si el token es válido. A diferencia de la autenticación basada en cookies, los exploradores no adjuntan los tokens de portador a las solicitudes. El cliente solicitante debe adjuntar explícitamente el token de portador al encabezado de solicitud. Por lo tanto, para las API web de ASP.NET protegidas con OAuth 2.0, los tokens de portador se consideran una defensa contra los ataques CSRF. Tenga en cuenta que, si la parte MVC de la aplicación utiliza la autenticación de formularios (es decir, usa cookies), la aplicación web de MVC debe usar tokens antifalsificación.

Ejemplo

Se ha de informar a la API web de que solo debe confiar en tokens de portador y no en cookies. Se puede realizar mediante la siguiente configuración en el método WebApiConfig.Register:

config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));

El método SuppressDefaultHostAuthentication indica a API Web que ignore toda autenticación que se produzca antes de que la solicitud llegue a la canalización de API Web, ya sea mediante IIS o middleware de OWIN. De este modo, se puede restringir API Web para la autenticación solo con tokens de portador.