Código seguro com OWASP e SSDLC - 2 ASVS

Fala galera,

Tudo beleza?

Como prometido e Dando continuidade ao conteudo de Código Seguro com OWASP e SSDLC, hoje vamos falar do ASVS.

Mas obviamente para começar:

O que é ASVS?

ASVS é uma sigla que significa "Application Security Verification Standard" (Padrão de Verificação de Segurança de Aplicativos), e o projeto OWASP ASVS é uma iniciativa da OWASP que visa fornecer um conjunto de diretrizes e requisitos de segurança para o desenvolvimento e testes de aplicativos web.

O objetivo principal do ASVS é garantir que os aplicativos web sejam projetados e construídos com segurança desde o início, protegendo-os contra as ameaças cibernéticas mais comuns.

O OWASP ASVS é uma ferramenta do cara... para desenvolvedores, "testadores" e profissionais de segurança . Ele fornece um conjunto abrangente de requisitos de segurança que podem ser usados como um guia para desenvolvimento seguro e teste de aplicativos.

Nota: a versão atual do ASVS utilizada na escrita desse artigo é a 4.0.3 (a 5.0 ja foi anunciada)

E como Funciona?

O OWASP ASVS é organizado em três níveis de segurança, cada um com requisitos específicos. Na maioria dos casos se sua aplicação esta no Nivel 1 eu ja fico feliz por você hahaha, pois é o minimo que se espera de um testes. Porem conforme exista uma maior complexidade do negocio e os tipos de dados envolvidos é necessario subir o nivel:

Nível 1 - Verificação Automatizada

É o nível mais básico. Este nível é focado em verificações automatizadas que podem ser implementadas durante o ciclo de desenvolvimento.

Ele inclui testes como verificação de vulnerabilidades conhecidas e configurações seguras de servidor web. Esses testes podem ser facilmente integrados em pipelines de CI/CD (Integração Contínua/Entrega Contínua) para fornecer feedback imediato aos desenvolvedores.

Nível 2 - Recomendado para aplicações e sistemas que contêm dados pessoais Verificação Funcional, geralmente para a maioria de aplicações comerciais.

O segundo nível envolve verificações manuais para garantir que os requisitos de segurança estejam sendo atendidos. Isso inclui testes de autenticação, autorização, criptografia e proteção contra ameaças comuns, como injeção de SQL e XSS (Cross-Site Scripting). (OWASP Top Ten)

Nível 3 - Verificação de Arquitetura

Recomendado para aplicações críticas e transacionais uma aplicação que requeira um alto nível de confiabilidade.

O nível mais alto do OWASP ASVS envolve revisões mais aprofundadas da arquitetura de segurança do aplicativo. Isso inclui avaliações de design de segurança, análise de risco e considerações de ameaças. Também aborda a conformidade com regulamentações de segurança, como GDPR (Regulamento Geral de Proteção de Dados) e HIPAA (Lei de Portabilidade e Responsabilidade de Seguro de Saúde).

Cada nivel vai complementando o anterior , então dependendo do tipo de aplicação é necesario aplica-los.

A implementação do ASVS prove : Maior segurança, Padrões Claros, Integração com CI/CD e Conformidade Regulatória.

Arquitetura ASVS :

Focando nos primeiros niveis se você deseja que seu aplicativo tenha um padrão de segurança de alto nivel alguns tipos de "arquiteturas" podem ser uteis.

Claro, considerando que você esta aplicando o OWASP Top TEN no seu ciclo de desenvolvimento ja podemos considerar que você esta no caminho certo, porem, para reforçar vamos falar especificamente de algumas arquiteturas que serão abordadas de forma mais detalhada nos proximos artigos :

Authentication Architecture

• Utilize patterns de segurança existentes
• Aplica frameworks/métodos de autenticação de mercado e testados : não vai inventar o seu próprio sendo que existem varios opensource como Keycloack e gratuitos para começar como o Azure B2C
• Prefira uma a varias formas de autenticação : Se possivel utilize apenas uma forma de autenticação, isto alem de diminuir a complexidade diminui os riscos de brechas de segurança
• Autenticação segura para componentes de backend e serviços de terceiros : Principalmente em arquiteturas de microserviços é importante lembrar de criar uma autenticação segura entre os mesmos e claro em qualquer arquitetura uma autenticação segura com serviços que você não tem o controle
• Logs e monitoramento : Manter um monitoramento constante de quem e de onde é autenticado em sua aplicação. Isso facilita o rastreio para evitar problemas futuros.

Access Control Architecture

