Post

Application security - AppSec

Postado em Atualizado
AppSec
AppSec
Por v0xn0x 27 min de leitura

Introdução

A segurança de aplicações, conhecida como AppSec (Application Security), é uma das bases fundamentais para proteger sistemas modernos contra vulnerabilidades e ataques. Este artigo explora conceitos, frameworks, práticas recomendadas e ferramentas essenciais para incorporar a segurança no ciclo de desenvolvimento de software. Aqui, você encontrará tudo o que precisa para entender como tornar suas aplicações mais seguras e confiáveis.

O que é Desenvolvimento Seguro?

O desenvolvimento seguro de software é uma abordagem que aplica práticas de segurança em todas as etapas do ciclo de vida da aplicação. Desde o brainstorming inicial até o deploy e monitoramento contínuo, o objetivo é mitigar ameaças e proteger dados críticos.

Aqui estão exemplos práticos que demonstram como a segurança pode ser integrada em cada etapa do ciclo de vida de uma aplicação:

Exemplo 1: Brainstorming Inicial

Durante a fase de brainstorming para o desenvolvimento de um e-commerce, os envolvidos discutem possíveis cenários de ataque, como:

  • Um cliente malicioso que tenta manipular os valores no carrinho de compras.
  • Tentativas de acesso não autorizado ao histórico de compras de outros usuários.

Ação de Desenvolvimento Seguro:
Incluir controle de acesso rigoroso desde o início e prever validações no lado do servidor para valores financeiros.

Exemplo 2: Definição de Requisitos

Em um sistema de gerenciamento hospitalar, é definido que ele deve proteger dados sensíveis, como informações de pacientes.

Ação de Desenvolvimento Seguro:
Adicionar como requisito obrigatório o uso de criptografia (como AES-256) para armazenar informações de pacientes no banco de dados.

Exemplo 3: Planejamento de Segurança

Ao planejar o desenvolvimento de uma aplicação bancária, é identificado que um possível ataque seria a falsificação de solicitações de transações bancárias (CSRF).

Ação de Desenvolvimento Seguro:
Planejar a inclusão de tokens CSRF em todas as requisições que envolvam alterações financeiras.

Exemplo 4: Design Seguro

Um aplicativo de delivery projeta sua arquitetura para incluir:

  • Uma API de terceiros para processamento de pagamentos.
  • Integração com sistemas de geolocalização.

Ação de Desenvolvimento Seguro:
Implementar comunicação criptografada (HTTPS) para todas as integrações, além de autenticação OAuth para a API de pagamentos.

Exemplo 5: Desenvolvimento (Build)

Durante a codificação de um sistema de login, o desenvolvedor decide armazenar senhas diretamente no banco de dados.

Ação de Desenvolvimento Seguro:
Evitar armazenar senhas em texto puro, usando um algoritmo de hash seguro como bcrypt ou Argon2.

Exemplo 6: Testes

Em uma aplicação que manipula uploads de arquivos, os testes identificam que um atacante pode fazer upload de arquivos executáveis.

Ação de Desenvolvimento Seguro:
Validar extensões de arquivos permitidas e sanitizar nomes de arquivos para evitar execução de scripts maliciosos.

Exemplo 7: Deploy

Um sistema de monitoramento industrial é colocado em produção sem validar as permissões no servidor.

Ação de Desenvolvimento Seguro:
Aplicar hardening no servidor, desabilitando portas e serviços desnecessários e garantindo que as permissões de arquivos estejam corretas.

Exemplo 8: Monitoramento Contínuo

Após o lançamento de uma aplicação de rede social, um administrador identifica várias tentativas de login em contas com senhas fracas.

Ação de Desenvolvimento Seguro:
Implementar monitoramento de logs e alertas em tempo real, além de bloqueio automático de IPs após várias tentativas de login.

Por que o AppSec é essencial?

Falhas de segurança podem surgir em qualquer etapa do desenvolvimento, comprometendo tanto o negócio quanto os usuários. O AppSec permite detectar e corrigir vulnerabilidades precocemente, reduzindo custos e protegendo a reputação da organização.

Benefícios do AppSec

  • Detecção antecipada de falhas: Reduz custos de correção.
  • Mitigação de riscos regulatórios: Protege contra multas e penalidades legais.
  • Proteção da reputação: Evita incidentes que possam prejudicar a imagem da empresa.
  • Melhoria da qualidade do produto: Segurança incorporada desde a concepção.

Os Quatro Cavaleiros do Apocalipse

