El middleware OpenIdConnect de ASP.NET Core permite a la aplicación interceptar la llamada al punto de conexión de la Plataforma de identidad de Microsoft al proporcionar un evento de OpenIdConnect denominado OnRedirectToIdentityProviderForSignOut
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
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
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.
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>
Todas las aplicaciones basadas en HTTP deben especificar HTTP solo para la definición de cookies
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:
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.
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.
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.
<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.
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:
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.
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:
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.
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.
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.
<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 - Id. de Microsoft Entra
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:
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.