OWASP: padrão de verificação de segurança de aplicações

Authentication Verification Requirements - Introdução

Bem-vindo a mais um curso de OWASP! Nesse curso nós vamos pegar os diversos riscos e vulnerabilidades ligados com OWASP Top 10 e vamos falar sobre padrões de verificação para segurança dessas aplicações.

Então, quer dizer, eu vou desenvolver uma aplicação e eu quero ter algum padrão mínimo de segurança. Então eu tenho que ter um checklist, uma lista que eu possa seguir de itens, para que me diga se eu estou indo para o caminho certo, se eu atendi essas coisas ou se eu não atendi.

Então esse relatório da própria OWASP, assim como existem outras instituições que fazem outros relatórios, vai fornecer para nós uma lista de requerimentos diversos, centenas de requerimentos para nós cumprirmos em relação a tudo que está ligado ao processo de autenticação, autorização e segurança em geral da nossa aplicação.

Nós vamos nesses próximos cursos, atacar cada um desses itens ligados primeiro ao level 1, porque isso daqui é quebrado em três níveis de segurança. O primeiro nível é o que atende às necessidades do OWASP Top 10.

O segundo nível serve para outras aplicações e a maior parte dos problemas de segurança em geral. O nível 3 para super aplicações - não é “super aplicações” o nome da palavra, mas aplicações de autovalor etc. que são as que precisam de ter o máximo de confiança no seu sistema. Então esse é o nível 3 e nós vamos atacar primeiro o que atende ao OWASP Top 10, que é o nível 1.

Então nós vamos passar por essas centenas de itens que nós estamos falando agora, que eu estou citando aqui. Nós vamos discutir eles um a um, exemplos falando sobre como que isso deve ser feito, como que isso não deve ser feito e qual que é o tipo de ataque que ele está defendendo. Vamos lá!

Authentication Verification Requirements - OWASP Application Security Verification Standard

Então, vamos começar! O arquivo que nós vamos analisar então da OWASP é o padrão de verificação de segurança de uma aplicação.

Esse padrão vai conter uma centena de dicas. Na verdade, não são dicas, são requerimentos. O que esses requerimentos nos falam? Eles falam, por exemplo, suporte e senhas, ou exije senhas que tenham no mínimo 12 caracteres. Então, repare que é algo super testável, por exemplo. Muito fácil de testar até mesmo automaticamente.

Existem outros requerimentos que são mais difíceis de testar automaticamente. Por exemplo: requeira senhas, ou requeira processo de autenticação, multifator - isto é, não só algo que você saiba que é uma senha, como algo que você tenha que é um cartão que dá um código específico. Então você tem que ter esse cartão, então são dois fatores.

Então isso é mais difícil de nós testarmos automaticamente, ou em questões técnicas que nós devemos utilizar durante o processo de desenvolvimento de software seguro. Então essas técnicas são mais difíceis de nós testarmos automaticamente.

Mas todas essas técnicas vão aparecer como requerimentos para os nossos sistemas. Claro, nós vamos quebrar isso em alguns níveis de segurança, um nível. “1, 2 e 3”. Na verdade, é 1, 2 e 3, do mais básico para o mais seguro.

E nós podemos usar isso como uma métrica, olhe: nós já atacamos 100 dos 300 pontos. Nós atacamos 101, 102, 103, nós podemos usar como uma métrica que nós queremos seguir.

Nós podemos utilizar isso como um guia, isto é, um guia para os desenvolvedores e desenvolvedoras para colocarmos controles de segurança, que satisfaçam os requerimentos de segurança de uma aplicação. Então é um guia que todo mundo tem que ler. É chato de ler, eu entendo. Nós discutimos no curso que nós esmiuçamos os detalhes da leitura durante o curso.

Ou colocarmos como um “procurement”, isto é, na hora que você vai fazer uma contratação de terceiros para desenvolver um software ou algo do gênero, terceirizar isso. Você coloca isso como requerimentos na verificação de segurança da sua aplicação, então você pode usar esse documento de diversas maneiras.