Mesmo com a adoção crescente de práticas de AppSec, erros críticos ainda são cometidos. Entre eles, destacam-se o que chamamos de Os Quatro Cavaleiros do Apocalipse:

  1. Ansiedade pela entrega: A pressão para finalizar projetos compromete a qualidade.
  2. Prazos irreais: Decisões apressadas ignoram medidas de segurança.
  3. Priorizar funcionalidade sobre segurança: Segurança é vista como um custo extra.
  4. Atalhos perigosos: Abordagens como “Go Horse” levam a retrabalho e aplicações vulneráveis.

Consequências:

  • Exposição de dados sensíveis.
  • Retrabalho caro e demorado.
  • Riscos legais e danos à reputação.

Pirate Bay e as Regras de Negócio Mal Planejadas

Um exemplo clássico de falha em regras de negócio ocorreu com o Pirate Bay. Um escritório jurídico entrou com uma ação coletiva contra o site, financiada por uma vaquinha online. A regra de cobrança da vaquinha era simples: as primeiras 1.000 doações eram isentas de taxas, mas, após isso, cada doação gerava uma cobrança de 1 SEK.

O Pirate Bay descobriu que a plataforma de Crowdfunding cobrava a taxa de 1 SEK sem levar em consideração o valor doado e incentivou os usuários a doar apenas 1 centavo, desestabilizando o modelo financeiro do escritório, chegando ao panto do escritório dever para a plataforma.

Estatísticas Alarmantes no AppSec

De acordo com o relatório “Cost of a Data Breach 2020” da IBM, o custo médio global de uma violação de dados foi de USS 3.86 milhões por incidente. No Brasil, esse valor foi de aproximadamente RS 6.2 milhões em 2023, conforme o relatório “Cost of a Data Breach 2023” da IBM.

Além disso, o custo por registro comprometido varia conforme o setor. Por exemplo, no setor de saúde, o custo médio por registro perdido ou roubado foi de US$ 408, quase três vezes mais do que a média entre setores, que foi de USS 148.

Esses dados destacam a importância de práticas robustas de segurança da informação para mitigar os custos associados a vazamentos de dados.

SSDLC

O SSDLC (Secure Software Development Life Cycle) é uma metodologia que integra segurança ao ciclo de vida do desenvolvimento de software.

Fases do SSDLC

  1. Análise de Requisitos: Identificar requisitos funcionais e de segurança.
  2. Planejamento: Definir recursos e estratégias para mitigar riscos.
  3. Design: Projetar uma arquitetura robusta e segura.
  4. Build: Desenvolver seguindo boas práticas de segurança.
  5. Code Testing: Identificar vulnerabilidades antes do deploy.
  6. Deploy: Implementar medidas de segurança na produção.

Modelos de Ciclo de Vida no Desenvolvimento

Waterfall

Um modelo tradicional que segue uma estrutura linear, com pouca flexibilidade para mudanças.

  • Vantagens: Planejamento simples e previsibilidade de custos.
  • Desvantagens: Dificuldade em lidar com alterações durante o projeto.

Agile (Scrum)

Um modelo iterativo e incremental que permite maior flexibilidade.

  • Vantagens: Feedback contínuo e adaptação rápida.
  • Segurança: O AppSec deve ser integrado desde o início para evitar vulnerabilidades.

DevSecOps

O DevSecOps (Segurança no Ciclo DevOps) é uma abordagem moderna que integra a segurança como um componente central em todas as fases do ciclo de vida do desenvolvimento de software, desde o planejamento até a operação. A ideia é tratar a segurança como uma responsabilidade compartilhada entre desenvolvedores, equipes de operações e especialistas em segurança, em vez de deixá-la como uma etapa final ou exclusiva de uma equipe.

Por que DevSecOps é essencial?

Tradicionalmente, a segurança era considerada um “gargalo” no processo de desenvolvimento, sendo aplicada somente após o código estar pronto ou já em produção. Isso criava atrasos e aumentava os custos para corrigir vulnerabilidades identificadas tardiamente. O DevSecOps resolve esse problema ao integrar práticas de segurança em todas as etapas, reduzindo riscos e acelerando o time-to-market.

Princípios Fundamentais do DevSecOps

1. Shift Left: Identificar falhas precocemente

O princípio do Shift Left consiste em mover as práticas de segurança para o início do ciclo de desenvolvimento. Isso significa que vulnerabilidades são identificadas e corrigidas ainda na fase de codificação, onde o custo e o impacto são significativamente menores.

Exemplo prático:

  • Durante o desenvolvimento de uma API REST, um desenvolvedor cometeu um erro que permitia SQL Injection em uma consulta de banco de dados. Com uma análise SAST (Static Application Security Testing) integrada ao ambiente de desenvolvimento, o erro foi detectado e corrigido antes mesmo do código ser commitado.

Benefícios do Shift Left:

  • Redução de custos com correções.
  • Aumento da qualidade do código.
  • Menor risco de incidentes em produção.
