Também deve destruir a sessão do utilizador chamando o método Session.Abandon(). O método seguinte mostra uma implementação segura do logout do utilizador:
[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 vidas finitas para tokens SaS gerados
Título
Detalhes
Componente
Dispositivo IoT
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Os tokens SaS gerados para autenticação no Azure IoT Hub devem ter um período de validade finito. Mantenha as vidas simbólicas sas ao mínimo para limitar o tempo que podem ser reproduzidos no caso de as fichas estarem comprometidas.
Utilize as vidas mínimas simbólicas para tokens de recursos gerados
Título
Detalhes
Componente
Documento Azure DB
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Reduza o tempo de token de recurso para um valor mínimo necessário. As fichas de recursos têm um tempo de tempo válido de 1 hora.
Implementar o logout adequado utilizando métodos de S.A.
Título
Detalhes
Componente
ADFS
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Se a aplicação se basear no token STS emitido pela ADFS, o manipulador de eventos logout deve ligar para o método WSFederationAuthenticationModule.FederatedSignOut() para registar o utilizador. Também a sessão atual deve ser destruída, e o valor simbólico da sessão deve ser reposto 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);
}
Implemente o logout adequado ao utilizar o Servidor de Identidade
O IdentityServer apoia a capacidade de federação com fornecedores de identidade externos. Quando um utilizador assina fora de um fornecedor de identidade a montante, dependendo do protocolo utilizado, pode ser possível receber uma notificação quando o utilizador assinar. Permite que o IdentityServer notifique os seus clientes para que também possam assinar o utilizador. Consulte a documentação na secção de referências para obter os detalhes da implementação.
As aplicações disponíveis em HTTPS devem utilizar cookies seguros
Normalmente, os cookies só são acessíveis ao domínio para o qual foram examinados. Infelizmente, a definição de "domínio" não inclui o protocolo para que os cookies que são criados em HTTPS estejam acessíveis em HTTP. O atributo "seguro" indica ao navegador que o cookie só deve ser disponibilizado através do HTTPS. Certifique-se de que todos os cookies definidos em HTTPS utilizem o atributo secure . A exigência pode ser aplicada no ficheiro web.config, definindo o atributo requereSSL à verdadeira. É 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 de código.
A definição é aplicada mesmo que HTTP seja utilizado para aceder à aplicação. Se HTTP for utilizado para aceder à aplicação, a configuração quebra a aplicação porque os cookies são definidos com o atributo seguro e o navegador não os enviará de volta para a aplicação.
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias aplicáveis
Web Forms, MVC5
Atributos
EnvironmentType - OnPrem
Referências
N/D
Passos
Quando a aplicação web é a Parte De Gestão, e o IdP é servidor ADFS, o atributo seguro do token da FedAuth pode ser configurado por definição requerSSL a True na system.identityModel.services secção de 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>
Toda a aplicação baseada em http deve especificar http apenas para definição de cookies
Para mitigar o risco de divulgação de informação com um ataque de scripts cross-site (XSS), um novo atributo - httpOnly - foi introduzido nos cookies e é suportado por todos os principais navegadores. O atributo especifica que um cookie não é acessível através do script. Ao utilizar cookies HttpOnly, uma aplicação web reduz a possibilidade de que informações sensíveis contidas no cookie possam ser roubadas através do script e enviadas para o site de um intruso.
Exemplo
Todas as aplicações baseadas em HTTP que utilizam cookies devem especificar httpOnly na definição de cookies, implementando a seguinte configuração em web.config:
O valor da propriedade RequireSSL é definido no ficheiro de configuração para uma aplicação ASP.NET utilizando o atributo requerESSL do elemento de configuração. Pode especificar no ficheiro Web.config para a sua aplicação ASP.NET se a Segurança da Camada de Transporte (TLS), anteriormente conhecida como SSL (Camada de Tomadas Seguras), é necessária para devolver o cookie de autenticação de formulários ao servidor, definindo o atributo requerendoSSL.
Exemplo
O exemplo de código a seguir define o atributo requereSSL no ficheiro Web.config.
Mitigar contra ataques de falsificação de pedidos de cross-site (CSRF) em páginas web ASP.NET
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Falsificação de pedidos de sites (CSRF ou XSRF) é um tipo de ataque no qual um intruso pode realizar ações no contexto de segurança de uma sessão estabelecida de um utilizador diferente num site. O objetivo é modificar ou apagar conteúdo, se o site direcionado se basear exclusivamente em cookies de sessão para autenticar o pedido recebido. Um intruso poderia explorar esta vulnerabilidade obtendo um navegador de um utilizador diferente para carregar um URL com um comando a partir de um site vulnerável no qual o utilizador já está iniciado. Existem muitas formas de um intruso fazer isso, como por exemplo hospedar um site diferente que carrega um recurso a partir do servidor vulnerável, ou fazer com que o utilizador clique num link. O ataque pode ser evitado se o servidor enviar um sinal adicional ao cliente, requer que o cliente inclua esse token em todos os pedidos futuros, e verifica que todos os pedidos futuros incluem um token que diz respeito à sessão atual, como por exemplo, utilizando o ASP.NET AntiForgeryToken ou ViewState.
Formulários anti-CSRF e ASP.NET MVC - Utilize o método de AntiForgeryToken ajuda em Vistas; coloque um Html.AntiForgeryToken() no formulário, por exemplo,
<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 escondido aleatório acima indicado. Em seguida, para validar um post de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação alvo. Por exemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorização que verifica:
O pedido de entrada tem um cookie chamado __RequestVerificationToken
O pedido de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
Estes cookies e Request.Form valores correspondem Assumindo que está tudo bem, o pedido passa normalmente. Mas se não, então uma falha de autorização com mensagem "Um sinal anti-falsificação exigido não foi fornecido ou foi inválido".
Exemplo
Anti-CSRF e AJAX: O token do formulário pode ser um problema para os pedidos do AJAX, porque um pedido do AJAX pode enviar dados de JSON, não dados de formulário HTML. Uma solução é enviar os tokens num cabeçalho HTTP personalizado. O código seguinte utiliza a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a um pedido do 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
Quando processar o pedido, extraia as fichas do cabeçalho do pedido. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Valide abre uma exceção se as fichas não forem válidas.
Os ataques CSRF em aplicações baseadas no WebForm podem ser atenuados definindo o ViewStateUserKey para uma cadeia aleatória que varia para cada utilizador - ID do utilizador ou, melhor ainda, ID de sessão. Por uma série de razões técnicas e sociais, o ID da sessão é muito melhor porque um ID de sessão é imprevisível, horários e varia por utilizador.
Exemplo
Aqui está o código que precisa de ter em todas as suas páginas:
O tempo limite de sessão representa o evento que ocorre quando um utilizador não realiza qualquer ação num web site durante um intervalo (definido pelo servidor web). O evento, no lado do servidor, altera o estado da sessão de utilizador para 'inválido' (por exemplo, "já não é utilizado") e instrui o servidor web a destruí-lo (eliminando todos os dados nele contidos). O seguinte exemplo de código define o atributo de sessão de tempo limite para 15 minutos no ficheiro Web.config.
Quando a aplicação web é AParting e ADFS é o STS, a vida útil dos cookies de autenticação - fichas FedAuth - pode ser definida 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
Também o ADFS emitiu a vida útil do token da SAML em 15 minutos, executando o seguinte comando de powershell no servidor ADFS:
Implementar o logout adequado a partir da aplicação
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Execute a assinatura adequada da aplicação, quando o utilizador premir o botão 'iniciar sessão'. Após o logout, a aplicação deve destruir a sessão do utilizador e também redefinir e anular o valor dos cookies da sessão, juntamente com a reposição e anulação do valor dos cookies de autenticação. Além disso, quando várias sessões estão ligadas a uma única identidade de utilizador, devem ser encerradas coletivamente no lado do servidor no tempo limite ou logout. Por último, certifique-se de que a funcionalidade Logout está disponível em todas as páginas.
Mitigar contra ataques de falsificação de pedidos de cross-site (CSRF) em APIs web ASP.NET
Título
Detalhes
Componente
API Web
Fase SDL
Compilação
Tecnologias aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Falsificação de pedidos de sites (CSRF ou XSRF) é um tipo de ataque no qual um intruso pode realizar ações no contexto de segurança de uma sessão estabelecida de um utilizador diferente num site. O objetivo é modificar ou apagar conteúdo, se o site direcionado se basear exclusivamente em cookies de sessão para autenticar o pedido recebido. Um intruso poderia explorar esta vulnerabilidade obtendo um navegador de um utilizador diferente para carregar um URL com um comando a partir de um site vulnerável no qual o utilizador já está iniciado. Existem muitas formas de um intruso fazer isso, como por exemplo hospedar um site diferente que carrega um recurso a partir do servidor vulnerável, ou fazer com que o utilizador clique num link. O ataque pode ser evitado se o servidor enviar um sinal adicional ao cliente, requer que o cliente inclua esse token em todos os pedidos futuros, e verifica que todos os pedidos futuros incluem um token que diz respeito à sessão atual, como por exemplo, utilizando o ASP.NET AntiForgeryToken ou ViewState.
Anti-CSRF e AJAX: O token do formulário pode ser um problema para os pedidos do AJAX, porque um pedido do AJAX pode enviar dados de JSON, não dados de formulário HTML. Uma solução é enviar os tokens num cabeçalho HTTP personalizado. O código seguinte utiliza a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a um pedido do 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
Quando processar o pedido, extraia as fichas do cabeçalho do pedido. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Valide abre uma exceção se as fichas não forem válidas.
<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 escondido aleatório acima indicado. Em seguida, para validar um post de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação alvo. Por exemplo:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtro de autorização que verifica:
O pedido de entrada tem um cookie chamado __RequestVerificationToken
O pedido de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
Estes cookies e Request.Form valores correspondem Assumindo que está tudo bem, o pedido passa normalmente. Mas se não, então uma falha de autorização com mensagem "Um sinal anti-falsificação exigido não foi fornecido ou foi inválido".
Título
Detalhes
Componente
API Web
Fase SDL
Compilação
Tecnologias aplicáveis
MVC5, MVC6
Atributos
Fornecedor de identidade - ADFS, Fornecedor de Identidade - Azure Ad
Se a API Web for protegida usando o OAuth 2.0, então espera um sinal ao portador no cabeçalho de pedido de autorização e concede acesso ao pedido apenas se o token for válido. Ao contrário da autenticação baseada em cookies, os navegadores não anexam as fichas do portador aos pedidos. O cliente que solicita precisa de anexar explicitamente o sinal do portador no cabeçalho do pedido. Portanto, para ASP.NET APIs Web protegidos usando OAuth 2.0, os tokens portadores são considerados como uma defesa contra os ataques de CSRF. Por favor, note que se a parte MVC da aplicação utiliza a autenticação de formulários (isto é, utiliza cookies), as fichas anti-falsificação têm de ser utilizadas pela aplicação web MVC.
Exemplo
A API Web tem de ser informada para se basear apenas em fichas ao portador e não em cookies. Pode ser feito pela seguinte configuração em WebApiConfig.Register método:
O método SupressefaultHostAuthentication diz à Web API para ignorar qualquer autenticação que oace antes do pedido chegar ao pipeline Web API, seja por IIS ou por middleware OWIN. Dessa forma, podemos restringir a API web a autenticar apenas usando fichas portadoras.