Vamos para o documento. Nesse primeiro vídeo eu queria só discutir essas questões dos níveis. Então você vai descendo aqui, você vê, são quase 70 páginas. Deixe-me dar uma olhadinha aqui. Ele vai falar dos níveis, ele chama de três níveis diferentes.

O primeiro nível que é o “low assurance level”, que é o nível baixo, que é o primeiro nível, que é totalmente testável com testes de penetração. Então são testes que nós podemos fazer de forma automática.

Um segundo nível para aplicações que possuem dados sensíveis e requer uma proteção maior, é o nível de recomendação para a maior parte das aplicações.

E o nível três que é para aplicações críticas, que têm transações de autovalor, que possuem dados médicos sensíveis e que possuem outras questões que envolvem um máximo nível de confiança no sistema.

Então esses são os três níveis. O que é importante e que nós vamos atacar neste curso, especificamente nessa sequência? Nós vamos atacar o nível 1. Por que nós vamos atacar o nível 1? Por que nós vamos descer um pouquinho aqui? Porque o nível 1 é quem ataca, literalmente defende os pontos do OWASP Top 10.

Então os requerimentos do nível 1 são suficientes para atacar os pontos do OWASP Top 10, são eles que nós queremos que todos os nossos desenvolvedores, desenvolvedoras de qualquer aplicação estejam cientes e adequados a eles, entendendo e utilizando eles de alguma maneira.

Nível 2, para a maior parte das aplicações, é o nível recomendado para a maior parte das aplicações. O nível 3, é para outras aplicações. Claro, isto é subjetivo, você vai escolher talvez até coisas talvez do nível 2 e do nível 3 para as suas aplicações, vai depender de você, do seu projeto etc.

Vamos lá! Claro, a partir daqui ele cita, olhe. Isso daqui poderia ser feito através de uma certificação. Uma empresa pode criar uma certificação e certificar e não sei o quê etc. e tal. Não é o nosso foco específico, a nossa maneira de utilizar esse guia.

A nossa maneira de utilizar esse guia é: quero me defender do OWASP Top 10, quero saber o nível 1, quero explorar o nível 1 e quero entender e esmiuçar todos os pontos citados aqui, que como de costume são resumidos. Quero esmiuçar eles para que eu possa me defender para o nível 1.

E o nível 2, nível 3, são níveis mais avançados; mais para frente.

Vamos dar uma olhada aqui. Ele separa então em vários pontos. O primeiro ponto, que é o designer, a arquitetura, a modelagem de ameaças e os requerimentos ligados a isso. Então vai falar do nível do ciclo de desenvolvimento do software que eu citei anteriormente, mas repare que os pontos citados aqui são do nível 2 e do nível 3.

Então, verificar que o ciclo de vida, desenvolvimento do software, endereça; ele vai estar atento às questões de segurança durante todas as fases de desenvolvimento. Então durante todas as fases de desenvolvimento, você está atento às questões de segurança.

Isto é o nível 2, é um requerimento a partir do nível 2. Então nós não vamos atacar especificamente. Cada um desses pontos, alguns deles, possuem um código CWE. Então o código CWE1053, eu posso ir lá, CWE1053, e nós temos o “missing documentation for design”.

E nós temos o “missing documentation for design”. Então, por exemplo: nesse caso que tem o CWE1053. Você pode ir na internet e procurar o “common weakenss enumeration, 1053”, que está relacionado às questões de documentação, está relacionado à documentação e a cada fase de design etc.

Então você tem o CWE aqui para procurar, se você quiser esmiuçar mais ainda cada um desses pontos, porém o V1., esse primeiro capítulo aqui inteiro é level 2 para cima. Portanto, eu vou passar por ele e nós vamos começar a partir do v2, que é a parte de verificação de autenticação. Quais são os requerimentos, qual é o objetivo dessa fase etc. que aparecem pontos do level 1. Esse daqui é o que nós vamos atacar daqui a pouquinho.