2. Cultura Colaborativa: Envolver todos na segurança

No DevSecOps, a segurança deixa de ser responsabilidade exclusiva de uma equipe especializada e passa a ser uma prática integrada a todas as funções. Desenvolvedores, analistas de operações e profissionais de segurança trabalham juntos para identificar e mitigar riscos.

Exemplo prático:

  • Em uma empresa de e-commerce, a equipe de desenvolvimento realiza reuniões quinzenais com o time de segurança para revisar novas features. Durante uma dessas reuniões, foi identificado que uma funcionalidade de “compartilhar carrinho” precisava de criptografia para proteger os dados do cliente.

Boas práticas para criar uma cultura colaborativa:

  • Educação: Treinamentos regulares em segurança para todos os times.
  • Ferramentas acessíveis: Fornecer ferramentas de segurança fáceis de usar e integradas aos processos já existentes.
  • Feedback contínuo: Compartilhar resultados de testes de segurança com os desenvolvedores, mostrando não só os problemas, mas também as soluções aplicáveis.
3. Automação: Segurança no ritmo do CI/CD

A automação é um dos pilares do DevSecOps, garantindo que práticas de segurança sejam integradas no pipeline de CI/CD (Continuous Integration/Continuous Deployment) sem desacelerar o desenvolvimento. Ferramentas automatizadas realizam análises de código, varreduras de vulnerabilidades e testes dinâmicos continuamente.

Exemplo prático:

  • Uma fintech utiliza uma pipeline automatizada que inclui:
    • SAST (Static Application Security Testing): Para detectar vulnerabilidades no código-fonte durante o commit.
    • DAST (Dynamic Application Security Testing): Para simular ataques em um ambiente de teste ao final da fase de build.
    • IAST (Interactive Application Security Testing): Para analisar o comportamento da aplicação em execução.

Essa automação detectou uma falha crítica de Cross-Site Scripting (XSS) em uma aplicação web antes do deploy, evitando um potencial ataque.

Ferramentas comuns de automação no DevSecOps:

  • SAST: SonarQube, Checkmarx.
  • DAST: OWASP ZAP, Burp Suite.
  • IAST: Contrast Security.
  • RASP: Runtime Application Self-Protection, integrado diretamente na aplicação.

Benefícios da automação:

  • Redução de esforço manual.
  • Identificação mais rápida de vulnerabilidades.
  • Escalabilidade, permitindo que grandes equipes mantenham a segurança sem comprometer a velocidade.

Casos Reais: Impacto do DevSecOps

  1. Startup de SaaS:
    Uma startup implementou DevSecOps e detectou, em ambiente de desenvolvimento, uma vulnerabilidade que permitia acesso não autorizado a dados sensíveis de clientes. Isso foi corrigido antes de causar impactos financeiros ou danos à reputação.

  2. Setor Financeiro:
    Em um banco, a automação de testes de segurança revelou um endpoint vulnerável à manipulação de dados financeiros. A correção foi realizada rapidamente, prevenindo um possível vazamento que poderia violar normas regulatórias.

Desafios ao Implementar DevSecOps

Embora os benefícios sejam claros, implementar DevSecOps exige mudanças culturais e técnicas:

  • Resistência inicial: Equipes podem ver segurança como um “freio” ao desenvolvimento.
  • Complexidade técnica: Integrar ferramentas e criar pipelines robustos requer investimento inicial.
  • Treinamento contínuo: É necessário educar todos os times sobre boas práticas de segurança.

Como superar esses desafios:

  • Comece pequeno, integrando ferramentas de segurança em uma única etapa do pipeline e expandindo gradualmente.
  • Promova a colaboração entre as equipes desde o início.
  • Use métricas para mostrar como a segurança melhora os resultados do negócio.

OWASP

A OWASP (Open Web Application Security Project) é a principal referência para segurança em aplicações web e mobile. Seus projetos incluem listas de vulnerabilidades, guias de mitigação e frameworks de avaliação.

OWASP Top 10 para Web (2021)

O OWASP Top 10 destaca as vulnerabilidades mais críticas em aplicações web, apresentando riscos comuns e suas respectivas mitigações. Aqui estão as vulnerabilidades detalhadas, com exemplos e boas práticas:

A01: Broken Access Control (Falhas no Controle de Acesso)

Descrição:
Falhas no controle de acesso permitem que usuários realizem ações ou acessem recursos para os quais não possuem permissão.

Exemplo:

  • Em um sistema de gerenciamento de arquivos, um usuário comum consegue acessar documentos restritos apenas modificando o parâmetro da URL, como GET /files/secret.pdf.

Mitigação:

  • Adote validações de permissões rigorosas no servidor.
  • Utilize o princípio do menor privilégio.
  • Realize testes regulares para identificar permissões incorretas.
