Pela equipa de Quality Engineering da MTP International · Junho 2026

A maioria dos sistemas comprometidos não falhou porque a sua equipa ignorava que existiam os ataques. Falharam porque ninguém verificou, de forma sistemática, se o sistema era vulnerável a eles antes que um atacante o fizesse primeiro. A diferença entre uma organização que deteta as suas próprias vulnerabilidades e uma que as descobre por um incidente não é de orçamento nem de tecnologia: é de processo.

O México registou mais de 119 milhões de tentativas de ataque bloqueadas, posicionando-se como o segundo país mais atacado na América Latina. Em 2024, estimaram-se 6 milhões de fraudes cibernéticas no país, das quais 7 em cada 10 ocorreram em canais digitais. Estes números descrevem o ambiente em que operam os sistemas de banca, retalho e manufatura no México. A pergunta não é se os ataques ocorrem: é se o seu sistema está preparado para os resistir. The CIU

Porque é que os sistemas parecem seguros mas não o estão?

O problema de segurança mais frequente que encontramos nos diagnósticos da MTP não é a ausência de controlos: é que os controlos existem mas nunca foram verificados sob condições de ataque real. Um sistema pode ter firewall, autenticação e cifragem de dados, e continuar a ser vulnerável a uma injeção SQL num formulário que nenhum engenheiro de segurança reviu porque “aquele campo não é crítico”.

O controlo de acesso quebrado é a vulnerabilidade mais comum em aplicações web, encontrada em 94% das aplicações testadas segundo o OWASP Top 10 2025. Não é uma falha exótica nem um ataque sofisticado: é um erro de configuração no qual um utilizador pode aceder a recursos ou funções que não deveria ver. KENSAI

O OWASP Top 10 — o quadro de referência mais citado na indústria para identificar os riscos críticos em aplicações web — descreve na sua edição de 2025 as dez categorias de vulnerabilidade que explicam a maioria dos incidentes de segurança em produção. Quatro delas são as que com maior frequência encontramos ativas em sistemas de organizações mexicanas que nunca fizeram uma validação de segurança formal.

Os quatro vetores de ataque mais comuns e como se manifestam

Injeções SQL e de comandos

Os ataques de injeção — SQL, NoSQL, comandos de sistema operativo, LDAP — mantêm-se no top 3 do OWASP após duas décadas. Uma injeção SQL ocorre quando um atacante introduz código malicioso num campo de entrada — um formulário de pesquisa, um parâmetro de URL, um campo de login — e o sistema executa-o como se fosse uma instrução legítima de base de dados. KENSAI

O resultado pode ser a leitura de toda a base de dados, a modificação de registos, a eliminação de dados ou a tomada de controlo do servidor. O sinal de alerta mais direto: qualquer campo de entrada que não valide o tipo, formato e comprimento dos dados que recebe, e qualquer consulta à base de dados que construa os seus parâmetros concatenando texto do utilizador diretamente na query.

Phishing e fator humano

O phishing representa cerca de 70% dos ciberataques no México, segundo relatórios de 2024. Os utilizadores clicam numa ligação maliciosa, em média, 21 segundos após abrirem um e-mail de phishing, e em 28 segundos adicionais fornecem as credenciais solicitadas. Isso significa que uma organização tem menos de um minuto desde que se abre um e-mail malicioso até que as credenciais estejam comprometidas. DiputadosThe Network Installers

O phishing não é um ataque ao sistema: é um ataque às pessoas que têm acesso ao sistema. A exposição real não se mede no código da aplicação, mas sim em três fatores: quão fácil é suplantar a identidade da organização, que nível de acesso têm os utilizadores comprometíveis e que controlos adicionais — MFA, monitorização de sessões anómalas, alertas de acesso a partir de localizações invulgares — existem entre o clique e o dano.

Controlo de acesso quebrado

É a categoria número um do OWASP 2025 porque é transversal: afeta quase qualquer aplicação que gira perfis de utilizador com diferentes níveis de privilégio. Os modos de falha mais comuns incluem o acesso direto a recursos por URL sem verificação de autorização, a escalada de privilégios onde um utilizador regular pode executar funções de administrador, e a exposição de IDs previsíveis nas APIs que permitem a um utilizador aceder aos registos de outros.

O sinal de alerta prático: se um utilizador autenticado pode modificar um parâmetro da URL ou do pedido (request) e aceder a dados de outro utilizador, o controlo de acesso está quebrado.

Vulnerabilidades em APIs

