E ai pessoal!
A muito tempo atrás eu comecei a postar uma série explicando como funciona cada uma das 10 falhas mais comuns, classificadas pela OWASP. Só agora me sobrou um tempo para continuar postando.
Até agora temos 2 falhas já explicadas basicamente. Assim que eu tiver um tempo eu faço um repost um pouco mais detalhado.
Já atualizando para a nova versão do OWASP Top 10, temos até o momento:
OWASP Top 10: A1 Injection
OWASP Top 10: A3 Cross Site Scripting
E vamos ao que interessa!
Cerca de 90% das aplicações web hoje em dia usam simples formulários em HMTL para autenticação, capturando o usuário e senha informado e encaminhando para uma função de autenticação.
Funções de autenticação ou sessão são normalmente desenvolvidas com falhas graves que podem ser facilmente ignoradas podendo causar o vazamento de credenciais, e também causar escalação de privilégios horizontalmente. Escalação de privilégios horizontalmente quer dizer, um usuário comum acessar informações de outro usuário comum, e a escalação vertical é quando um usuário normal acessa informações de uma conta com acesso superior.
A muito tempo atrás eu comecei a postar uma série explicando como funciona cada uma das 10 falhas mais comuns, classificadas pela OWASP. Só agora me sobrou um tempo para continuar postando.
Até agora temos 2 falhas já explicadas basicamente. Assim que eu tiver um tempo eu faço um repost um pouco mais detalhado.
Já atualizando para a nova versão do OWASP Top 10, temos até o momento:
OWASP Top 10: A1 Injection
OWASP Top 10: A3 Cross Site Scripting
E vamos ao que interessa!
Cerca de 90% das aplicações web hoje em dia usam simples formulários em HMTL para autenticação, capturando o usuário e senha informado e encaminhando para uma função de autenticação.
Funções de autenticação ou sessão são normalmente desenvolvidas com falhas graves que podem ser facilmente ignoradas podendo causar o vazamento de credenciais, e também causar escalação de privilégios horizontalmente. Escalação de privilégios horizontalmente quer dizer, um usuário comum acessar informações de outro usuário comum, e a escalação vertical é quando um usuário normal acessa informações de uma conta com acesso superior.
O comum nas aplicações web atuais é um sistema de login seguro e completamente blindado onde nenhuma requisição maliciosa pode passar, mas em outros campos como “Esqueci minha senha”, “Lembrar-me”, troca de senha, entre outros, nenhuma verificação de segurança é realizada e através desses campos as informações podem ser obtidas.
O erro do desenvolvedor está em não dar a mesma atenção com relação a segurança a todos os campos e funções onde o usuário interage com a aplicação. Outro erro bem comum é utilizar exatamente a mesma função de segurança para todas as páginas e campos, o que pode causar algum bug e escapar dos métodos de segurança.
Este tipo de falha está cada vez mais comum hoje em dia, subindo para segundo lugar nesta última versão, tomando o lugar do XSS. Vejamos algumas falhas na criação das aplicações de hoje em dia:
- Senhas fracas: Muitas aplicações web hoje em dia ainda tem falhas críticas nas suas políticas de senha. É comum ver sites que permitem senhas muito curtas ou até mesmo em branco, permitem palavras presentes em dicionários ou nomes, uma senha padrão, ou até mesmo o login na senha.
- Possibilidade de Bruteforce: Sem dúvida você viu o vazamento de fotos que vazou de celebridades a algum tempo atrás. Isso foi causado por essa falta de cuidado. A aplicação permite que um usuário tente diversas vezes combinações de usuário/senha sem problema nenhum, isso quer dizer, permite o uso da técnica de bruteforce de tentar milhares de tentativas.
- Mensagens de erro vazando informação: Normalmente aplicações usam 2 ou mais campos para autenticar usuários, como por exemplo login/senha, e até mesmo outras informações como tokens, senhas de dois passos, datas de nascimento e etc. O maior erro dos desenvolvedores é avisar indiretamente, com mensagens de erros diferentes, qual é o campo que está errado, em vez de uma mensagem genérica.
- Falhas na funcionalidade de mudar a senha: Em muitas aplicações é comum que um campo seja informado errado e volte uma mensagem de erro informando que algum campo de login foi inserido errado. O erro dos desenvolvedores está em informar exatamente qual o campo está errado com mensagens de erro diferente. Um usuário mal intencionado pode usar isso para enumerar possíveis usuários da aplicação e depois executar um ataque de dicionário ou bruteforce para conseguir as senhas. O correto seria uma mensagem genérica de "usuário ou senha incorreta" para dificultar e não vazar informações sensíveis.
- Sistemas de troca de senha falhos: Sistemas de troca de senha ou recuperação de senha podem por descuido também informar informações sensíveis da senha atual. Por exemplo, o campo "Nova senha" pode retornar mensagens de erro como "Nova senha não pode ser igual a senha atual".
E vou ficando por aqui! Eu poderia escrever muito mais falhas e erros básicos que os desenvolvedores cometem até mesmo sem saber, no intuito de fazer algo bom e seguro, que entram nessa categoria de Broken Authentication, mas isso já está bom para exemplificar o que esta categoria do OWASP Top 10 quer dizer.
Imagens originalmente publicadas no livro The Web Application Hacker's Handbook.
- Mensagens de erro vazando informação: Normalmente aplicações usam 2 ou mais campos para autenticar usuários, como por exemplo login/senha, e até mesmo outras informações como tokens, senhas de dois passos, datas de nascimento e etc. O maior erro dos desenvolvedores é avisar indiretamente, com mensagens de erros diferentes, qual é o campo que está errado, em vez de uma mensagem genérica.
- Falhas na funcionalidade de mudar a senha: Em muitas aplicações é comum que um campo seja informado errado e volte uma mensagem de erro informando que algum campo de login foi inserido errado. O erro dos desenvolvedores está em informar exatamente qual o campo está errado com mensagens de erro diferente. Um usuário mal intencionado pode usar isso para enumerar possíveis usuários da aplicação e depois executar um ataque de dicionário ou bruteforce para conseguir as senhas. O correto seria uma mensagem genérica de "usuário ou senha incorreta" para dificultar e não vazar informações sensíveis.
- Sistemas de troca de senha falhos: Sistemas de troca de senha ou recuperação de senha podem por descuido também informar informações sensíveis da senha atual. Por exemplo, o campo "Nova senha" pode retornar mensagens de erro como "Nova senha não pode ser igual a senha atual".
E vou ficando por aqui! Eu poderia escrever muito mais falhas e erros básicos que os desenvolvedores cometem até mesmo sem saber, no intuito de fazer algo bom e seguro, que entram nessa categoria de Broken Authentication, mas isso já está bom para exemplificar o que esta categoria do OWASP Top 10 quer dizer.
Imagens originalmente publicadas no livro The Web Application Hacker's Handbook.
0 comentários:
Postar um comentário