A02: Cryptographic Failures (Falhas Criptográficas)

Descrição:
Inclui uso inadequado de algoritmos criptográficos, má configuração ou falta de proteção de dados sensíveis.

Exemplo:

  • Uma aplicação armazena números de cartões de crédito sem criptografia. Em caso de vazamento, todos os dados ficam expostos.

Mitigação:

  • Armazene dados sensíveis usando criptografia forte (ex.: AES-256).
  • Garanta o uso de HTTPS para proteger dados em trânsito.
  • Não reutilize chaves criptográficas.
A03: Injection (Injeção)

Descrição:
Dados maliciosos enviados para um intérprete podem comprometer a aplicação ao permitir a execução de comandos inesperados.

Exemplo:

  • Em um formulário de login, inserir admin' OR '1'='1 no campo de senha pode permitir acesso ao sistema sem credenciais válidas.

Mitigação:

  • Use consultas parametrizadas (Prepared Statements).
  • Valide todas as entradas do usuário.
  • Evite concatenar strings diretamente em comandos SQL.
A04: Insecure Design (Design Inseguro)

Descrição:
O design inseguro ocorre quando questões de segurança não são levadas em conta durante a concepção da aplicação.

Exemplo:

  • Um sistema de e-commerce não possui limite de tentativas de login, permitindo ataques de força bruta.

Mitigação:

  • Realize modelagem de ameaças no início do desenvolvimento.
  • Implemente limites de tentativa, como bloqueio temporário após 5 falhas de login.
A05: Security Misconfiguration (Configuração Malfeita)

Descrição:
Configurações incorretas em servidores, frameworks ou bibliotecas podem expor vulnerabilidades.

Exemplo:

  • Um servidor web está configurado para exibir mensagens de erro detalhadas com informações sobre diretórios e versões de software.

Mitigação:

  • Desabilite mensagens de erro detalhadas em produção.
  • Realize auditorias de configuração regulares.
  • Use ferramentas automatizadas para detectar configurações incorretas.
A06: Vulnerable and Outdated Components (Componentes Desatualizados e Vulneráveis)

Descrição:
O uso de bibliotecas, frameworks ou componentes desatualizados pode introduzir vulnerabilidades conhecidas.

Exemplo:

  • Uma aplicação utiliza uma versão antiga do Log4j vulnerável ao ataque Log4Shell, permitindo execução remota de código.

Mitigação:

  • Mantenha todos os componentes e bibliotecas atualizados.
  • Use ferramentas de análise de dependências, como OWASP Dependency-Check.
  • Remova componentes que não são mais utilizados.
A07: Identification and Authentication Failures (Falhas de Identificação e Autenticação)

Descrição:
Falhas na autenticação e identificação de usuários podem permitir acessos não autorizados.

Exemplo:

  • Uma aplicação permite a reutilização de senhas antigas, comprometendo a segurança em caso de vazamento.

Mitigação:

  • Exija senhas fortes e implemente autenticação multifator (MFA).
  • Use tokens únicos para sessões autenticadas.
  • Configure políticas de expiração e rotação de senhas.
A08: Software and Data Integrity Failures (Comprometimento de Dados e Software)

Descrição:
Ocorre quando a integridade de software ou dados críticos não é garantida.

Exemplo:

  • Um invasor compromete um pacote npm malicioso usado pela aplicação, injetando código malicioso no sistema.

Mitigação:

  • Use assinaturas digitais para verificar a integridade de pacotes.
  • Implemente controles de CI/CD que detectem alterações não autorizadas.
  • Mantenha backups criptografados.
A09: Security Logging and Monitoring Failures (Falhas em Logs e Monitoramento de Segurança)

Descrição:
A falta de monitoramento eficaz impede que incidentes de segurança sejam detectados ou respondidos.

Exemplo:

  • Uma aplicação não registra tentativas de login mal-sucedidas, dificultando a identificação de ataques de força bruta.

Mitigação:

  • Configure logs detalhados de eventos de segurança.
  • Use ferramentas de SIEM (Security Information and Event Management) para análise.
  • Realize revisões regulares de logs.
A10: Server Side Request Forgery (SSRF)

Descrição:
O SSRF ocorre quando uma aplicação permite que um atacante envie requisições maliciosas para servidores internos.

Exemplo:

  • Uma aplicação permite que um invasor envie uma URL para um servidor interno, acessando recursos sensíveis como http://localhost/admin.

Mitigação:

  • Valide e sanitize todas as URLs enviadas pelo usuário.
  • Restrinja o acesso a endereços IP internos.
  • Configure firewalls para bloquear requisições não autorizadas.

OWASP Top 10 para APIs (2023)