• Quem pode acessar o que e quais dados : Roles devem ser levadas a serio, é importante sempre tratar os dados que devem ou não ser acessados de acordo com as regras e perfis de acesso
• Um Único mecanismo bem testado para autenticação : Diversos mecanismos criam complexidades desnecessárias e abrem brechas de segurança
• Verificação de controles acontece só no Cliente ou no Server também? : Caso você esteja implementando tanto a solução de Client como Server prefira realizar a validação em ambos os lados. Isto melhora a segurança e tambem garante uma integridade de dados caso va compartilhar sua api com terceiros.

Input and Output Architecture

• Validação do que é Enviado : Validação de dados que são enviados para sua aplicação como formularios, sql injection, dados sem criptografia e dados que não deveriam estar la
• Validação do que é retornado : Tão perigoso quanto o envio são os dados retornados. É importante garantir que toda informação retornada seja para o perfil correto ou não possua dados sensiveis.

Cryptographic Architecture

• Os dados estão devidamente criptografados? : Tudo que é enviado ou gerado pela sua aplicação com informações sensiveis deve ter algum tipo de criptografia. Isso minimiza problemas e brechas de segurança em trafegos de dados.
• O que você armazena do lado do Client? : Cookies, secrets entre outros são informações armazenadas que podem abrir brechas para vazamentos de dados e possiveis invasores. É importante tomar cuidado no que é armazenado.
• Os dados do lado do servidor estão protegidos? : Não adianta nada proteger apenas o lado do Client,informações da aplicação publicada devem ser protegidas tambem. Prefira armazenar informações sensiveis em keyvaults do que em arquivos de configuração por exemplo.
• Considere um cenario caso se algum invasor consiga roubar uma chave ou algum “secret”

Auditing Architecture

• Erros
• Logs de informações
• Auditoria
• Proteção de Logs Sensíveis : Essa parte é muito importante!! Deve-se tomar cuidado com o que se loga de facil acesso.Um log pode revelar informações sensiveis que abrem brechas de segurança e facilitam o acesso de um invasor para roubos de informações.

Nota : gravamos um episódio do devshow só desse tema , vale a pena escutar.

Data Protection And Privacy Architecture

• Dados devem ser classificados :

1. Publico
2. Interno
3. Confidencial

Aplique controles próprios para cada tipo de informação garantindo que dados sensiveis não fiquem expostos.

Communications Architecture

• Proteja/Criptografe dados que são transmitidos
• Não exponha dados compartilhados entre micro serviços, Apis ou containers

Malicious Software Architecture

• Repositório GIT : Deve se tomar cuidado com o que você armazena em seus repositórios
• Secrets em Commits : Nunca, jamais, nem por brincadeira deve-se commitar secretes e informações sensiveis em repositórios.
• Bagunça em Branch : Branchs bagunçadas ou com nomes de desenvolvedores podem gerar dores de cabeça e abrir brechas de segurança. Prefira adotar um padrão como Gitflow por exemplo

Existem algumas ferramentas como Sonarqube/SonarCloud e GitGuardian quem podem lhe ajudar não permitir que informações Sensiveis sejam guardadas em repositórios.

Business Logic Architecture

• Autenticação
• Controle de Acesso
• Gerenciamento de Sessão (expirar e etc)
• Regras de negocio com tratamentos e validações

Muitas vezes os problemas de segurança estão na própria regra de negócio da aplicação. Aplique validações consistentes e revisões de logica. Um Código bem feito pode evitar problemas de segurança.

Secure File Upload Architecture

• Quais arquivos podem ser enviados? : Garanta que apenas os arquivos permitidos sejam possiveis de ser inseridos em sua aplicação
• Validação de Tipos de Arquivo : Um bom começo é permitir apenas extensões validas de acordo com sua regra de negócio
• Validação de Arquivos Maliciosos : Tenha um validador de arquivos eficiente para garantir que arquivos maliciosos não consigam prejudicar sua aplicação
• Arquivos que podem ser baixados : Garanta quais arquivos podem ou não ser baixados

Configuration Architecture

• Build and Deployment : Tenha uma esteira de Devops configurada e segura, garantindo quais informções estão em variaveis de ambiente, arquivos e etc
• Monitorar vulnerabilidades
• Variáveis de Ambientes para projetos separados
• Fontes assinadas

Ufa!!! Creio que para esse artigo ja tem muita coisa hehehe.

Segurança é um assunto extenso e que deve ser levado a sério, então creio que com essas boas praticas sua aplicação deve atingir um nivel excelente de segurança durante o ciclo de desenvolvimento.

Recentemente fizemos uma live no Canal .net sobre o Assunto, quem quiser pode conferir :

Espero ter ajudado!

Aquele abraço!