Authentication Verification Requirements - Password Security Requirements

Então vamos começar com os requerimentos de verificação de autenticação. O que é isso, “autenticação”? Relembrando: autenticar é ter certeza que uma pessoa é quem ela diz que é. Então se é o Guilherme acessando esse sistema, dizendo que é o Guilherme; ele é o Guilherme mesmo? Eu preciso validar isso.

Qual é a forma mais comum de validar? Nós perguntamos para a pessoa que está utilizando qual o usuário dela e a senha, porque só o usuário qualquer um nos engana, então nós pedimos o usuário e nós pedimos uma senha. Essa é a forma mais comum de autenticação.

Ela é um fator. Por que ela é um fator? Por que ela é conhecida como o quê? Ela é conhecida como uma coisa que você sabe, é uma senha que você sabe. Ela pode ser um PIN numérico, ela pode ser uma senha com caracteres e números, ela pode ser um padrão que você desenha na tela do seu celular. Tudo isso é algo que você sabe, então nós autenticamos você através desses conhecimentos.

Mas é claro, dá para ir muito além, além de algo que você sabe. Como nós discutimos lá no OWASP Top 10, pode ter algo que você tem, que é por exemplo, um cartão com várias senhas que foi dado para você. Então esse cartão foi dado, você tem que ter este cartão. Se este cartão é simplesmente um “copy paste”, poderia ser considerado algo que você sabe e não algo que você tem.

E algo que você é, para saber que você é, por exemplo. O que eu tenho? Minha impressão digital, a minha impressão digital é algo que eu sou. Não é algo que eu tenho, não é algo que eu sei.

Então nós temos três fatores que nós podemos utilizar. Então o celular receber um código é algo que eu tenho. O celular recebe um código que eu tenho que digitar, então eu tenho o celular. Se eu não tenho o celular, eu não tenho essa informação.

Então tem várias maneiras e ele discute que é claro, na maior parte dos sistemas, utiliza-se um único fator para autenticação, que é o “single factor authentication”, que tem muita falha e muito problema no mundo real.

Então o ideal é: sistemas que tem preocupações de segurança, em que se alguém impersonar, pegar e fingir ser a outra pessoa, vai ter um grave problema. Como, por exemplo, um banco. Como, por exemplo, um hospital. Se eu acessar um sistema de hospital como se eu fosse um outro paciente, eu teria acesso aos documentos médicos do outro paciente. Nós não queremos isso de jeito nenhum.

Eu acessando um jornal com o usuário de outra pessoa e o jornal sendo somente leitura, não tem tanto problema. Claro, é um problema, nós não queremos que isso aconteça, mas eu não estou lendo questões sensíveis sobre aquela pessoa, eu não estou roubando dinheiro de uma pessoa para outra.

Claro, a atividade é ilícita e não deveria ser feita e não deveria ser suportada, mas ela parece ser menos grave do que alguém acessar a conta bancária de outra pessoa e nesse ataque tirar o dinheiro dela. Então não é à toa que a maior parte dos sistemas usa um “single factor autentication”.

Quanto mais importante se prevenir, mais questões de segurança vão aparecer. Nós vamos no nível 2, nível 3 e muito mais.

Existe um padrão o NIST800-63 e o NIST800-63b, que documenta informações de requerimento baseado em problemas do mundo real, em questões do mundo real. Por exemplo: antigamente era sugerido que uma senha tivesse caracteres com letra maiúscula, minúscula, cifrão, duplo carpado de ponta de p, e não sei o quê. Quanto mais complexa a senha nesse sentido, era a forma de provar segurança e era o recomendado.

Mas com o passar do tempo foi se adquirindo evidências de que certos padrões de senha não eram os ideais e foi sendo criado em cima desse padrão requerimentos que condizem com o que significa segurança no mundo real, e não simplesmente na teoria. Olhe, na teoria quanto mais complexa, melhor a senha.

