The latest articles on DEV Community by K (@k_336be9edf3535190b9f89b9). https://dev.to/k_336be9edf3535190b9f89b9 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4025405%2F25c8815d-d5d0-4cab-b7bd-13e64d4d7df3.jpg https://dev.to/k_336be9edf3535190b9f89b9 en K Sat, 11 Jul 2026 17:18:13 +0000 https://dev.to/k_336be9edf3535190b9f89b9/seguranca-nao-e-encontrar-alertas-e-entender-como-um-sistema-pode-ser-quebrado-2l4l https://dev.to/k_336be9edf3535190b9f89b9/seguranca-nao-e-encontrar-alertas-e-entender-como-um-sistema-pode-ser-quebrado-2l4l <p>Existe uma diferença enorme entre executar uma ferramenta de segurança e realizar uma análise de vulnerabilidade de verdade.</p> <p>Scanners são úteis. Eles identificam versões vulneráveis, configurações suspeitas, headers ausentes e padrões conhecidos. Mas as falhas mais relevantes raramente aparecem como um simples alerta vermelho em um dashboard.</p> <p>Vulnerabilidades críticas geralmente surgem da combinação entre componentes que, analisados isoladamente, parecem funcionar corretamente.</p> <p>Um endpoint valida a autenticação.</p> <p>Outro endpoint valida a existência do recurso.</p> <p>O backend confia que o identificador recebido pertence ao usuário autenticado.</p> <p>Cada parte parece segura. A lógica completa, porém, permite que um usuário acesse dados de outra conta.</p> <p>Isso é segurança ofensiva.</p> <p>Não se trata apenas de procurar SQL Injection, XSS ou arquivos expostos. Trata-se de compreender autenticação, autorização, estados internos, fluxos de negócio, relações de confiança e decisões arquiteturais.</p> <p>A superfície de ataque real</p> <p>A superfície de ataque de uma aplicação não é composta somente pelas URLs visíveis.</p> <p>Ela também inclui:</p> <ul> <li>APIs internas consumidas pelo frontend;</li> <li>endpoints antigos ainda ativos;</li> <li>integrações com serviços terceiros;</li> <li>filas, webhooks e workers;</li> <li>parâmetros que controlam estados internos;</li> <li>diferenças entre aplicações web e mobile;</li> <li>mecanismos de importação e exportação;</li> <li>armazenamento de arquivos;</li> <li>painéis administrativos;</li> <li>ambientes de homologação;</li> <li>regras de autorização implementadas apenas no cliente.</li> </ul> <p>Um sistema pode utilizar criptografia moderna, autenticação multifator e uma infraestrutura robusta, mas continuar vulnerável porque uma única operação sensível não verifica corretamente quem pode executá-la.</p> <p>Autenticação não é autorização</p> <p>Essa continua sendo uma das confusões mais perigosas no desenvolvimento de software.</p> <p>Autenticação responde:</p> <p>“Quem é você?”</p> <p>Autorização responde:</p> <p>“Você pode realizar esta ação sobre este recurso?”</p> <p>Estar autenticado não significa estar autorizado a alterar qualquer objeto cuja identificação possa ser enviada ao backend.</p> <p>Considere uma API como:</p> <p>GET /api/documents/9831<br> Authorization: Bearer </p> <p>O servidor pode validar perfeitamente o token e ainda assim retornar um documento pertencente a outro usuário.</p> <p>A autenticação funcionou.</p> <p>A autorização falhou.</p> <p>Esse tipo de problema pode resultar em exposição de dados, alteração de registros, acesso entre organizações, escalada horizontal de privilégios ou comprometimento administrativo.</p> <p>A lógica de negócio é parte da segurança</p> <p>Algumas das falhas mais impactantes não possuem payloads complexos.</p> <p>Elas exploram comportamentos legítimos em uma ordem ou contexto que os desenvolvedores não anteciparam.</p> <p>Exemplos:</p> <ul> <li>reutilizar um cupom que deveria ser utilizado uma única vez;</li> <li>cancelar uma operação depois de receber o benefício;</li> <li>alterar o preço pelo cliente;</li> <li>pular etapas obrigatórias de um fluxo;</li> <li>executar novamente uma ação por meio de condições de corrida;</li> <li>transferir recursos entre contas sem validar propriedade;</li> <li>manipular estados que deveriam ser definidos exclusivamente pelo servidor.</li> </ul> <p>Nenhuma dessas falhas depende necessariamente de malware ou de técnicas extremamente sofisticadas.</p> <p>Elas dependem de uma pergunta simples:</p> <p>“O servidor está impondo todas as regras importantes ou apenas confiando no comportamento esperado do cliente?”</p> <p>O impacto precisa ser demonstrado</p> <p>Um bom relatório de vulnerabilidade não deve apenas afirmar que algo “pode ser explorado”.</p> <p>Ele deve apresentar:</p> <ul> <li>pré-condições;</li> <li>passos reproduzíveis;</li> <li>requisições e respostas relevantes;</li> <li>comportamento esperado;</li> <li>comportamento observado;</li> <li>impacto técnico;</li> <li>impacto para o negócio;</li> <li>causa raiz;</li> <li>recomendação de correção;</li> <li>evidência mínima e não destrutiva.</li> </ul> <p>A qualidade da evidência importa tanto quanto a descoberta.</p> <p>Sem contexto, uma falha pode parecer irrelevante. Sem controle, uma prova de conceito pode ultrapassar limites éticos ou causar impacto desnecessário.</p> <p>O objetivo de uma análise profissional não é causar o maior dano possível.</p> <p>É demonstrar, com segurança e precisão, o dano que seria possível.</p> <p>Segurança precisa existir no backend</p> <p>Qualquer controle implementado exclusivamente no frontend deve ser considerado contornável.</p> <p>Botões podem ser reativados.</p> <p>Campos ocultos podem ser modificados.</p> <p>Requisições podem ser enviadas diretamente.</p> <p>Aplicações mobile podem ser instrumentadas.</p> <p>O cliente está sob controle do usuário. Portanto, decisões críticas precisam ser validadas pelo servidor.</p> <p>O backend deve verificar:</p> <ul> <li>identidade;</li> <li>permissão;</li> <li>propriedade do recurso;</li> <li>estado atual da operação;</li> <li>integridade dos parâmetros;</li> <li>limites de uso;</li> <li>transições permitidas;</li> <li>consistência entre organizações ou tenants.</li> </ul> <p>Uma interface pode orientar o usuário.</p> <p>Somente o servidor pode impor a regra.</p> <p>Segurança não termina quando a falha é corrigida</p> <p>Corrigir apenas o endpoint vulnerável pode não resolver o problema estrutural.</p> <p>Quando uma falha de autorização é encontrada, é necessário investigar:</p> <ul> <li>outros endpoints que utilizam o mesmo padrão;</li> <li>serviços que compartilham a mesma camada de acesso;</li> <li>operações de leitura, alteração e exclusão;</li> <li>implementações semelhantes em versões antigas da API;</li> <li>testes automatizados inexistentes;</li> <li>decisões arquiteturais que permitiram a vulnerabilidade.</li> </ul> <p>Uma vulnerabilidade é frequentemente um sintoma.</p> <p>A causa real pode ser a ausência de um modelo centralizado de autorização, falta de threat modeling, validações inconsistentes ou confiança excessiva no cliente.</p> <p>Segurança ofensiva não é barulho</p> <p>O valor de uma análise não está na quantidade de alertas gerados.</p> <p>Está na capacidade de identificar caminhos reais de ataque, validar impacto e fornecer informações que permitam corrigir o problema de forma definitiva.</p> <p>Ferramentas encontram padrões.</p> <p>Pesquisadores encontram contexto.</p> <p>E contexto é o que transforma um comportamento inesperado em uma vulnerabilidade real.</p> <p>Na A.S.I.A Security, o foco é justamente esse: compreender a aplicação como um sistema completo, identificar falhas exploráveis e produzir evidências técnicas que ajudem equipes a corrigir riscos reais — não apenas aumentar a quantidade de itens em um relatório.</p> <h1> CyberSecurity #AppSec #OffensiveSecurity #BugBounty #VulnerabilityResearch #Pentest #APISecurity #InformationSecurity </h1> webdev programming security