A vulnerabilidade foi detetada durante um teste de segurança realizado pela Sygnia, uma empresa especializada em resposta a incidentes e cibersegurança. O alvo era uma aplicação de onboarding de clientes usada por uma empresa de serviços financeiros que gere milhares de milhões em ativos.
Neste artigo encontras:
Essa plataforma tratava dados altamente sensíveis, incluindo documentos de identificação, informação de verificação de identidade, detalhes de pagamento e outros registos pessoais.
O problema permitia que um candidato acedesse ao registo de outro utilizador.
O erro não estava na falta de proteção
O mais surpreendente é que a aplicação não estava “desprotegida” no sentido tradicional. Pelo contrário.
Segundo a análise, o sistema incluía controlos como tokens temporários, expiração de sessões, limitação de tentativas, registos de auditoria, recuperação de sessão e deteção de atividade suspeita.
Ou seja, a IA gerou vários mecanismos de segurança reais.
O problema é que todos esses controlos estavam montados à volta da decisão errada.
A pergunta que ficou por responder
A aplicação precisava de permitir que um utilizador retomasse um processo iniciado anteriormente, mesmo antes de ter conta e palavra-passe.
Para resolver isso, foi criado um sistema de acesso temporário. A falha surgiu no momento em que o backend decidia quem tinha direito a receber esse token.
Na prática, bastava ter o GUID de um candidato um identificador único do registo para obter ou restaurar um token de acesso dessa pessoa.
Esse identificador passou a funcionar como se fosse um segredo. E esse é precisamente o problema.
Porque é que isto é grave
Um GUID serve para identificar um registo. Não prova, por si só, que quem o apresenta é o verdadeiro titular, que controla o dispositivo, que está na sessão correta ou que passou por um canal de verificação legítimo.
Se alguém obtivesse o GUID de outro candidato, poderia aceder a dados como:
- nome e contactos
- estado da candidatura
- informação financeira
- dados de verificação de identidade
- detalhes de pagamento
- registos de co-candidatos
Num contexto financeiro, isto representa um risco sério para privacidade, conformidade e fraude.
Código com aspeto seguro não é o mesmo que código seguro
Este caso foge à crítica mais comum feita à IA na programação. Não se trata de código mal escrito, desorganizado ou cheio de erros básicos.
A vulnerabilidade era mais profunda: estava na lógica de confiança do sistema.
Por isso, ferramentas tradicionais de análise estática podem não apanhar este tipo de falha. Não era um padrão clássico de programação insegura. Era uma suposição errada sobre autorização e propriedade de acesso.
É precisamente aqui que o uso de IA no desenvolvimento se torna mais delicado.
IA gerou o código e outra IA ajudou a descobrir a falha
Há outro detalhe que torna este caso ainda mais relevante. Segundo a Sygnia, o problema não foi inicialmente encontrado apenas por revisão manual.
A empresa usou um modelo de linguagem para analisar partes do código e procurar falhas relacionadas com fronteiras de confiança e lógica de negócio. Foi esse processo que destacou diretamente o problema do token de candidato.
Em resumo, uma IA ajudou a encontrar a falha criada por código produzido com IA.
Isto mostra duas coisas ao mesmo tempo: estas ferramentas podem acelerar a defesa, mas também podem acelerar a descoberta de vulnerabilidades por atacantes.
Porque é que isto importa agora
A programação assistida por IA está a ganhar espaço nas equipas de produto e engenharia, sobretudo porque aumenta a velocidade de desenvolvimento.
Mas este caso reforça uma ideia simples: rapidez não substitui validação.
Uma aplicação pode compilar, funcionar bem e passar testes básicos, mas continuar vulnerável se a lógica central estiver errada.
Em áreas sensíveis como autenticação, pagamentos, exportação de dados ou tratamento de informação regulada, isso pode ter consequências sérias.
O que as empresas devem fazer com código gerado por IA
A recomendação da Sygnia não passa por proibir estas ferramentas. Bloqueá-las por completo pode apenas empurrar a sua utilização para contas pessoais e fora da visibilidade da empresa.
Em vez disso, a ideia é tratar o código gerado por IA como não fiável até prova em contrário.
Entre as medidas sugeridas estão:
- assinalar pull requests criados ou alterados de forma substancial por IA
- identificar que ferramenta foi usada
- marcar com atenção extra alterações em autenticação, pagamentos e dados regulados
- especificar nos prompts requisitos claros de segurança
- incluir testes negativos para provar que um utilizador não consegue aceder aos dados de outro
Fonte: Thenextweb
Sem Comentários! Seja o Primeiro.