Teoricamente sim, mas se quanto mais complexa significa que a pessoa vai dar “copy paste” da mesma senha em todos os lufares, então a senha não é mais tão boa. Por quê? Porque uma vez que ela vaze em um lugar, um hacker utiliza essa mesma senha em todos os lugares para tentar quebrar o seu usuário.

Então você pode ver que, por mais que na teoria uma ideia possa ser o máximo de segurança, na prática e nas evidências nós vamos ver que não necessariamente ela vai ser a melhor. O padrão vai nos falar sobre isso e vai ser baseado nesse padrão que vamos ter os requerimentos aqui.

A terminologia é meio assustadora, porque você pode pensar que primeiro: senha é um segredo que você memorizou seja ele qual for. Quando eu falar “segredo memorizado”, é senha, é a terminologia, tenta ser mais precisa do que simplesmente uma palavra “senha”.

Vamos lá! Então vamos descer aqui um pouquinho, ele vai falar sobre o que que é um segredo memorizável. Como eu disse, senhas, PINs, que são basicamente números, destravamento de padrões, que você coloca o dedo e faz um desenho na tela.

Questões do tipo. Escolha qual é o gatinho que você teve na sua infância, ou outra imagem, ou ainda frases que você tem que responder. Tudo isso são consideradas coisas que você sabe e consideradas um único fator de autenticação. Então tem questões relacionadas a isso e nós vamos atacar esse tipo de questão.

Vamos ver lá! “2.1.1”, verifique que os usuários devem setar senhas com pelo menos 12 caracteres. Então é 6, 8 e 9? Não, é 12! Toda senha tem que ter no mínimo 12 caracteres, e é isso. Level 1, todos os sistemas têm que ter uma senha com no mínimo 12 caracteres.

Por que nós não podemos suportar senha com 3 caracteres? Porque a variabilidade, o universo de senhas possíveis ia ser muito pequeno e isso facilita ataques de força bruta. Então, no mínimo 12 caracteres.

E qual é o máximo? 13. Verifique que senhas de 64 caracteres ou mais são permitidas. Então de no mínimo 12, tem que suportar 64. Se você quiser, você suporta mais, mais 64. Então de 12 a 64 nós temos que suportar.

Por que 64? Porque nós queremos suportar senhas grandes, complexas e que vão ser mais difíceis de serem quebradas com força bruta. Queremos também suportar senhas que são geradas aleatoriamente por geradores de senha, como OnePass, LastPass ou seja lá o que for.

Verifique que as senhas podem conter espaços. Então as senhas têm que poder terem espaços. O espaço pode ser no começo, pode ser no final ou pode ser onde for.

E que a senha não é truncada. O que quer dizer truncada? Quer dizer que se você suporta 64 caracteres e a pessoa digita 64 caracteres e o número 1; o número 1 não pode ser jogado fora. Você tem que reclamar: “por favor, coloque 64 caracteres”.

Não é para jogar fora o número 1. Por quê? Porque se ela colocar 65 caracteres ela acredita que a senha dela tem 65 caracteres e você acabou de comer um caractere da senha sela. Não permita truncagem de caracteres de senhas.

Espaços consecutivos não devem ser coalescidos. Não sei nem como falar em português, mas não devem ser agrupados. Três espaços são três espaços, três espaços não são um espaço.

Também é outra coisa que nós queremos valida. Em outras palavras, o que isso daqui está dizendo é que tem que suportar que as senhas tenham no mínimo 12 caracteres, tenham que suportar senhas de 64 caracteres ou mais. Se eu desejar e a senha é o que a pessoa digitar, a senha não é o que a pessoa digitou, só uma parte. Além disso, a senha tem que ser qualquer caractere unicode.

