TL;DR
O OWASP ASVS é uma lista de verificação detalhada e orientada para a comunidade para verificar a segurança das aplicações Web - utilizada por programadores, testadores e arquitectos.
Abrange áreas como AuthN, AuthZ, criptografia, segurança de API - dividida em L1 (básica) a L3 (aplicações críticas).
Não é um certificado, mas é ideal para definir linhas de base de segurança, orientar testes de intrusão ou criar aplicações seguras a partir do zero.
Resumo do quadro de pontuação do OWASP ASVS:
- Esforço do desenvolvedor: Moderado a elevado (requer a compreensão dos controlos de segurança detalhados em muitos domínios e a sua correta implementação durante o desenvolvimento; utilizado como referência durante os testes).
- Custo das ferramentas: Baixo a moderado (a norma em si é gratuita; os custos estão relacionados com as ferramentas utilizadas para efetuar testes em relação aos requisitos ASVS - SAST, DAST, IAST, ferramentas de teste de penetração).
- Impacto no mercado: elevado (norma do sector amplamente respeitada para a verificação da segurança das aplicações Web; frequentemente utilizada como base para definir os requisitos de segurança e os âmbitos dos ensaios).
- Flexibilidade: elevada (os níveis permitem uma adaptação em função do risco; os requisitos específicos podem ser considerados não aplicáveis).
- Intensidade da auditoria: N/A (Não é uma norma de auditoria formal para certificação, mas é utilizada durante avaliações/testes de segurança que podem ser intensos).
O que é o OWASP ASVS?
O OWASP Application Security Verification Standard (ASVS) é um projeto de código aberto que fornece uma estrutura de requisitos e controlos de segurança especificamente para verificar a segurança das aplicações Web. Tem dois objectivos principais:
- Para programadores: Fornece uma lista pormenorizada de requisitos de segurança para orientar práticas de desenvolvimento seguras.
- Para testadores: Fornece uma base para testar os controlos de segurança técnica de aplicações Web durante avaliações de segurança, testes de penetração ou revisões de código seguro.
O OWASP ASVS está estruturado em capítulos que abrangem os principais domínios de segurança:
- V1: Arquitetura, conceção e modelação de ameaças
- V2: Autenticação
- V3: Gestão de sessões
- V4: Controlo de acesso
- V5: Validação, Sanitização e Codificação
- V6: Criptografia armazenada
- V7: Tratamento de erros e registo
- V8: Proteção de dados
- V9: Segurança das comunicações
- V10: Código malicioso
- V11: Lógica comercial
- V12: Ficheiro e recursos
- V13: API e serviço Web
- V14: Configuração
Em cada capítulo, são listados os requisitos de verificação específicos (controlos). Crucialmente, o OWASP ASVS define três Níveis de Verificação de Segurança (Níveis ASVS), indicando níveis crescentes de profundidade e rigor:
- Nível 1 (Baixa garantia): Destinado a aplicações de baixo risco ou como um primeiro passo. Centra-se em vulnerabilidades e controlos facilmente detectáveis que podem frequentemente ser verificados automaticamente (por exemplo, testes de penetração básicos). Todas as aplicações devem ter como objetivo, pelo menos, o nível 1.
- Nível 2 (garantia padrão): Recomendado para a maioria das aplicações, especialmente as que lidam com dados sensíveis ou realizam transacções importantes. Requer verificações mais aprofundadas que abrangem a proteção contra riscos comuns de segurança das aplicações (como o OWASP Top 10). Requer testes automatizados e manuais, incluindo elementos de revisão de design/código.
- Nível 3 (Alta garantia): Para aplicações críticas que lidam com dados altamente sensíveis (por exemplo, finanças, saúde, governo). Requer uma verificação de segurança abrangente, incluindo uma análise aprofundada da conceção, uma análise do código e testes rigorosos para resistir a atacantes qualificados.
O nível exigido determina quais os requisitos de verificação específicos de cada capítulo que devem ser cumpridos.
Porque é que é importante?
O OWASP ASVS é uma pedra angular da segurança moderna das aplicações Web porque:
- Fornece padronização: Oferece um padrão consistente e repetível para o que constitui uma aplicação Web segura, indo além dos testes ad-hoc.
- Orientação acionável: Dá aos programadores requisitos concretos e aos testadores itens específicos para verificar, colmatando a lacuna entre os princípios de alto nível e a implementação.
- Abordagem baseada em risco: O sistema de níveis permite que as organizações adaptem os esforços de verificação com base no perfil de risco da aplicação.
- Complementa o OWASP Top 10: Enquanto o Top 10 lista os riscos comuns, o ASVS fornece os controlos detalhados necessários para mitigar esses riscos (e muitos outros).
- Reconhecimento do sector: Amplamente respeitado e utilizado globalmente por programadores, profissionais de segurança e organizações que adquirem software.
- Suporta o SDLC seguro: Pode ser integrado em todo o SDLC - definindo requisitos, orientando a conceção/codificação e formando a base para os testes de verificação.
- Código aberto e orientado para a comunidade: Disponível gratuitamente e constantemente atualizado por uma comunidade global de especialistas em segurança.
A utilização do OWASP ASVS ajuda a garantir que os testes de segurança são completos, consistentes e centrados nos controlos que realmente importam para proteger as aplicações Web.
O que e como implementar (técnica e política)
Implementar o OWASP ASVS não é obter a certificação; é usar o padrão para criar e verificar aplicativos seguros:
- Determinar o nível necessário: Com base na sensibilidade dos dados da aplicação, na criticidade do negócio e nos requisitos regulamentares, escolha o nível ASVS pretendido (1, 2 ou 3).
- Integrar nos requisitos (fase de conceção): Utilizar os requisitos ASVS para o nível escolhido (e capítulos relevantes) como contributo para os requisitos de segurança durante as fases de conceção e planeamento.
- Exemplo (Controlo de Acesso V4): Se criar uma aplicação que exija diferentes funções de utilizador, reveja os requisitos do Capítulo V4 da ASVS, como o V4.1.1 ("Verifique se a aplicação aplica regras de controlo de acesso numa camada de serviço fiável...") e conceba o sistema em conformidade.
- Desenvolvimento do guia (fase de codificação): Os programadores utilizam os requisitos ASVS como uma lista de verificação para garantir que são seguidas práticas de codificação seguras.
- Exemplo (validação de entrada V5): Ao criar formulários de entrada, consulte os requisitos da V5, como V5.1.1 ("Verificar se a aplicação tem defesas contra poluição de parâmetros HTTP...") e V5.2.1 ("Verificar se os dados estruturados são fortemente tipados..."). Implemente bibliotecas e rotinas de validação de entrada que cumpram estes requisitos.
- Informar os testes de segurança (fase de verificação): Os testadores de segurança (pen testers, revisores de código) utilizam a lista de verificação ASVS para o nível-alvo para estruturar a sua avaliação. Verificam se cada requisito aplicável foi cumprido.
- Exemplo (Autenticação V2): Um testador que verifica o Nível 2 verificaria requisitos como V2.2.1 ("Verificar se o comprimento mínimo da palavra-passe é de 12 caracteres..."), V2.1.1 ("Verificar se as credenciais nunca são armazenadas de forma recuperável...") e V2.4.1 ("Verificar se existe um mecanismo de bloqueio de conta...").
- Integração de ferramentas:
- Ferramentas SAST/DAST: Configurar scanners para verificar violações relacionadas com os requisitos ASVS (por exemplo, encontrar potenciais falhas de injeção relacionadas com a V5).
- Gestão de listas de verificação: Utilize folhas de cálculo ou ferramentas como o SecurityRAT para gerir os requisitos ASVS, acompanhar a aplicabilidade e registar os resultados da verificação.
- Documentação: Documentar como os requisitos ASVS foram cumpridos (ou porque foram considerados não aplicáveis) como parte dos documentos de projeto, comentários de código e relatórios de teste.
A implementação consiste em utilizar ativamente a lista ASVS ao longo do SDLC - como um guia para construir com segurança e uma lista de verificação para verificar a segurança.
Erros comuns a evitar
Ao utilizar o OWASP ASVS, tenha em atenção estes erros comuns:
- Escolher o nível errado: Selecionar o Nível 1 para uma aplicação de alto risco, ou apontar para o Nível 3 quando os recursos apenas permitem a verificação do Nível 2, conduzindo a avaliações inadequadas ou incompletas.
- Tratando-o apenas como uma lista de verificação de pentest: O ASVS é mais amplo do que apenas pentesting; os níveis 2 e 3 exigem aspectos de design e revisão de código. Confiar apenas no controlo dinâmico não permite detetar vulnerabilidades cruciais.
- Ignorar a aplicabilidade: Tentar aplicar cegamente todos os requisitos sem considerar se são relevantes para a arquitetura, pilha de tecnologia ou funcionalidades da aplicação específica.
- Falta de formação dos programadores: Esperar que os programadores cumpram os requisitos ASVS sem os formar nos conceitos de segurança subjacentes e nas práticas de codificação seguras necessárias.
- Aplicação inconsistente: Aplicar o ASVS rigorosamente durante um teste, mas superficialmente durante o teste seguinte, levando a uma postura de segurança inconsistente.
- Não integração precoce: Utilizar o ASVS apenas no final para testar, em vez de o utilizar para informar a conceção e o desenvolvimento seguros desde o início (o que é muito mais eficaz).
- Interpretação incorrecta dos requisitos: Não compreender a nuance ou intenção por detrás de requisitos específicos de verificação ASVS.
O que os auditores/testadores perguntarão (foco no desenvolvedor)
Os testadores de segurança que utilizam o OWASP ASVS pedem essencialmente aos programadores (diretamente ou através da revisão do código/design) que demonstrem como os requisitos específicos são cumpridos:
- (V1) "Pode mostrar-me o modelo de ameaça para esta aplicação?" (1.1.1 - L2+)
- (V2) "Como são armazenadas as palavras-passe dos utilizadores? Pode mostrar a implementação do hashing?" (2.2.2 - L1+)
- (V3) "Como é que os tokens de sessão são gerados e protegidos contra a pirataria?" (3.1.1, 3.3.1 - L1+)
- (V4) "Demonstrar como a aplicação impede um utilizador normal de aceder à funcionalidade de administração." (4.1.1, 4.1.2 - L1+)
- (V5) "Mostre-me as rotinas de validação de entrada utilizadas para este ponto final crítico da API". (5.1.3, 5.2.1 - L1+)
- (V6) "Onde e como são geridas as chaves criptográficas na aplicação?" (6.2.1 - L2+)
- (V7) "Como é que a aplicação trata os erros sem deixar escapar informações sensíveis?" (7.1.1 - L1+)
- (V8) "Como são protegidos os dados sensíveis quando armazenados na base de dados (encriptação, mascaramento)?" (8.1.1 - L2+)
- (V13) "Como é que a autenticação e a autorização são tratadas para os pedidos de API?" (13.1.1, 13.2.1 - L1+)
Procurarão provas concretas no código, na configuração, nos documentos de conceção ou na aplicação em execução para verificar a conformidade com cada requisito ASVS relevante para o nível-alvo.
Ganhos rápidos para as equipas de desenvolvimento
Os programadores podem começar a incorporar facilmente os princípios do OWASP ASVS:
- Concentre-se nos princípios básicos do Nível 1: Comece por rever e implementar os requisitos de nível 1 em áreas-chave como a autenticação (V2), o controlo de acesso (V4) e a validação de entrada (V5). Estes cobrem muitas falhas comuns.
- Usar padrões de estrutura segura: Aproveite os recursos de segurança integrados da sua estrutura da Web (por exemplo, para gerenciamento de sessão, proteção CSRF, codificação de saída) que geralmente se alinham com o ASVS.
- Validar e codificar: Validar consistentemente todas as entradas e codificar todos os resultados destinados a navegadores, APIs ou bases de dados. (Núcleo da V5)
- Implementar o registo básico: Assegurar que os principais eventos de segurança (logins, falhas, transacções significativas) são registados. (Essencial da V7)
- Revisar o OWASP Top 10: Compreender os 10 principais riscos e como os controlos ASVS ajudam a mitigá-los.
- Utilizar ferramentas SAST: Configurar as ferramentas SAST para assinalar violações relacionadas com requisitos ASVS comuns (por exemplo, manuseamento inseguro de palavras-passe, potenciais pontos de injeção).
Ignorar isto e... (Consequências do incumprimento)
Ignorar os princípios e requisitos descritos no OWASP ASVS significa negligenciar os controlos fundamentais de segurança das aplicações Web. As consequências são diretas:
- Maior probabilidade de violações: As aplicações serão mais vulneráveis a ataques comuns, como XSS, injeção de SQL, autenticação deficiente, controlo de acesso deficiente, etc. (diretamente relacionados com os capítulos ASVS).
- Perda/roubo de dados: As vulnerabilidades permitem que os atacantes roubem dados sensíveis dos utilizadores, conduzindo a violações da privacidade e a multas regulamentares (por exemplo, RGPD).
- Perturbação do serviço: Os ataques podem colocar as aplicações offline, causando perturbações no negócio e perda de receitas.
- Danos à reputação: Os incidentes de segurança afectam a confiança dos clientes e prejudicam a marca da empresa.
- Auditorias/Pentestes de segurança falhados: Se os clientes ou parceiros exigirem testes de segurança, uma aplicação que não tenha sido criada com os princípios ASVS em mente irá provavelmente falhar, bloqueando potencialmente negócios ou implementações.
- Aumento dos custos de correção: Encontrar e corrigir vulnerabilidades numa fase tardia do ciclo ou após uma violação é muito mais dispendioso do que criar segurança utilizando o ASVS como guia.
Essencialmente, não aderir ao OWASP ASVS significa criar aplicações Web inerentemente inseguras.
FAQ
O OWASP ASVS é uma norma de conformidade como o SOC 2 ou a ISO 27001?
Não. A OWASP ASVS é uma norma de verificação, essencialmente uma lista de verificação pormenorizada para testar a segurança das aplicações Web. Não envolve auditorias formais ou certificações como SOC 2 ou ISO 27001, que abrangem sistemas de gestão mais amplos. No entanto, o cumprimento dos níveis ASVS pode ajudar a satisfazer os requisitos de controlo técnico dentro dessas estruturas mais amplas.
Qual é a diferença entre o OWASP ASVS e o OWASP Top 10?
O OWASP Top 10 lista os dez riscos mais críticos para a segurança das aplicações Web com base em dados e consensos da comunidade. O OWASP ASVS fornece os controlos de segurança detalhados e os requisitos de verificação necessários para prevenir e testar esses riscos (e muitos outros). O Top 10 diz-lhe quais são os principais problemas; o ASVS diz-lhe como verificar as suas defesas contra eles.
Qual o nível ASVS a que devemos aspirar?
Depende do risco. O nível 1 é a base de referência mínima para todas as aplicações. O nível 2 é recomendado para a maioria das aplicações que lidam com dados ou transacções sensíveis. O nível 3 destina-se a aplicações altamente críticas em que uma falha tem consequências graves (por exemplo, dados financeiros e de saúde).
É necessário cumprir 100% dos requisitos para um determinado nível?
Em geral, sim, para todos os requisitos aplicáveis. A norma permite que os requisitos sejam assinalados como "Não Aplicável" se não se aplicarem efetivamente à tecnologia ou funcionalidade da aplicação, mas tal exige uma justificação. Por vezes, podem ser aceites controlos de compensação se um requisito específico não puder ser cumprido diretamente.
O ASVS destina-se apenas a testes de penetração?
Não. Embora sejam muito utilizados em testes de penetração (especialmente no Nível 1), os Níveis 2 e 3 do ASVS exigem explicitamente uma verificação para além dos testes dinâmicos, incluindo revisões da arquitetura, da conceção e do código-fonte. Destina-se à verificação holística da segurança da aplicação.
Com que frequência devemos efetuar a verificação em relação ao ASVS?
A verificação deve ser integrada no SDLC. Isto pode significar a verificação dos requisitos relevantes durante as revisões de código, a execução de testes automatizados alinhados com o ASVS em CI/CD e a realização de avaliações ASVS completas (ao nível do objetivo) antes dos principais lançamentos ou periodicamente (por exemplo, anualmente) para aplicações críticas.
O ASVS pode ser utilizado para APIs e aplicações móveis?
O capítulo V13 do OWASP ASVS aborda especificamente a verificação de APIs e serviços Web. Embora se concentre principalmente em aplicações Web, muitos princípios aplicam-se de forma geral. Para aplicações móveis específicas, a OWASP também tem a Norma de Verificação de Segurança de Aplicações Móveis (MASVS).