3. Contextualizando...
Autenticação é o processo de verificação de que
uma pessoa, entidade ou site é quem afirma ser
Em aplicações web é comumente realizado
através do envio de um nome de usuário ou id e
um ou mais itens de informações privadas que
apenas um determinado usuário deveria saber
4. Contextualizando...
O gerenciamento de sessão é um processo pelo
qual um servidor mantém o estado de uma
entidade interagindo com ele
As sessões são mantidas no servidor por um
identificador de sessão, que pode ser passado e
encaminhado entre o cliente e o servidor, para
lembrar como reagir a solicitações subsequentes
durante uma transação
5. Contextualizando...
Multifactor Authentication (MFA)
• Autenticação usando dois ou mais fatores para
obter autenticação
• Os fatores incluem:
– (i) algo que você conhece (por exemplo, senha /
número de identificação pessoal (PIN));
– (ii) algo que você tem (por exemplo, dispositivo de
identificação criptográfica, token);
– ou (iii) algo que você é (por exemplo, biométrico)
Fonte: NIST – disponível em https://csrc.nist.gov/Glossary/?term=6463
6. A2: Broken Authentication
A essência do Broken Authentication está na
permissão de um usuário ou invasor efetuar
login em sua aplicação web sem o uso de
credenciais adequadas
7. A2: Broken Authentication
As funções do aplicativo relacionadas ao
gerenciamento de autenticação e de sessão
geralmente são implementadas incorretamente
Isso permite que invasores comprometam senhas,
chaves ou tokens de sessão ou explorem outras
falhas de implementação para assumir as
identidades de outros usuários de forma
temporária ou permanente
8. A2: Broken Authentication
A confirmação da identidade, autenticação e
gerenciamento de sessão do usuário é
fundamental para proteger contra ataques
relacionados à autenticação
9. A2: Broken Authentication
Pode haver falhas de autenticação se a aplicação
web:
• Permite ataques automatizados, como o
Credential Stuffing, em que o invasor tem uma
lista de nomes de usuários e senhas válidos
• Permite força bruta ou outros ataques
automatizados
• Permite senhas padrão, fracas ou conhecidas,
como "Password1" ou "admin / admin"
10. A2: Broken Authentication
Pode haver falhas de autenticação se a
aplicação web:
• Usa senhas em texto puro, criptografadas
usando algoritmos ou hashs fracos
• Expõe IDs de sessão na URL
11. A2: Broken Authentication
Cenário A:
• O Credential Stuffing e o uso de listas de
senhas conhecidas é um ataque comum
• Se uma aplicação não implementar proteções
automatizadas de ameaça ou de Credential
Stuffing, ela poderá ser usada para determinar
se as credenciais são válidas
12. A2: Broken Authentication
Cenário B:
• Os tempos limite da sessão da aplicação não
estão definidos corretamente
• Um usuário usa um computador público para
acessar uma aplicação. Em vez de selecionar
"logout", o usuário simplesmente fecha a guia do
navegador e se afasta. Um invasor usa o mesmo
navegador uma hora depois e o usuário ainda
está autenticado
13. A2: Broken Authentication
Como prevenir?
• Sempre que possível, implemente mutifactor
authentication para evitar ataques
automatizados, Credential Stuffing, força
bruta e reutilização de credenciais roubadas
• Não envie ou implante uma aplicação com
nenhuma credencial padrão, principalmente
para usuários administradores
14. A2: Broken Authentication
Como prevenir?
• Implemente verificações de senhas fracas,
testando novas senhas/alterações em uma
lista como a das 10.000 piores senhas
• Alinhe as políticas de comprimento,
complexidade e rotação de senhas com as
diretrizes do NIST 800-63 B na seção 5.1.1
15. A2: Broken Authentication
Como prevenir?
• Limite ou atrase cada vez mais as tentativas de
login malsucedidas
• Registre todas as falhas e avise os
administradores quando forem detectados
credential stuffing, força bruta ou outros
ataques
16. A2: Broken Authentication
Como prevenir?
• Use um gerenciador de sessão interno, seguro e
no lado do servidor que gere um novo ID de
sessão aleatório após o login
• Os IDs de sessão não devem estar na URL, devem
ser armazenados e invalidados com segurança
após os tempos limite de logoff e inatividade
17. Para mais informações, acesse:
www.owasp.org
Fernando Galves
São Paulo Chapter Leader
fernando.galves@owasp.org