Se a pessoa está digitando com emoji, isto é, 12 emojis, maravilha! Se a pessoa digitou 64 caracteres em kanji, maravilha! Se ela misturou kanji com emoji com caractere coreano, com latim americano; não tem problema nenhum! Tudo isso é senha válida, deve ser suportada.

Então, tudo isso nós estamos falando sobre criação de senha e vamos falar muito mais. O que mais? Imagine que o usuário quer alterar a senha, decidiu que a senha é antiga e gostaria de mudar. Decidiu que a senha é fraca ou descobriu que a senha vazou em outros sites, estava reutilizando a senha. Ela quer o quê? Alterar sua própria senha.

Tem que permitir alteração de senha, tem que ter uma tela que permite alterar a senha. Mais ainda, a tela que permite alteração de senha tem que pedir a senha atual. Por quê? Pense no “man-in-the-middle”, ou pense em uma maneira que a pessoa esquece a aba do navegador aberta em um lugar, ou ela fecha a aba mas continua logada.

Isto é, um atacante consegue abrir uma aba no navegador e fazer impersonação, pegar e acessar o seu site como se fosse o usuário logado atual e alterar a senha dessa pessoa sem saber a senha atual. Nós não queremos que isso aconteça. Para alterar a senha, você tem que provar que você é a pessoa que está logada no sistema, então precisa da senha atual para alterar a senha para uma senha nova.

Cuidado! Estamos falando de alteração de senha, não estamos falando do processo de lembrar a senha que eu esqueci. Este é outro processo que é discutido mais para frente.

Vamos verificar que as senhas utilizadas, seja na hora de criar uma senha, de criar uma conta, na hora do login ou na hora de alteração de senha; todos os momentos que nós colocamos uma senha no sistema, nós temos que conferir que essa senha não é uma senha comum que já foi vazada pelo mundo afora.

E quando nós falamos de comum vazada, se você fala das 1000 ou 10000 mais vazadas, são as 1000, 10000 mais comuns, provavelmente. Isso você pode procurar em listas na internet. Você pode procurar no próprio OWASP, ele tem recomendações dessas listas e você pode negar que o usuário ou a usuária, utilize essa senha.

Você pode fazer isso através de um arquivo local que tenha essas senhas ou você pode usar um sistema externo. Se de alguma maneira, pergunta para um sistema externo se aquela senha pode ser utilizada.

Muito cuidado! Se eu entro no seu site, que é o site “X” e digito que minha senha é “guilhermesilveira” e você vai mandar a minha senha para um site terceiro para conferir se a minha senha já foi vazada, é muito comum etc., muito cuidado! Você não quer mandar a senha “gruilhermesilveira” como plan/text para o site terceirizado através da API deles.

Por quê? Porque você está abrindo uma brecha de segurança, você está pegando a minha senha que eu confiei para você e enviando ela abertamente para outro canto. Não vamos fazer isso. Faça isso com carinho e atenção!

Se a senha foi vazada, se você sabe que a senha de algum dos seus usuários foi vazada, você tem que pedir uma nova senha que não foi vazada para os seus usuários. Então todo esse processo tem que ser seguido. Repare aqui que, por exemplo, validar com as senhas mais comuns, 1000 ou 10000, não é um processo complexo de ser feito.

Verificar que a senha é forte. O que é uma senha forte? Uma senha forte é quem toma Toddynho? Não, não é! Na minha época era Todynho que falava na propaganda, ou sei lá, tiveram outras coisas.

Uma senha forte é o quê? Uma senha forte é uma senha que seja difícil de ser quebrada. Então quer dizer que eu vou inventar uma regra aqui: “olhe, três caracteres com letra maiúscula, três minúsculo, dois códigos, um duplo carpado e uma parada de mão por dez segundos. Se fizer isso, é uma senha forte!” Não é!

Tem descrições de como fazer isso, tem algoritmos já discutidos e vantagens e desvantagens. Você pode procurar “five algorithms to measure real password strength”, é uma recomendação, por exemplo, de um colega do Nubank, de algoritmos para validar a força de uma senha.