As APIs desempenham um papel central na arquitetura moderna, mas sua exposição pública as torna alvos frequentes de ataques. O OWASP Top 10 para APIs (2023) aborda as principais vulnerabilidades que podem comprometer sua segurança.

API1: Broken Object Level Authorization (Falhas na Autorização de Objetos)

Descrição:
Falhas na autorização de objetos ocorrem quando a API não verifica se o usuário tem permissão para acessar ou manipular um recurso específico.

Exemplo:

  • Um endpoint como GET /api/orders/{orderId} permite que um usuário acesse pedidos de outros clientes apenas alterando o orderId na URL.

Mitigação:

  • Implemente verificações rigorosas de autorização no servidor para cada requisição.
  • Não confie em IDs fornecidos pelo cliente.
  • Use frameworks que suportem controle de acesso granular.
API2: Broken Authentication (Autenticação Comprometida)

Descrição:
Falhas na autenticação permitem que atacantes assumam identidades legítimas devido a senhas fracas, tokens comprometidos ou má implementação de autenticação.

Exemplo:

  • Uma API não invalida tokens JWT após logout, permitindo que um atacante use um token vazado para acessar dados.

Mitigação:

  • Use autenticação multifator (MFA) sempre que possível.
  • Configure expiração de tokens e implemente sua rotação regular.
  • Proteja endpoints de login contra ataques de força bruta.
API3: Broken Object Property Level Authorization (Problemas em Propriedades de Objetos)

Descrição:
Ocorre quando a API permite que usuários modifiquem ou acessem propriedades de objetos que deveriam estar restritas.

Exemplo:

  • Em um formulário de atualização de perfil, um usuário envia uma requisição contendo o campo role e consegue se promover a administrador ("role": "admin").

Mitigação:

  • Ignore ou valide propriedades inesperadas enviadas na requisição.
  • No lado do servidor, implemente verificações rigorosas de permissões para cada campo.
API4: Unrestricted Resource Consumption (Consumo Excessivo de Recursos)

Descrição:
APIs que não limitam o consumo de recursos estão vulneráveis a ataques que sobrecarregam servidores, como abusos de memória, CPU ou banda.

Exemplo:

  • Um atacante envia milhares de requisições a um endpoint de busca sem restrição, causando a indisponibilidade do serviço.

Mitigação:

  • Configure limites de requisições (rate limiting) e quotas para usuários.
  • Use caches para respostas de alta demanda.
  • Adote políticas de backoff exponencial para lidar com requisições excessivas.
API5: Broken Function Level Authorization (Falhas na Autorização de Função)

Descrição:
Ocorre quando a API não valida se o usuário tem permissão para acessar certas funções ou métodos.

Exemplo:

  • Um usuário comum consegue acessar um endpoint administrativo (POST /api/admin/delete-user) apenas descobrindo a URL.

Mitigação:

  • Controle rigorosamente o acesso a endpoints sensíveis com verificações de permissões baseadas em função.
  • Oculte endpoints administrativos em ambientes públicos.
API6: Unrestricted Access to Sensitive Business Flows (Acesso Irrestrito a Fluxos Sensíveis)

Descrição:
APIs que permitem acesso a processos críticos sem verificações adequadas tornam-se alvos fáceis para ataques.

Exemplo:

  • Um atacante descobre um endpoint de API para aprovar transações (POST /api/approve-transaction) e o utiliza sem autenticação adequada.

Mitigação:

  • Implemente autenticação e autorização em fluxos críticos.
  • Exija confirmações adicionais (ex.: autenticação multifator) para operações de alto impacto.
API7: Server Side Request Forgery (SSRF)

Descrição:
Falhas de SSRF em APIs permitem que atacantes enviem requisições maliciosas para servidores internos.

