Durante minha jornada, eu já tive a oportunidade de ministrar várias aulas de segurança em aplicações e também desenvolvimento para programadores. Posso afirmar que quando se trata de vulnerabilidades, há uma espécie de tríade de conhecimento:
Como é que a vulnerabilidade ocorre? Ou seja, mecanicamente, como ela funciona?
Porque ela é tão perigosa? Quais são os principais danos que ela pode causar?
O que deve ser feito para a evitar ou eliminar essa vulnerabilidade?
Baseado em minha experiência, quando estou explicando uma vulnerabilidade aos desenvolvedores de software e outras pessoas envolvidas neste processo, percebo que os profissionais de segurança frequentemente falham em uma dessas três partes dessa tríade.
O projeto mais conhecido da OWASP é o OWASP Top 10, cujo objetivo é ser uma lista atualizada regularmente demonstrando as vulnerabilidades mais exploradas e mais perigosas relacionadas a aplicações Web. Esse projeto se sai bem ao abordar o Como e o Porquê dessas vulnerabilidades, mas não se concentra tanto no “O que” fazer a respeito delas.
Porém para quem ainda conhece, a OWASP tem uma vasta gama de outras listas Top 10, incluindo algumas focadas em vulnerabilidades para aplicações móveis e também para APIs, ou seja, cada uma dessas listas é um projeto individual com específicos colaboradores e mantenedores.
A minha lista Top 10 favorita da OWASP é a Top 10 de Controles Pró-Ativos, lista esta, que inclusive me referi na minha publicação anterior sobre Considerações de segurança ao criar uma nova aplicação Web.
Enquanto muitas das outras listas abordam vulnerabilidades que podem ocorrer em um determinado tipo de aplicação, a lista de Controles Pró-Ativos identifica ações e práticas a serem tomadas na durante o desenvolvimento de software, buscando evitar que este contenha vulnerabilidades. Em outras palavras, ela demonstra através de ações como arquitetos e programadores devem se precaver. Graças ao trabalho árduo de vários colaboradores da OWASP, temos uma nova versão dos 10 principais controles Pró-Ativos publicada neste ano, sendo que a versão anterior era de 2018.
Neste contexto, minha tarefa aqui será analisar brevemente as alterações realizadas nessa nova lista e compartilhar algumas das minhas ideias sobre cada um dos 10 itens apresentados.
C1 - Implementar Controle de Acesso
Logo de cara, é possível ver que este controle aborda o assunto autorização. Se olharmos para a lista da OWASP das 10 principais vulnerabilidades contidas na edição de 2021, veremos que os controles de acesso que foram explorados e “quebrados” também estão no topo da lista, portanto na minha opinião, esta é absolutamente a melhor opção para estar no topo.
Atualmente, as aplicações Web têm muita segurança que é definida através de padrões, mas os controles de acessos tendem a ter uma lógica empresarial adicional por detrás que torna praticamente inevitável que alguma implementação manual seja adicionada. Portanto, um possível risco catastrófico pode facilmente surgir, justamente por não conseguir aplicar por completo os controles neste processo de autorização. A versão anterior de 2018 já tinha uma opção chamada “Aplique controles de acesso” bem parecida com esta, porém anteriormente a mesma aparecia abaixo na lista, em 7.º lugar. Minha opinião é que definitivamente isso é uma grande mudança.
C2 - Utilizar Corretamente a Criptografia
Esta inclusão abrange a proteção de uma vasta gama de dados, incluindo segredos de aplicação, como por exemplo, strings de conexão de base de dados, armazenamento de senhas de usuários, forma de encriptação dos dados armazenados em disco, chaves de assinatura para JWTs (JASON Web Tokens), entre outros. De certa forma, este item combina elementos que já existiam anteriormente na lista de 2018, sendo eles: (C3) Mantenha o Acesso a Base de Dados Seguro e (C8) Proteja os dados, porém agora especificamente aborda também uma série de casos que se tornaram cada vez mais comuns, como as chaves do JWT acima mencionadas. Considero esta inclusão bastante importante, porém em minha opinião, ela pode estar tentando combinar muitas coisas em um único item, deixando deste modo a mesma não muito focada ou coesa. Um ponto importante que achei é a forma simplificada de discussão de funções criptográficas, para torná-la mais acessível aos desenvolvedores que podem não ter tido ainda familiaridade com PKI. Para resumir, acho que é uma inclusão muito boa, mas não gosto muito da forma como é apresentada.
C3 - Validar Todas Entradas com Tratamento de Exceptions
Este é um ótimo conselho e de aspecto fundamental para o desenvolvimento de qualquer tipo de aplicação. Ele também combina a lista de 2018 com os itens, (C5) Valide Todas as Entradas e (C10) Faça o Tratamento de Erros e Exceções. Considero que a orientação escrita para este item é bastante bom, existem apenas pequenas coisas que eu mudaria, como uma condenação mais severa da utilização da abordagem denylist para a validação de entradas, mas, no geral, acho que este item apresenta a quantidade certa de detalhes de uma forma muito clara e legível.
C4 - Abordar segurança desde o início
Este item incorpora de certa forma o anterior da lista de 2018, (C1) Defina os Requisitos de Segurança, mas é mais um substituto do que um análogo direto. Apresenta claramente algumas grandes ideias a serem seguidas na concepção de desenvolvimento seguro. Para mim, esta item parece estar atualmente ainda um pouco fraco… Há mais coisas que podem ser consideradas para melhorar este item, com alguma discussão sobre onde e como incorporar a segurança no SDLC, talvez fazer referência às funções e práticas de negócios do OWASP SAMM, especialmente em torno de Design, Implementação e Verificação. Também gostaria de ver este item mais à frente na lista, talvez no segundo ou terceiro lugar, mas, na sua forma atual, percebo o porquê não está. Continua valendo a pena dar uma melhor olhada, mas espero que futuramente este receba algum carinho adicional com uma pequena revisão que o desenvolva melhor.
C5 - Configurações de segurança padrão
Esta é uma outra recomendação que é bastante concisa, mas cobre partes importantes para a maioria dos projetos de desenvolvimento de software. A minha inclinação teria sido escrevê-la como Utilizar Configurações Seguras (Use Secure Configurations), e depois lidar com a questão de Segurança Padrão (Secure-by-Default). Isto posto, possuo as seguintes considerações:
- Nem sempre é possível e está dentro dos seus dentro dos seus controles a segurança por padrão. E quando isso não acontece, é necessário tentar compensar de algum outro modo, por exemplo, se a implantação da sua aplicação envolve a configuração de uma instância de um serviço de fornecedor que usa uma senha padrão, você não pode torná-la segura por padrão, mas sim, deve alterar a senha para que isso passe a acontecer.
- Algumas vezes, a Segurança Padrão pode ser reforçada ainda mais para a sua utilização, portanto, quando isso for possível, você deve obviamente optar por fazer.
Apesar de eu estar sendo crítico aqui, os conselhos existentes neste item são muito bons, especialmente para quem está a criar aplicações que se integram com serviços na nuvem.
C6 - Mantenha os seus Componentes Seguros
Este é um item fantástico, de cabo a rabo. Ele aborda a utilização de dependências de terceiros e o potencial risco para vulnerabilidades e ataques à cadeia de suprimentos. As estratégias de mitigação são abordadas com bastante detalhes. Se a minha equipe trabalhasse em um mesmo espaço físico, eu certamente imprimiria a seção “Melhores práticas” em letras grandes e fixava na parede.
C7 - Implementar Identidade Digital
O mesmo título aparecia na versão anterior de 2018, porém na posição C6. Grande parte do texto é praticamente o mesmo, mas continua a ser um guia sólido para considerações de autenticação e gestão de sessões. Detectei algumas áreas onde em minha opinião poderia haver atualizações adicionais, como a discussão do atributo de cookie SameSite, onde no texto de 2018 tem o conteúdo, mas não reflete o estado atual da tecnologia. O SameSite é amplamente suportado pelos navegadores modernos, e o seu comportamento padrão, quando não especificado, mudou em alguns deles, portanto valeria a pena comentar. Se fosse eu que estivesse atualizando este item, provavelmente iria querer incluir uma discussão adicional sobre a utilização de fornecedores de autenticação de terceiros como o Okta, AWS Cognito, SSO baseado em SAML e OpenID Connect. Também parece que o WebAuthn poderia ter sido incluído nesta seção.
C8 - Aproveitar os Recursos de Segurança do Navegador
Fiquei contente por ver este item na lista. A orientação é bem direcionada, embora um pouco esparsa, mas as listas de ferramentas e referências que eles compilaram para este item são incríveis. Todos os programadores de aplicações Web devem estar familiarizados com tudo o que é referido nesta lista. Acho que ela se encaixa bem no 8º lugar da lista, mas novamente é um ótimo tópico e uma com certeza uma inclusão inteligente.
C9 - Implementar logging e monitoramento de segurança
Este tópico também estava na mesma posição na lista de 2018. É um tópico importante que ainda está bem coberto em 2024. Não há muito mais a dizer sobre ele.
C10 - Parar Server Side Request Forgery
Esta foi uma inclusão um pouco estranha para mim. Penso que o título parece imediatamente deslocado, porque se trata especificamente de prevenir uma determinada classe de vulnerabilidade. Por que não ter uma entrada para parar Cross-Site Scripting? Porque está abrangido por C3 - Validar todas as entradas e tratar exceções. Eu diria que C3, C4 e C5 abordam todos os elementos da SSRF. De fato, o primeiro dos três itens listados como formas de prevenir a SSRF é a validação do input. Para mim, este parece ser um item que não precisava de ser separado nesta lista. A sua já inclusão nos outros pontos liberaria um espaço que poderia ser utilizado para outra coisa, como a divisão do ponto C2 Criptografia em duas áreas mais específicas. Também reconheço que a equipe que está a trabalhar nisto tem uma tarefa difícil em termos de onde traçar as linhas, porque há uma tonelada de sobreposições entre tópicos.
Considerações finais
Embora eu tenha expressado algumas críticas a essa nova versão, acredito que há uma melhoria significativa em relação à versão de 2018 (e olha que eu já era fã dessa versão). A equipe do projeto da OWASP fez um trabalho fantástico ao reunir essas orientações com excelentes recursos. Com certeza há algumas áreas que eu espero que sejam um pouco mais aprimoradas, mas eu definitivamente faria do Top 10 Controles Pró-Ativos de 2024 uma leitura recomendada para desenvolvedores experientes que estão sendo solicitados a pensar mais sobre segurança como parte de suas responsabilidades diárias.
Biografia
Conheça Mic Whitehorn, nosso consultor sênior de segurança da informação e chefe de desenvolvimento na Secure Ideas. Com uma vasta experiência em segurança da informação, pentest e desenvolvimento de software, Mic possui mais de uma década de experiência em consultorias técnicas e tem atendido com excelência diversas indústrias, incluindo finanças, marketing, seguros, entretenimento e produtos farmacêuticos.
Ao longo da sua carreira, Mic contribuiu significativamente para o mercado de segurança de aplicações e pentests. Sua experiência se estende ao trabalho com tecnologias modernas e amplamente utilizadas, como Node.js, aplicações servless e serviços em nuvem. Aproveitando seu profundo conhecimento relativo ao comportamento de aplicações e navegadores, Mic tem sido fundamental para proteger sistemas críticos e dados confidenciais de seus clientes.
Tendo a mentalidade de um desenvolvedor, Mic aborda os desafios de segurança de vários ângulos, fornecendo insights exclusivos e excelentes recomendações. A sua crença no poder da colaboração levou-o a criar fortes parcerias no âmbito de defesa, garantindo uma abordagem holística à cibersegurança que atenua de maneira eficaz os riscos.
A paixão de Mic por práticas de codificação seguras influenciou positivamente a comunidade de desenvolvimento nos EUA. Através de treinamentos acessíveis, compartilha os seus conhecimentos sobre metodologias de codificação segura, desenvolvimento avançado de provas de conceito web e segurança de arquitetura de API de microsserviços, inspirando os programadores a criar aplicações robustas e resilientes.
Reconhecido como um comunicador hábil, Mic traduz sem esforço conceitos complexos de segurança em orientações práticas para todos os diferentes níveis técnicos de uma organização. Desde as equipes de desenvolvimento que procuram aconselhamento até os executivos que tomam decisões estratégicas, a capacidade de Mic para diminuir a lacuna entre as complexidades técnicas e as implicações comerciais faz dele um especialista muito procurado.
Num cenário digital de rápida evolução, Mic Whitehorn permanece na vanguarda, dedicado a tornar o mundo virtual um lugar mais seguro para empresas e utilizadores. O seu compromisso inabalável com a excelência e a sua paixão pela segurança da informação continuam a impulsionar a sua procura de soluções inovadoras e metodologias de ponta.