A3 Falha de Autenticação e Gerenciamento de Sessão
(Redirecionado de A3 Broken Authentication and Session Management)
Conteúdo |
A3.1 Descrição
O gerenciamento de autenticação e de sessão inclui todos os aspectos referentes ao manuseio da autenticação do usuário e o controle das sessões ativas. A autenticação é um aspecto crítico deste processo, mas mesmo os mecanismos mais robustos de autenticação podem ser comprometidos por falhas nas funções relacionadas ao gerenciamento das credenciais dos usuários, incluindo funções para troca de senhas, esquecimento de senha, atualização de conta e outras relacionadas. Uma vez que muitas aplicações Web podem sofrer ataques do tipo “walk by” (onde alguém deixa o computador com sua sessão autenticada aberta e outra pessoa utiliza esta estação para o acesso indevido), todas as funções de gerenciamento de conta devem exigir a reautenticação do usuário, mesmo se ele possui uma identificação válida daquela sessão.
A autenticação do usuário na Web tipicamente envolve o uso de um nome de usuário (“userid”) e de uma senha. Alguns métodos de autenticação forte são disponíveis comercialmente, tais como o uso de ”tokens” criptográficos (baseados em software e hardware) ou biometria, porém tais mecanismos possuem custo proibitivo para a maioria das aplicações Web. Uma seqüência de falhas no gerenciamento das contas de acesso e da sessão pode resultar no comprometimento da conta do usuário ou mesmo do administrador do sistema. As equipes do desenvolvimento freqüentemente subestimam a complexidade envolvida na elaboração de um mecanismo para gerenciamento de autenticação e de sessão que consiga protejer adequadamente as credenciais dos usuários em todo o site.
As aplicações Web devem estabelecer sessões para controlar a seqüência de requisições de cada usuário. Como o protocolo HTTP não possui este recurso, as aplicações Web devem tomar esta função para si. Freqüentemente, o ambiente da aplicação Web fornece recursos para estabelecer a sessão, mas muitos desenvolvedores preferem criar seu próprio controle (“token”) da sessão. Em um ou outro caso, se o token da sessão não for protegido corretamente, um atacante pode seqüestrar uma sessão ativa e assumir a identidade de um usuário. Ter um mecanismo para criar tokens de sessão de forma robusta e protegê-los durante todo seu ciclo de vida provou ser algo complicado para muitos desenvolvedores.
A menos que todas as credenciais de autenticação e os identificadores de sessão estejam sempre protegidos com o uso de SSL e protegidos contra a descoberta de outras falhas, tais como “cross site script”, um atacante pode seqüestrar a sessão de um usuário e assumir sua identidade.
A3.2 Ambientes Afetados
Todos os servidores Web, servidores de aplicação e os ambientes de aplicação Web são suscetíveis à falhas relacionadas ao gerenciamento de autenticação e de sessão.
A3.3 Exemplos e Referências
- “OWASP Guide to Building Secure Web Applications and Web Services”, Capítulo 6: “Authentication” e Capítulo 7: “Session Management”: http://www.owasp.org/documentation/guide.html
- White paper sobre “Session Fixation Vulnerability in Web-based Applications”: http://www.acros.si/papers/session_fixation.pdf
- White paper sobre “Password Recovery for Web-based Applications” - http://fishbowl.pastiche.org/archives/docs/PasswordRecovery.pdf
A3.4 Como Descobrir se Você Está Vulnerável
A revisão do código e testes de invasão (“penetration tests”) podem ser usados para diagnosticar problemas no gerenciamento de autenticação e de sessão. Revise com cuidado cada aspecto de seus métodos de autenticação para assegurar-se que as credenciais do usuário estejam protegidas o tempo todo, quando estão armazenadas (por exemplo, no disco) e quando estiverem em trânsito (por exemplo, durante o início de uma sessão). Revise cada meio disponível para troca de credenciais de um usuário para garantir que somente possam ser trocadas por um usuário autorizado. Revise os métodos de gerenciamento da sessão para garantir que os identificadores da sessão sempre estejam protegidos e sejam usados de forma que minimizem a possibilidade de exposição acidental ou intencional.
A3.5 Como se Proteger
O uso cuidadoso e apropriado de métodos conhecidos para gerenciamento de autenticação e de sessão (“de prateleira”) pode reduzir significativamente a chance de surgir um problema nesta área. Uma primeira etapa recomendável consiste em definir e documentar a política do seu site no que se refere ao gerenciamento das credenciais dos usuários de forma segura. Assegurar de que sua implementação reforce esta política consistentemente é um fator chave para ter um mecanismo seguro e robusto para gerenciamento de autenticação e de sessão. Alguns pontos críticos são apresentados a seguir:
- Robustez da senha - as senhas devem ter controles que garantam um tamanho mínimo e um nível de complexidade. A complexidade normalmente consiste em exigir o uso de um conjunto mínimo de combinações entre caracteres alfabéticos, numéricos, e/ou não-alfanuméricos (como símbolos e sinais de pontuação) na senha de um usuário (por exemplo, pelo menos um caractere de cada conjunto). Os usuários devem ser obrigados a trocar periodicamente sua senha. Os usuários devem ser impedidos de reutilizar senhas anteriores.
- Uso da senha - os usuários devem ser limitados a um número máximo de tentativas frustradas de acesso por um período de tempo e a ocorrência de várias tentativas erradas deve ser registrada. As senhas fornecidas durante tentativas frustradas de acesso não devem ser registradas, pois pode expor a senha de um usuário a quem obter acesso a este registro. O sistema não deve indicar se houve erro no nome do usuário ou na senha fornecida. Os usuários devem ser informados da data e hora de sua última sessão ativa e o número de tentativas de acesso com falha que ocorreram neste período.
- Controles de Mudança da Senha: Um mecanismo único para mudança da senha deve ser usado sempre que os usuários tiverem permissão de mudar sua senha, independente da situação. Os usuários devem sempre ser forçados a fornecer a senha antiga e a nova ao trocar sua senha. Se as senhas esquecidas forem enviadas aos usuários por e-mail, o sistema deve solicitar que o usuário se reautentique sempre que alterar seu endereço de e-mail, caso contrário um atacante que obtenha acesso temporário a sua sessão (por exemplo, indo até seu computador quando estiver com a sessão aberta) pode simplesmente mudar o endereço de e-mail e pedir posteriormente que seja enviada a senha “esquecida”.
- Armazenamento da senha - toda senha deve ser armazenada de forma criptografada ou ter gravado somente o seu hash para protegê-la contra exposição, independente de onde esteja armazenada. O método de Hash é preferível, desde que ele não seja reversível. A criptografia deve ser usada quando for necessário utilizar a senha original, como por exemplo, quando for usar a senha para iniciar uma sessão em outro sistema. As senhas nunca devem ser gravadas (“hardcoded”) no código fonte. As chaves de criptografia devem ser fortemente protegidas para assegurar de que não possam ser capturadas e utilizadas para decifrar o arquivo de senhas.
- Protegendo as credenciais em trânsito - a única técnica eficaz consiste em criptografar toda a transação referente ao início de uma sessão usando algo como SSL. Transformações simples da senha, como criar seu hash no cliente e transmiti-lo, fornece pouca proteção uma vez que a versão cifrada pode simplesmente ser interceptada e retransmitida posteriormente - mesmo que a senha original não seja conhecida.
- Proteção da identificação da sessão - idealmente, toda a sessão de um usuário deve ser protegida por SSL. Se isto for feito, então o identificador da sessão (por exemplo, um cookie de sessão) não poderá ser capturado na rede, que é o maior risco de exposição para um ID de sessão. Se o uso de SSL não for viável por questões de desempenho ou outros motivos, então os identificadores de sessão devem ser protegidos de outras formas. Inicialmente, eles nunca devem ser incluídos na URL, uma vez que podem ser mantidos pelo browser em cache, serem re-enviados no cabeçalho, ou serem retransmitidos acidentalmente para outra pessoa. O identificador de sessão deve ser longo, complicado, formado por números aleatórios e não podem ser facilmente descobertos. O identificador de sessão também pode ser trocado freqüentemente durante uma mesma sessão para reduzir o seu tempo de validade. O identificador de sessão deve ser alterado ao passar para uma conexão SSL, ao usuário se autenticar ou qualquer outra transação considerada importante. Nunca devem ser aceitos identificadores de sessão escolhidos pelo usuário.
- Listas de contas de acesso - os sistemas devem ser projetados de forma a evitar que os usuários tenham acesso à relação de contas existentes no site. Se as listas de usuários necessitem ser visíveis, recomenda-se que seja apresentado algum tipo de pseudônimo (“screen name”) que seja mapeado internamente ao nome real da conta. Dessa maneira, o pseudônimo não poderá ser utilizado durante uma tentativa de acesso ou algum outro ataque que se baseie na conta do usuário.
- Cache do browser - os dados de autenticação e da sessão nunca devem ser submetidos como parte de um GET - sempre ser preferido o uso de POST. As páginas de autenticação devem ser marcadas com todos os tipos de Tags para não efetuar cache, para impedir que alguém use a tecla de voltar no browser do usuário para retornar até a página de autenticação e submeter novamente as credenciais fornecidas anteriormente. Muitos browsers suportam agora a flag “autocomplete=false” para impedir que as credenciais do usuário sejam armazenadas no cache do recurso “autocompletar”.
- Relacionamentos de confiança – A arquitetura de seu site deve evitar, sempre que possível, o uso de confiança implícita entre componentes. Cada componente deve se autenticar para todo outro componente que interagir, a menos que haja uma forte razão para não fazê-lo (como problemas no desempenho ou a falta de um método viável para tal). Se os relacionamentos da confiança forem necessários, devem ser definidos procedimentos e arquiteturas rígidas para garantir que tal confiança não possa ser utilizada de forma abusiva, uma vez que a arquitetura do site evolui constantemente.