Então existem algoritmos que você pode utilizar para validar isso. Então tem como isso daqui poder ser feito e existem implementações desses algoritmos. Então utilize alguma coisa do gênero.

Verificar que não existem regras de composição. A regra de composição é aquilo que eu falei: “olhe, número de caracteres especiais, números de letras minúsculas e números de letras maiúsculas”. Não vamos usar isso, não vamos usar essas imitações.

Por quê? Lembra? Esse tipo de limitação faz com que as pessoas reutilizem senhas entre sistemas e isso quebra. É uma brecha de segurança, porque quando um sistema vaza senha, todos os outros sistemas estão comprometidos, porque a pessoa reutilizou a senha.

Verificar que não existem rotação de credencial ou de senha, e que não existe requerimentos de senhas históricos. Então não tem essa história de rotacionar, de daqui dez dias você tem que rotacionar. Porque não tem essa história de rotacionar daqui 10 dias? O que que nós fazemos quando temos que rotacionar? Nós reutilizamos a mesma senha em vários sistemas.

O que acontece quando temos histórico de senhas? Nós primeiro ficamos com o histórico de senhas do sistema e segundo: a pessoa tem que ficar recriando senhas e relembrando diversas senhas em vários sistemas. Ela não faz isso. O que ela faz? Reutiliza as senhas em vários sistemas.

Então, quando nós pensamos em nós mesmos isolados parece uma ideia genial, mas você percebe que você fazendo isso e os outros fazendo isso, todo mundo se dá mal em conjunto. Então nós não queremos isso.

Verificar que pode fazer um “paste” da senha. Por favor, permita fazer um “paste” na sua senha. Por quê? Porque os “helpers” de senha, os geradores de senha, o manjadores de senhas etc. que costumam ser “plugings” para os navegadores ou para aplicativos mobile etc. vão utilizar em geral, a funcionalidade de “paste”, de colar a senha dentro daquele campo, ou mesmo porque a pessoa quem copiar do aplicativo e colar nesse campo.

Então tem que permitir colar senha nesse campo, sim. Então os gerenciadores de senhas externos têm que ser permitidos. Por quê? Justamente para permitir que as pessoas criem senhas complexas, ricas e distintas em sistemas distintos. Nós temos que permitir isso.

Por fim, permitir que o usuário possa ver a senha dele temporariamente que ele está digitando. Então ele clica naquele olhinho e vê a senha que está sendo digitada ou simplesmente vê o último caractere que foi digitado, sabe aquele que ajuda bastante. Para nós termos certeza. “Será que eu digitei o 4 ou o 5? Eu apertei meu dedão aqui, meu dedão é grande. Eu apertei o 4, mas não sei se apertei o 5!”

Então olhar o último caractere já ajuda um pouco, ou colocar o olhinho para ter certeza que eu digitei a senha que eu queria digitar. Apertar o olhinho, nós apertamos de novo para sumir, ou algo do gênero. Então aqui é o que ele fala, o objetivo disso é facilitar o “input”.

Então repare que esse conjunto de requerimentos, são 12 requerimentos ligados com segurança da sua senha, só a segurança da sua senha. Nós vamos ter mais dezenas e dezenas e dezenas de requerimentos em outras áreas.

Todos esses que nós discutimos são ligados ao OWASP Top 10, todos esse que nós vimos são do L1 e são testáveis automaticamente. Nós conseguimos criar testes automatizados para esses requerimentos e deixar eles nos nossos sistemas.

Nós vamos passar para o próximo item daqui a pouquinho.

Sobre o curso OWASP: padrão de verificação de segurança de aplicações

O curso OWASP: padrão de verificação de segurança de aplicações possui 130 minutos de vídeos, em um total de 25 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Authentication Verification Requirements
• Authenticator Lifecycle Requirements
• Out of band verifier Requirements
• Fundamental Session Management Requirements
• Access Control Verification Requirements