ASP.NET Security: Autenticação e segurança no ASP.NET – Parte 2

Autenticação em um website é algo muito comum hoje em dia. Observando nossos navegadores e os sites que acessamos, cada um deles tem a sua forma individual de autenticação.

Então, confiamos sempre que esses sites estão protegendo corretamente a sessão atual e qualquer dado que é persistido ou transferido, tais como credenciais e afins. Mas além de observar se o protocolo SSL está presente e com seu certificado em dia, temos uma ideia muito pequena de como o site implementa sua autenticação e como gerencia as suas sessões.

Pelo menos, esta compreensão foge do usuário médio, o qual nunca se preocupará muito com esta questão.

Em alguns sites conhecidos do público, tais como fóruns, um serviço de autenticação utiliza o OpenID. Tal implementação é uma ótima solução para o usuário, que pode reutilizar uma conta existente com um serviço aberto, sem se preocupar em criar uma nova conta e mais uma senha para guardar ou esquecer, o que é muito comum.

Isso também é uma grande vantagem para o desenvolvedor com relação ao processo de desenvolvimento, já que ele pode centralizar a parte de autenticação em um serviço externo.

Mesmo assim, o desenvolvedor ainda precisa se preocupar com a autorização dentro das aplicações e ainda precisa persistir a sessão autenticada em um ambiente sem estado, para que então seu trabalho de permissão de acesso seja funcional e eficiente.

Explicaremos a quebra de autenticação e gerenciamento de sessão com uma definição da OWASP: “A aplicação e suas funções para autenticação e gerenciamento de sessão não são implementados corretamente de uma maneira geral, permitindo aos atacantes comprometerem senhas, chaves, tokens de sessão ou explorar outras falhas de implementação com o intuito de assumir a identidade do usuário”.

E a Matriz de Ameaça para este tipo de ataque vemos na Figura 1.

abrir imagem em nova janela

Figura 1. Matriz de ameaça do tipo de ataque chamado Quebra de Autenticação e Gerenciamento de Sessão

Consideremos um atacante externo e anônimo, bem como usuários com suas próprias contas, que podem roubar contas dos outros. Também leve em consideração usuários internos que querem esconder suas ações e procuram uma forma de burlar o sistema.

Atacantes usam vazamentos de memória, falta de controle e tratamento ou falhas nos métodos de autenticação e gerenciamento de sessão (ou seja, contas expostas, senhas e IDs de sessão) para se passarem pelos usuários.

Desenvolvedores frequentemente criam esquemas de autenticação e gerenciamento de sessão de acordo com a aplicação, mas construí-los corretamente é muito demorado e complexo. Como resultado, estes esquemas personalizados frequentemente falham em áreas tais como logout, gerenciamento de senhas, expirações, “perdi a minha senha”, pergunta secreta, atualização de contas e etc. Encontrar estas falhas pode, às vezes, ser difícil, já que cada implementação é única.

Tais falhas podem permitir que algumas, ou mesmo todas as contas, sejam atacadas. Quando o atacante tem sucesso uma única vez, ele pode fazer tudo o que a vítima pode fazer. Contas com muitos privilégios são os principais alvos.

Pense sempre que os objetos de negócios, ou suas funções específicas da aplicação serão afetados. Caso um atacante tenha êxito, isso irá ajudar a equipe de projetos a pensar de uma forma mais concisa relacionada à segurança. Também pense no prejuízo para a organização em caso de uma exposição da vulnerabilidade de sua aplicação."