O middleware OpenIdConnect ASP.NET Core permite que seu aplicativo intercete a chamada para o ponto de extremidade de logout da plataforma de identidade da Microsoft fornecendo um evento OpenIdConnect chamado OnRedirectToIdentityProviderForSignOut
Use tempos de vida finitos para tokens SaS gerados
Título
Detalhes
Componente
Dispositivo IoT
Fase SDL
Criar
Tecnologias aplicáveis
Genérico
Atributos
N/A
Referências
N/A
Passos
Os tokens SaS gerados para autenticação no Hub IoT do Azure devem ter um período de expiração finito. Mantenha o tempo de vida dos tokens SaS a um mínimo para limitar a quantidade de tempo que eles podem ser reproduzidos caso os tokens sejam comprometidos.
Usar tempos de vida mínimos de token para tokens de recursos gerados
Título
Detalhes
Componente
Banco de Dados de Documentos do Azure
Fase SDL
Criar
Tecnologias aplicáveis
Genérico
Atributos
N/A
Referências
N/A
Passos
Reduza o período de tempo do token de recurso para um valor mínimo necessário. Os tokens de recurso têm um período de tempo válido padrão de 1 hora.
Implementar logout adequado usando métodos WsFederation ao usar o ADFS
Título
Detalhes
Componente
ADFS
Fase SDL
Criar
Tecnologias aplicáveis
Genérico
Atributos
N/A
Referências
N/A
Passos
Se o aplicativo depender do token STS emitido pelo ADFS, o manipulador de eventos de logout deverá chamar o método WSFederationAuthenticationModule.FederatedSignOut() para efetuar logout do usuário. Além disso, a sessão atual deve ser destruída e o valor do token de sessão deve ser redefinido e anulado.
Exemplo
[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);
}
Implementar o logout adequado ao usar o Identity Server
O IdentityServer suporta a capacidade de federar com provedores de identidade externos. Quando um usuário sai de um provedor de identidade upstream, dependendo do protocolo usado, pode ser possível receber uma notificação quando o usuário sair. Ele permite que o IdentityServer notifique seus clientes para que eles também possam sair do usuário. Verifique a documentação na seção de referências para obter os detalhes da implementação.
As aplicações disponíveis através de HTTPS devem utilizar cookies seguros
Normalmente, os cookies só são acessíveis ao domínio para o qual foram definidos. Infelizmente, a definição de "domínio" não inclui o protocolo para que os cookies criados através de HTTPS sejam acessíveis através de HTTP. O atributo "seguro" indica ao navegador que o cookie só deve ser disponibilizado por HTTPS. Certifique-se de que todos os cookies definidos por HTTPS usam o atributo seguro . O requisito pode ser imposto no arquivo web.config definindo o atributo requireSSL como true. É a abordagem preferida porque irá impor o atributo seguro para todos os cookies atuais e futuros sem a necessidade de fazer quaisquer alterações adicionais no código.
A configuração é imposta mesmo se HTTP for usado para acessar o aplicativo. Se HTTP for usado para acessar o aplicativo, a configuração quebra o aplicativo porque os cookies são definidos com o atributo seguro e o navegador não os enviará de volta para o aplicativo.
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Criar
Tecnologias aplicáveis
Formulários Web, MVC5
Atributos
Tipo de Ambiente - OnPrem
Referências
N/A
Passos
Quando o aplicativo Web é a Terceira Parte Confiável e o IdP é o servidor ADFS, o atributo secure do token FedAuth pode ser configurado definindo requireSSL como True na system.identityModel.services seção web.config:
Exemplo
<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>
Todos os aplicativos baseados em http devem especificar http apenas para definição de cookie
Para mitigar o risco de divulgação de informações com um ataque de script entre sites (XSS), um novo atributo - httpOnly - foi introduzido aos cookies e é suportado por todos os principais navegadores. O atributo especifica que um cookie não é acessível através de script. Ao usar cookies HttpOnly, uma aplicação web reduz a possibilidade de que informações confidenciais contidas no cookie possam ser roubadas via script e enviadas para o site de um invasor.
Exemplo
Todos os aplicativos baseados em HTTP que usam cookies devem especificar HttpOnly na definição de cookie, implementando a seguinte configuração em web.config:
O valor da propriedade RequireSSL é definido no arquivo de configuração de um aplicativo ASP.NET usando o atributo requireSSL do elemento de configuração. Você pode especificar no arquivo Web.config para seu aplicativo ASP.NET se o Transport Layer Security (TLS), anteriormente conhecido como SSL (Secure Sockets Layer), é necessário para retornar o cookie de autenticação de formulários ao servidor definindo o atributo requireSSL.
Exemplo
O exemplo de código a seguir define o atributo requireSSL no arquivo Web.config.
Atenue os ataques de falsificação de solicitação entre sites (CSRF) em páginas da Web ASP.NET
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Criar
Tecnologias aplicáveis
Genérico
Atributos
N/A
Referências
N/A
Passos
A falsificação de solicitação entre sites (CSRF ou XSRF) é um tipo de ataque no qual um invasor pode realizar ações no contexto de segurança da sessão estabelecida de um usuário diferente em um site. O objetivo é modificar ou excluir conteúdo, se o site de destino depender exclusivamente de cookies de sessão para autenticar a solicitação recebida. Um invasor pode explorar essa vulnerabilidade fazendo com que o navegador de um usuário diferente carregue uma URL com um comando de um site vulnerável no qual o usuário já está conectado. Há muitas maneiras de um invasor fazer isso, como hospedando um site diferente que carrega um recurso do servidor vulnerável ou fazendo com que o usuário clique em um link. O ataque pode ser evitado se o servidor enviar um token adicional para o cliente, exigir que o cliente inclua esse token em todas as solicitações futuras e verificar se todas as solicitações futuras incluem um token que pertence à sessão atual, como usando o ASP.NET AntiForgeryToken ou ViewState.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Exemplo
Ao mesmo tempo, Html.AntiForgeryToken() dá ao visitante um cookie chamado __RequestVerificationToken, com o mesmo valor que o valor oculto aleatório mostrado acima. Em seguida, para validar uma postagem de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação de destino. Por exemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorização que verifica se:
A solicitação recebida tem um cookie chamado __RequestVerificationToken
A solicitação de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
Estes cookies e Request.Form valores correspondem Supondo que esteja tudo bem, o pedido decorre normalmente. Mas se não, então uma falha de autorização com a mensagem "Um token anti-falsificação necessário não foi fornecido ou foi inválido".
Exemplo
Anti-CSRF e AJAX: O token de formulário pode ser um problema para solicitações AJAX, porque uma solicitação AJAX pode enviar dados JSON, não dados de formulário HTML. Uma solução é enviar os tokens em um cabeçalho HTTP personalizado. O código a seguir usa a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a uma solicitação 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>
Exemplo
Ao processar a solicitação, extraia os tokens do cabeçalho da solicitação. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Validate lança uma exceção se os tokens não forem válidos.
Os ataques CSRF em aplicativos baseados em WebForm podem ser atenuados definindo ViewStateUserKey como uma cadeia de caracteres aleatória que varia para cada usuário - ID de usuário ou, melhor ainda, ID de sessão. Por uma série de razões técnicas e sociais, o ID de sessão é muito mais adequado porque um ID de sessão é imprevisível, atinge o tempo limite e varia de acordo com o usuário.
Exemplo
Aqui está o código que você precisa ter em todas as suas páginas:
O tempo limite da sessão representa o evento que ocorre quando um usuário não executa nenhuma ação em um site durante um intervalo (definido pelo servidor Web). O evento, no lado do servidor, alterar o status da sessão do usuário para 'inválido' (por exemplo, "não usado mais") e instruir o servidor web para destruí-lo (excluindo todos os dados contidos nele). O exemplo de código a seguir define o atributo de sessão de tempo limite para 15 minutos no arquivo Web.config.
Quando o aplicativo Web é Terceira Parte Confiável e o ADFS é o STS, o tempo de vida dos cookies de autenticação - tokens FedAuth - pode ser definido pela seguinte configuração em web.config:
Exemplo
<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>
Exemplo
Além disso, o tempo de vida do token de declaração SAML emitido pelo ADFS deve ser definido como 15 minutos, executando o seguinte comando powershell no servidor ADFS:
Execute o logout adequado do aplicativo, quando o usuário pressiona o botão de logout. Após o logout, o aplicativo deve destruir a sessão do usuário e também redefinir e anular o valor do cookie de sessão, juntamente com redefinir e anular o valor do cookie de autenticação. Além disso, quando várias sessões são vinculadas a uma única identidade de usuário, elas devem ser encerradas coletivamente no lado do servidor no tempo limite ou logout. Por fim, certifique-se de que a funcionalidade Logout esteja disponível em todas as páginas.
Atenue os ataques CSRF (Cross-Site Request Forgery) em APIs Web ASP.NET
Título
Detalhes
Componente
API da Web
Fase SDL
Criar
Tecnologias aplicáveis
Genérico
Atributos
N/A
Referências
N/A
Passos
A falsificação de solicitação entre sites (CSRF ou XSRF) é um tipo de ataque no qual um invasor pode realizar ações no contexto de segurança da sessão estabelecida de um usuário diferente em um site. O objetivo é modificar ou excluir conteúdo, se o site de destino depender exclusivamente de cookies de sessão para autenticar a solicitação recebida. Um invasor pode explorar essa vulnerabilidade fazendo com que o navegador de um usuário diferente carregue uma URL com um comando de um site vulnerável no qual o usuário já está conectado. Há muitas maneiras de um invasor fazer isso, como hospedando um site diferente que carrega um recurso do servidor vulnerável ou fazendo com que o usuário clique em um link. O ataque pode ser evitado se o servidor enviar um token adicional para o cliente, exigir que o cliente inclua esse token em todas as solicitações futuras e verificar se todas as solicitações futuras incluem um token que pertence à sessão atual, como usando o ASP.NET AntiForgeryToken ou ViewState.
Anti-CSRF e AJAX: O token de formulário pode ser um problema para solicitações AJAX, porque uma solicitação AJAX pode enviar dados JSON, não dados de formulário HTML. Uma solução é enviar os tokens em um cabeçalho HTTP personalizado. O código a seguir usa a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a uma solicitação AJAX.
Exemplo
<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>
Exemplo
Ao processar a solicitação, extraia os tokens do cabeçalho da solicitação. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Validate lança uma exceção se os tokens não forem válidos.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Exemplo
Ao mesmo tempo, Html.AntiForgeryToken() dá ao visitante um cookie chamado __RequestVerificationToken, com o mesmo valor que o valor oculto aleatório mostrado acima. Em seguida, para validar uma postagem de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação de destino. Por exemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorização que verifica se:
A solicitação recebida tem um cookie chamado __RequestVerificationToken
A solicitação de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
Estes cookies e Request.Form valores correspondem Supondo que esteja tudo bem, o pedido decorre normalmente. Mas se não, então uma falha de autorização com a mensagem "Um token anti-falsificação necessário não foi fornecido ou foi inválido".
Título
Detalhes
Componente
API da Web
Fase SDL
Criar
Tecnologias aplicáveis
MVC5, MVC6
Atributos
Provedor de Identidade - ADFS, Provedor de Identidade - Microsoft Entra ID
Se a API da Web estiver protegida usando o OAuth 2.0, ela espera um token de portador no cabeçalho da solicitação de autorização e concede acesso à solicitação somente se o token for válido. Ao contrário da autenticação baseada em cookies, os navegadores não anexam os tokens de portador às solicitações. O cliente solicitante precisa anexar explicitamente o token de portador no cabeçalho da solicitação. Portanto, para ASP.NET APIs da Web protegidas usando OAuth 2.0, os tokens de portador são considerados como uma defesa contra ataques CSRF. Observe que, se a parte MVC do aplicativo usa autenticação de formulários (ou seja, usa cookies), tokens antifalsificação devem ser usados pelo aplicativo Web MVC.
Exemplo
A API Web tem de ser informada para confiar APENAS em tokens ao portador e não em cookies. Isso pode ser feito pela seguinte configuração no WebApiConfig.Register método:
O método SuppressDefaultHostAuthentication informa à API da Web para ignorar qualquer autenticação que aconteça antes que a solicitação chegue ao pipeline da API da Web, seja pelo IIS ou pelo middleware OWIN. Dessa forma, podemos restringir a API da Web para autenticar apenas usando tokens de portador.