94% das organizações reportaram problemas de cibersegurança relacionados com as suas APIs durante 2023 (Salt Security). As APIs são hoje a superfície de ataque mais exposta em aplicações modernas: ligam o frontend ao backend, integram serviços de terceiros e expõem lógica de negócio que em versões anteriores estava encapsulada no servidor. Uma API sem autenticação robusta, sem validação de inputs e sem limites de taxa de pedidos é um vetor de ataque aberto. DeltaProtect

Os cinco sinais de que o seu sistema poderá estar exposto

Sem necessidade de executar um teste formal, estas condições indicam uma exposição provável que requer validação:

Os formulários da aplicação não validam o tipo nem o formato dos dados que recebem. As URLs da aplicação incluem IDs de recursos previsíveis e sequenciais. A aplicação não tem autenticação de dois fatores para perfis com acesso a dados sensíveis. As dependências de terceiros e bibliotecas da stack não são atualizadas com um processo definido. Os logs de acesso não são monitorizados nem geram alertas perante padrões anómalos.

Qualquer uma destas cinco condições, numa organização que processa dados financeiros, pessoais ou regulados, representa um risco ativo que um atacante pode explorar sem ferramentas sofisticadas.

Como validar a exposição de forma sistemática?

A validação de segurança de uma aplicação não é um evento anual: é uma capacidade contínua que opera em três camadas complementares.

A análise estática (SAST) avalia o código-fonte antes de ser executado, identificando padrões que correspondem a vulnerabilidades conhecidas — consultas SQL construídas com concatenação, gestão insegura de credenciais, dependências com CVEs publicados — sem necessidade de implementar a aplicação.

A análise dinâmica (DAST) avalia a aplicação em execução, simulando o comportamento de um atacante externo. Identifica vulnerabilidades que apenas aparecem em tempo de execução: configurações incorretas de cabeçalhos de segurança, exposição de endpoints sem autenticação, comportamento perante inputs maliciosos.

O pentesting simula um ataque real executado por um especialista que tenta explorar as vulnerabilidades identificadas nas duas camadas anteriores. Confirma se são exploráveis no contexto real do sistema e quantifica o impacto potencial de um incidente.

Na MTP integramos as três camadas no pipeline de CI/CD com Omniatest®, a nossa metodologia proprietária de QE, com quality gates que bloqueiam o avanço para produção quando são detetadas descobertas de criticidade alta. A MTP é a primeira empresa certificada TMMi Nível 5 no mundo, o que reforça a rastreabilidade e reprodutibilidade do processo de segurança em cada ciclo de entrega.

Perguntas frequentes

1. O que é o OWASP Top 10 e como o utilizo para avaliar o meu sistema? O OWASP Top 10 é um documento de referência publicado pela Open Web Application Security Project Foundation que lista as dez categorias de vulnerabilidade mais críticas em aplicações web, baseado em dados reais de incidentes e análises da indústria. A sua edição de 2025 cobre controlo de acesso quebrado, falhas criptográficas, injeções, design inseguro, má configuração de segurança, componentes vulneráveis, falhas de autenticação, integridade de software e dados, logging insuficiente e falsificação de pedidos do lado do servidor. Utilizá-lo como lista de verificação numa revisão de arquitetura ou como base para desenhar os cenários de um pentest é o ponto de partida mais prático para organizações que não têm um programa de segurança formal.
2. O phishing é um problema de segurança do software ou das pessoas? É ambos, e essa é exatamente a razão pela qual requer uma resposta em duas camadas. O vetor de entrada é humano — um clique numa ligação maliciosa —, mas o dano real é determinado pelo design do sistema: que acesso tem o utilizador comprometido, se existe MFA que bloqueia o uso de credenciais roubadas, se há monitorização que deteta o acesso anómalo e quanto tempo passa entre o comprometimento e a deteção. Reduzir o impacto do phishing requer tanto formação da equipa como controlos técnicos na aplicação.
3. Com que frequência devo fazer testes de segurança? O mínimo operacional para organizações que lançam software de forma contínua é integrar SAST e DAST como passos automáticos do pipeline de CI/CD, com execução em cada ciclo de integração. O pentesting manual deve ser executado pelo menos uma vez por ano como validação da postura de segurança completa, e sempre antes de alterações arquitetónicas significativas: migração para a nuvem, incorporação de novas APIs, alteração de fornecedor de autenticação.

Sabe se o seu sistema tem vulnerabilidades ativas que um atacante poderia explorar hoje?

O Quick Assessment de Segurança da MTP identifica os vetores de exposição mais críticos em cinco dias úteis, sem custos e com recomendações priorizadas por impacto no negócio.