Exemplo:

  • Um endpoint que aceita URLs de entrada (POST /api/fetch-data?url=http://...) é usado para acessar recursos internos, como http://localhost/admin.

Mitigação:

  • Valide e sanitize todas as URLs fornecidas pelo cliente.
  • Restrinja o acesso a endereços IP internos e portas específicas.
  • Configure firewalls para filtrar requisições maliciosas.
API8: Security Misconfiguration (Configuração Malfeita)

Descrição:
Configurações inadequadas em servidores, autenticação ou bibliotecas de terceiros podem expor a API a ataques.

Exemplo:

  • Uma API expõe endpoints de teste (/debug) em produção, fornecendo informações sensíveis, como variáveis de ambiente.

Mitigação:

  • Revise configurações regularmente e remova endpoints desnecessários.
  • Desative logs detalhados em ambientes de produção.
  • Realize auditorias de segurança periódicas.
API9: Improper Inventory Management (Gerenciamento Inadequado de Inventário)

Descrição:
Falhas no rastreamento de versões e endpoints ativos podem expor APIs antigas ou não documentadas.

Exemplo:

  • Um endpoint de API legado, ainda disponível publicamente, contém vulnerabilidades já corrigidas em versões mais recentes.

Mitigação:

  • Mantenha um inventário atualizado de todas as APIs, incluindo suas versões.
  • Monitore endpoints para garantir que APIs antigas sejam desativadas ou protegidas.
  • Use ferramentas de API Gateway para gerenciar e proteger APIs.
API10: Unsafe Consumption of APIs (Consumo Inseguro de APIs)

Descrição:
APIs que consomem dados de outras APIs sem validação adequada podem introduzir vulnerabilidades em cascata.

Exemplo:

  • Uma API consome dados de uma API de terceiros que retorna valores inesperados, causando falhas na aplicação.

Mitigação:

  • Valide todos os dados recebidos de APIs externas.
  • Monitore e audite as integrações com APIs de terceiros regularmente.
  • Configure contratos claros e limites de confiança para APIs consumidas.

OWASP Top 10 para Mobile (2024)

O OWASP Top 10 para Mobile foca nas principais vulnerabilidades e ameaças específicas a aplicativos móveis, que, devido à sua natureza distribuída e presença em dispositivos pessoais, apresentam desafios únicos de segurança.

M01: Improper Credential Usage (Uso Inadequado de Credenciais)

Descrição:
Essa vulnerabilidade ocorre quando aplicativos móveis gerenciam mal credenciais, como armazená-las em locais inseguros ou expô-las inadvertidamente em logs.

Exemplo:

  • Um aplicativo de rede social armazena tokens de autenticação em texto plano no armazenamento local do dispositivo, permitindo que qualquer aplicativo malicioso no mesmo dispositivo roube o token.

Mitigação:

  • Use o armazenamento seguro oferecido pelo sistema operacional, como o Keychain no iOS e o Keystore no Android.
  • Evite armazenar credenciais sensíveis localmente sempre que possível.
  • Sempre utilize autenticação segura baseada em tokens com expiração.
M02: Inadequate Supply Chain Security (Falhas na Cadeia de Suprimentos)

Descrição:
Aplicativos podem ser comprometidos ao depender de bibliotecas de terceiros ou ferramentas de desenvolvimento vulneráveis ou maliciosas.

Exemplo:

  • Um aplicativo utiliza uma biblioteca de anúncios de terceiros que coleta dados pessoais sem consentimento e os transmite para servidores desconhecidos.

Mitigação:

  • Realize auditorias regulares de todas as bibliotecas e dependências.
  • Prefira bibliotecas open-source confiáveis e com histórico de atualizações.
  • Use ferramentas como Dependency-Check para monitorar vulnerabilidades em componentes.
M03: Insecure Authentication/Authorization (Autenticação e Autorização Inseguras)

Descrição:
Ocorre quando um aplicativo implementa autenticação ou autorização sem seguir boas práticas, permitindo que usuários não autorizados acessem funcionalidades restritas.

Exemplo:

  • Um aplicativo bancário não verifica adequadamente tokens de autenticação, permitindo que um atacante reutilize tokens de outro usuário para acessar contas bancárias.

Mitigação:

  • Use autenticação multifator (MFA) para operações sensíveis.
  • Implemente tokens de autenticação com expiração curta e rotação regular.
  • Certifique-se de que todas as requisições passem por verificações de autorização no servidor.
M04: Insufficient Input/Output Validation (Validação Insuficiente de Entrada/Saída)

Descrição:
A ausência de validação robusta de dados enviados e recebidos pelo aplicativo pode permitir a execução de ataques como SQL Injection e Cross-Site Scripting (XSS).

Exemplo:

  • Um campo de entrada de texto em um aplicativo de reservas aceita caracteres de comando, permitindo que um atacante execute injeções SQL ao enviar '; DROP TABLE users;--.

Mitigação:

  • Valide todas as entradas do usuário no lado do servidor.
  • Sanitizar dados antes de exibi-los ou armazená-los.
  • Utilize listas de permissões para entrada de dados.
M05: Insecure Communication (Comunicação Insegura)

Descrição:
Aplicativos que transmitem dados sem usar protocolos seguros, como HTTPS, estão sujeitos à interceptação (man-in-the-middle attacks).

Exemplo:

  • Um aplicativo de mensagens transmite mensagens de texto via HTTP, permitindo que um atacante em uma rede Wi-Fi pública intercepte as mensagens.

Mitigação:

  • Use HTTPS para todas as comunicações de rede.
  • Configure certificados SSL/TLS válidos e atualizados.
  • Evite armazenar dados sensíveis em cache local de solicitações.
M06: Inadequate Privacy Controls (Controles de Privacidade Inadequados)

Descrição:
Falhas que expõem ou coletam informações pessoais sem o devido consentimento dos usuários.

Exemplo:

  • Um aplicativo solicita permissões para acessar contatos e localização, mas utiliza essas informações para rastrear usuários sem notificá-los.

Mitigação:

  • Solicite apenas permissões essenciais para o funcionamento do aplicativo.
  • Seja transparente sobre o uso de dados, seguindo regulamentações como GDPR e LGPD.
  • Armazene dados de usuários de forma anonimizada sempre que possível.
M07: Insufficient Binary Protections (Proteções Binárias Insuficientes)

Descrição:
Ocorre quando aplicativos não implementam técnicas de proteção contra engenharia reversa, permitindo que invasores modifiquem o código ou extraí-lo para análise.

Exemplo:

  • Um atacante usa engenharia reversa para descobrir chaves de API hardcoded no aplicativo e as utiliza para acessar serviços protegidos.

Mitigação:

  • Obfusque o código do aplicativo usando ferramentas como ProGuard ou R8.
  • Evite armazenar chaves sensíveis no código do aplicativo.
  • Utilize técnicas de detecção de manipulação para identificar binários modificados.
M08: Security Misconfiguration (Configuração Malfeita)

Descrição:
Configurações padrão ou inadequadas no ambiente de execução podem expor dados ou funcionalidades desnecessárias.

Exemplo:

  • Um aplicativo Android expõe permissões excessivas em seu manifesto, permitindo acesso a recursos desnecessários como câmera ou microfone.

Mitigação:

  • Revise e limite permissões concedidas pelo aplicativo.
  • Configure ambientes de produção para desabilitar mensagens de erro detalhadas.
  • Realize auditorias regulares das configurações de segurança.
M09: Insecure Data Storage (Armazenamento de Dados Inseguro)

Descrição:
Armazenar dados sensíveis de forma insegura pode expor informações críticas em caso de roubo ou acesso indevido ao dispositivo.

Exemplo:

  • Um aplicativo financeiro armazena o histórico de transações em um arquivo de texto não criptografado no armazenamento local.

Mitigação:

  • Use criptografia robusta para todos os dados armazenados.
  • Evite armazenar informações sensíveis desnecessárias.
  • Utilize APIs de armazenamento seguro oferecidas pelos sistemas operacionais móveis.
M10: Insufficient Cryptography (Criptografia Insuficiente)

Descrição:
Implementações criptográficas inadequadas ou o uso de algoritmos inseguros podem comprometer a confidencialidade e a integridade dos dados.

Exemplo:

  • Um aplicativo utiliza o algoritmo de hash MD5 para armazenar senhas, permitindo que elas sejam facilmente quebradas por ferramentas de força bruta.

Mitigação:

  • Use algoritmos criptográficos robustos, como SHA-256 para hashes e AES-256 para criptografia.
  • Evite criar algoritmos criptográficos próprios.
  • Certifique-se de que a implementação está conforme as melhores práticas do setor.

OWASP Proactive Controls (2018)

O OWASP Proactive Controls apresenta as 10 principais práticas para incorporar segurança durante o desenvolvimento de software. Esse guia fornece um roteiro prático para criar aplicações seguras desde o início, tornando a segurança parte intrínseca do ciclo de desenvolvimento.

C01: Define Security Requirements (Definir Requisitos de Segurança)

Descrição:
O desenvolvimento seguro começa com a definição clara de requisitos de segurança que atendam às necessidades do projeto e ao contexto em que a aplicação será usada.

Exemplo:

  • Uma aplicação de saúde exige que todos os dados de pacientes sejam armazenados criptografados e que a autenticação multifator seja usada para acessar registros médicos.

Boas práticas:

  • Identifique requisitos específicos do negócio, como conformidade com GDPR, LGPD ou PCI DSS.
  • Inclua requisitos de proteção contra ataques como SQL Injection e XSS.
  • Use frameworks de requisitos de segurança, como o OWASP ASVS (Application Security Verification Standard).
C02: Leverage Security Frameworks and Libraries (Utilizar Frameworks e Bibliotecas Seguras)

Descrição:
Aproveitar frameworks e bibliotecas conhecidos e bem mantidos reduz a probabilidade de introduzir vulnerabilidades.

Exemplo:

  • Usar frameworks de ORM como Entity Framework ou Hibernate para interagir com bancos de dados, reduzindo riscos de injeção de SQL.

Boas práticas:

  • Sempre utilize bibliotecas com histórico confiável e suporte ativo.
  • Evite reinventar soluções de segurança, como criar algoritmos de criptografia próprios.
  • Mantenha todas as dependências atualizadas e realize auditorias regulares.
C03: Secure Database Access (Acesso Seguro ao Banco de Dados)

Descrição:
Configurar conexões ao banco de dados de forma segura é fundamental para mitigar ataques, especialmente injeções de SQL.

Exemplo:

  • Um aplicativo de e-commerce utiliza Prepared Statements para consultas, prevenindo ataques de SQL Injection como '; DROP TABLE users;--.

Boas práticas:

  • Use contas de banco de dados com privilégios mínimos.
  • Restrinja conexões ao banco de dados a servidores autorizados.
  • Adote consultas parametrizadas em vez de concatenar strings diretamente.
C04: Encode and Escape Data (Codificar e Escapar Dados)

Descrição:
Proteger dados de saída para evitar que eles sejam interpretados como código por navegadores ou outros sistemas.

Exemplo:

  • Um campo de texto em um fórum permite que um usuário insira <script>alert('XSS')</script>, resultando em um ataque XSS.

Boas práticas:

  • Use funções de escape apropriadas para o contexto (HTML, CSS, SQL, etc.).
  • Evite exibir dados do usuário diretamente sem sanitizá-los.
  • Adote bibliotecas especializadas, como OWASP Java Encoder ou funções nativas do framework usado.
C05: Validate All Inputs (Validar Entradas)

Descrição:
Verificar e sanitizar todos os dados fornecidos pelo usuário para evitar ataques como SQL Injection, XSS e Buffer Overflow.

Exemplo:

  • Um campo de upload de arquivos aceita qualquer tipo de arquivo, permitindo que um atacante envie um script malicioso.

Boas práticas:

  • Valide entradas usando listas de permissões (whitelists).
  • Implemente validações no cliente e no servidor.
  • Restrinja o tamanho e o formato de dados enviados.
C06: Implement Digital Identity (Implementar Identidade Digital)

Descrição:
Configure autenticação e autorização seguras para garantir que apenas usuários autorizados tenham acesso a funcionalidades e dados.

Exemplo:

  • Um aplicativo bancário implementa autenticação multifator (MFA) para operações sensíveis.

Boas práticas:

  • Use bibliotecas confiáveis para gerenciamento de autenticação.
  • Armazene senhas usando algoritmos de hash robustos, como bcrypt ou Argon2.
  • Adote tokens JWT para autenticação baseada em sessões.
C07: Enforce Access Controls (Aplicar Controle de Acesso)

Descrição:
Restrinja o acesso a funcionalidades e recursos com base nos privilégios do usuário.

Exemplo:

  • Em um sistema de gerenciamento, um usuário com privilégios básicos tenta acessar um painel administrativo via URL direta.

Boas práticas:

  • Aplique controle de acesso no servidor, não apenas no cliente.
  • Implemente o princípio do menor privilégio.
  • Realize verificações de permissão para cada requisição.
C08: Protect Data Everywhere (Proteger Dados em Todos os Estados)

Descrição:
Garanta que dados sensíveis estejam protegidos tanto em trânsito quanto em repouso.

Exemplo:

  • Um aplicativo financeiro transmite dados de cartão de crédito sem usar HTTPS, expondo informações em redes públicas.

Boas práticas:

  • Use HTTPS para todas as comunicações.
  • Armazene dados sensíveis criptografados com AES-256.
  • Restrinja o acesso a dados sensíveis apenas a processos e usuários autorizados.
C09: Implement Security Logging and Monitoring (Implementar Logs e Monitoramento de Segurança)

Descrição:
Manter logs detalhados de eventos e monitorar a aplicação para detectar atividades suspeitas.

Exemplo:

  • Um sistema de login registra todas as tentativas de acesso, identificando um ataque de força bruta após várias falhas consecutivas.

Boas práticas:

  • Registre eventos como logins, alterações de dados e erros de autenticação.
  • Proteja logs contra acesso não autorizado.
  • Use ferramentas de análise, como SIEM, para monitoramento contínuo.
C10: Handle All Errors and Exceptions (Tratar Todos os Erros e Exceções)

Descrição:
Fornecer mensagens de erro genéricas para o cliente enquanto registra detalhes técnicos no servidor.

Exemplo:

  • Um site expõe informações de stack trace em mensagens de erro, permitindo que um atacante descubra a estrutura interna da aplicação.

Boas práticas:

  • Configure mensagens de erro genéricas para usuários finais.
  • Registre exceções no back-end com informações detalhadas para análise posterior.
  • Realize testes regulares para garantir que mensagens de erro não exponham informações sensíveis.

Atividade Prática

Para consolidar o aprendizado, foi disponibilizada uma API com vulnerabilidades intencionais. Essa prática ajuda a desenvolver habilidades reais de detecção e mitigação.

Referências

ESTUDO, APPSEC
C2 SHELL REVERSO
Esta postagem está licenciada sob CC BY 4.0 pelo autor.