Produto/Serviço |
Artigo |
Microsoft Entra ID |
|
Dispositivo IoT |
|
Banco de Dados de Documentos do Azure |
|
ADFS |
|
Servidor de identidade |
|
Aplicação Web |
|
Web API |
|
Implementar a saída adequada usando métodos MSAL ao usar o ID do Microsoft Entra
Título |
Detalhes |
Componente |
Microsoft Entra ID (um serviço de identificação da Microsoft) |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
N/A |
Referências |
Habilite seu aplicativo Web para entrar usuários usando a plataforma de identidade da Microsoft |
Passos |
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 |
Exemplo
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.Events.OnRedirectToIdentityProviderForSignOut = async context =>
{
//Your logic here
};
});
Use tempos de vida finitos para tokens SaS gerados
Título |
Detalhes |
Componente |
Dispositivo IoT |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
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 os tempos 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 |
Compilar |
Tecnologias aplicáveis |
Genérica |
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 |
Compilar |
Tecnologias aplicáveis |
Genérica |
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
Título |
Detalhes |
Componente |
Servidor de identidade |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
N/A |
Referências |
N/A |
Passos |
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
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
Tipo de Ambiente - OnPrem |
Referências |
Elemento httpCookies (esquema de configurações ASP.NET),propriedade HttpCookie.Secure |
Passos |
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 que são 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. |
Exemplo
<configuration>
<system.web>
<httpCookies requireSSL="true"/>
</system.web>
</configuration>
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 secure e o navegador não os enviará de volta para o aplicativo.
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
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
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
N/A |
Referências |
Atributo de cookie seguro |
Passos |
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:
<system.web>
.
.
<httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Formulários Web |
Atributos |
N/A |
Referências |
Propriedade FormsAuthentication.RequireSSL |
Passos |
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.
<authentication mode="Forms">
<forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
MVC5 |
Atributos |
Tipo de Ambiente - OnPrem |
Referências |
Configuração do Windows Identity Foundation (WIF) – Parte II |
Passos |
Para definir o atributo httpOnly para cookies FedAuth, o valor do atributo hideFromScript deve ser definido como True. |
Exemplo
A configuração a seguir mostra a configuração correta:
<federatedAuthentication>
<cookieHandler mode="Custom"
hideFromScript="true"
name="FedAuth"
path="/"
requireSsl="true"
persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>
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 |
Compilar |
Tecnologias aplicáveis |
Genérica |
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. |
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
MVC5, MVC6 |
Atributos |
N/A |
Referências |
Prevenção de XSRF/CSRF em ASP.NET MVC e páginas da Web |
Passos |
Anti-CSRF e ASP.NET formulários MVC - Use o AntiForgeryToken método auxiliar em Views; coloque um Html.AntiForgeryToken() no formulário, por exemplo, |
Exemplo
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
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 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.
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 |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Formulários Web |
Atributos |
N/A |
Referências |
Aproveite ASP.NET recursos integrados para se defender de ataques da Web |
Passos |
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:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
:
}
Configurar sessão para o tempo de vida da inatividade
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
N/A |
Referências |
Propriedade HttpSessionState.Timeout |
Passos |
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. |
Exemplo
<configuration>
<system.web>
<sessionState mode="InProc" cookieless="true" timeout="15" />
</system.web>
</configuration>
Habilitar a deteção de ameaças no SQL do Azure
Exemplo
<forms name=".ASPXAUTH" loginUrl="login.aspx" defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Formulários Web, MVC5 |
Atributos |
Tipo de Ambiente - OnPrem |
Referências |
Asdeqa |
Passos |
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:
Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true
Implementar o logout adequado do aplicativo
Título |
Detalhes |
Componente |
Aplicação Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
Atributos |
N/A |
Referências |
N/A |
Passos |
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 de falsificação de solicitação entre sites (CSRF) em APIs da Web ASP.NET
Título |
Detalhes |
Componente |
API da Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
Genérica |
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. |
Título |
Detalhes |
Componente |
API da Web |
Fase SDL |
Compilar |
Tecnologias aplicáveis |
MVC5, MVC6 |
Atributos |
N/A |
Referências |
Prevenção de ataques de falsificação de solicitação entre sites (CSRF) em ASP.NET API Web |
Passos |
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.
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);
}
Exemplo
Formulários Anti-CSRF e ASP.NET MVC - Use o método auxiliar AntiForgeryToken em Views; coloque um Html.AntiForgeryToken() no formulário, por exemplo,
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
}
Exemplo
O exemplo acima produzirá algo como o seguinte:
<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 |
Compilar |
Tecnologias aplicáveis |
MVC5, MVC6 |
Atributos |
Provedor de Identidade - ADFS, Provedor de Identidade - Microsoft Entra ID |
Referências |
Proteja uma API Web com Contas Individuais e Login Local em ASP.NET Web API 2.2 |
Passos |
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:
config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
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.