Cibersegurança

Além do login: outros riscos de segurança em aplicações criadas com IA

Descubra as principais vulnerabilidades em aplicações criadas com inteligência artificial e como reduzir riscos com práticas recomendadas pela OWASP.

Evandro Gayer Gomes
Evandro Gayer Gomes
Pessoa trabalhando em um laptop com uma interface de segurança de aplicações em um ambiente de escritório moderno iluminado em tons de azul.

Introdução

No primeiro artigo desta série, vimos que uma tela de login representa apenas a parte mais visível da segurança de uma aplicação. Autenticação e sessão determinam quem entra e como o acesso continua válido. Já os cookies (pequenos dados armazenados pelo navegador) e a autorização influenciam como esse acesso é mantido e quais ações cada pessoa pode realizar.

Esses controles são fundamentais, mas não cobrem todos os riscos. Uma aplicação também recebe conteúdo externo e se comunica com outros sistemas. Ela ainda processa arquivos e depende de componentes criados por terceiros. Além disso, precisa limitar o consumo de recursos e registrar comportamentos anormais para que um incidente seja percebido a tempo.

O risco aumenta quando uma solução criada rapidamente com inteligência artificial generativa deixa de ser um protótipo e passa a lidar com dados de clientes ou operações financeiras. O Cost of a Data Breach Report 2025 (relatório sobre o custo de uma violação de dados em 2025), da IBM, estimou o custo médio global de uma violação de dados em USD 4,4 milhões. Entre as organizações que relataram incidentes relacionados à inteligência artificial, 97% não possuíam controles adequados de acesso a esses sistemas.

Neste artigo, vamos ampliar a análise para outros pontos de exposição. O objetivo é explicar vulnerabilidades recorrentes, mostrar por que elas também aparecem em aplicações criadas com inteligência artificial e apresentar medidas práticas para reduzir cada risco.

O que é a OWASP e por que ela é importante?

A OWASP é uma fundação sem fins lucrativos e uma comunidade aberta dedicada à segurança de software. A sigla corresponde a Open Worldwide Application Security Project (Projeto Mundial Aberto de Segurança de Aplicações). Seus projetos incluem padrões e guias mantidos com a colaboração de profissionais de diferentes partes do mundo.

Uma de suas publicações mais conhecidas é o OWASP Top 10 (dez principais riscos de segurança para aplicações web). O documento reúne categorias consideradas especialmente importantes para conscientização e revisão de aplicações. Ele não substitui uma análise completa, mas oferece um ponto de partida reconhecido para identificar problemas recorrentes.

A OWASP também mantém a Cheat Sheet Series (série de guias práticos), com recomendações mais específicas sobre prevenção e implementação. Neste artigo, usaremos o OWASP Top 10:2025, o OWASP API Security Top 10:2023 e esses guias como referências principais.

Os riscos abordados serão:

  • injeção de comandos e Cross-Site Scripting (injeção de scripts entre sites), ou XSS;
  • Cross-Site Request Forgery (falsificação de requisição entre sites), ou CSRF;
  • Server-Side Request Forgery (falsificação de requisição do lado do servidor), ou SSRF;
  • envio e processamento inseguro de arquivos;
  • exposição de chaves, senhas e outras credenciais;
  • falhas na cadeia de suprimentos de software;
  • consumo irrestrito de recursos;
  • falhas no registro de eventos e na geração de alertas.

Essas categorias não abrangem todos os riscos possíveis. Elas formam um recorte prático de problemas que podem permanecer ocultos mesmo quando o login e as permissões básicas já parecem funcionar.

Quando dados se transformam em comandos

Informações enviadas por um usuário deveriam ser tratadas apenas como dados. Uma falha de injeção aparece quando parte desse conteúdo é interpretada como uma instrução por um componente interno, como o banco de dados.

Imagine um campo de busca cujo texto seja inserido diretamente em uma consulta. Se a aplicação não separar corretamente o valor informado da estrutura do comando, uma entrada manipulada pode alterar o comportamento esperado da consulta.

A categoria Injection (injeção), da OWASP Top 10:2025, também inclui o XSS. Nesse caso, conteúdo externo é inserido em uma página de modo que o navegador o execute como código. Isso pode permitir o acesso indevido a informações da sessão ou a alteração do conteúdo exibido ao usuário.

Aplicações geradas rapidamente podem ser vulneráveis quando o código mistura dados com comandos ou desativa proteções oferecidas pelo framework utilizado. Uma interface visualmente correta não demonstra que o conteúdo dinâmico está sendo tratado de forma segura.

Como reduzir o risco

Consultas e comandos devem utilizar interfaces parametrizadas, que mantêm os valores externos separados da instrução executada. A validação de entrada continua importante, mas não deve ser a única defesa.

Para prevenir XSS, a aplicação deve preservar a codificação automática oferecida pela estrutura de desenvolvimento e sanitizar conteúdo quando a exibição de HTML for realmente necessária. O guia de prevenção de XSS da OWASP reforça que nenhuma técnica isolada resolve o problema.

A Content Security Policy (política de segurança de conteúdo), conhecida pela sigla CSP, pode limitar o impacto de alguns ataques. Ela funciona como proteção adicional, não como substituta do tratamento correto do conteúdo.

Na revisão, é necessário localizar onde dados externos entram na aplicação e acompanhar como eles são usados até a consulta, o comando ou a página final.

Quando o navegador age em nome do usuário sem que ele perceba

Depois que uma pessoa entra em uma aplicação, o navegador pode enviar automaticamente o cookie que mantém a sessão ativa. O CSRF explora esse comportamento para fazer o navegador executar uma ação que o usuário não pretendia realizar.

Por exemplo, uma página maliciosa pode tentar enviar uma solicitação para alterar o e-mail de uma conta já autenticada. O atacante não precisa conhecer a senha, porque o navegador da vítima apresenta a sessão válida ao sistema.

Esse risco afeta principalmente operações que alteram dados. Confirmar apenas a existência da sessão não demonstra que a solicitação partiu do fluxo legítimo da aplicação.

Como reduzir o risco

O primeiro passo é utilizar a proteção contra CSRF já oferecida pela estrutura de desenvolvimento. Quando ela não existe, operações que modificam informações devem receber e validar um código de proteção específico no servidor.

O guia de prevenção de CSRF da OWASP também recomenda validar a origem das solicitações e configurar o atributo SameSite dos cookies. Operações sensíveis podem exigir uma confirmação adicional do usuário.

Solicitações que alteram o estado do sistema não devem ser implementadas como simples acessos de leitura. Na revisão, cada operação relevante precisa demonstrar que a requisição veio do fluxo esperado, não apenas de um navegador com uma sessão aberta.

Quando a aplicação se torna uma ponte para destinos restritos

O risco anterior explora a confiança depositada no navegador. O SSRF explora a confiança e o alcance de rede do próprio servidor.

Essa falha acontece quando a aplicação aceita um endereço informado externamente e faz uma requisição sem controlar adequadamente o destino. Uma função que importa uma imagem a partir de uma URL, por exemplo, pode ser manipulada para tentar acessar um serviço interno.

O atacante usa a aplicação como intermediária porque o servidor pode alcançar recursos que não estão disponíveis diretamente pela internet. Em ambientes de nuvem, isso também pode expor informações da própria infraestrutura.

Como reduzir o risco

Quando os destinos legítimos são conhecidos, a aplicação deve manter uma lista explícita de domínios ou serviços permitidos. O endereço precisa ser validado depois de sua resolução, incluindo possíveis redirecionamentos.

O guia de prevenção de SSRF da OWASP recomenda combinar controles na aplicação com restrições de rede. O servidor deve conseguir se comunicar somente com os sistemas necessários para sua função.

Também é importante limitar os protocolos aceitos e bloquear o acesso a endereços internos quando eles não fazem parte do fluxo esperado. Na revisão, toda função que busca conteúdo externo deve ter destinos e comportamentos claramente definidos.

Quando um arquivo enviado se torna uma entrada perigosa

Um arquivo não deve ser considerado seguro apenas porque possui a extensão esperada. O conteúdo pode explorar a ferramenta usada no processamento ou consumir recursos em excesso.

O caso conhecido como ImageTragick mostrou como uma imagem especialmente preparada podia provocar a execução de comandos em versões vulneráveis do ImageMagick. O problema foi registrado como CVE-2016-3714 no National Vulnerability Database (Banco de Dados Nacional de Vulnerabilidades dos Estados Unidos), conhecido pela sigla NVD.

O risco cresce quando a aplicação realiza processamento adicional, como reconhecimento óptico de caracteres ou conversão de documentos. Nessa situação, o arquivo atravessa outras bibliotecas antes de produzir o resultado esperado.

Como reduzir o risco

A aplicação deve aceitar somente os formatos necessários para a função de negócio e verificar o conteúdo real do arquivo. Também precisa definir um limite de tamanho antes de iniciar o processamento.

O guia de segurança para envio de arquivos da OWASP recomenda gerar nomes internos e armazenar os arquivos fora da área pública da aplicação. O processo responsável pela leitura deve ter apenas as permissões necessárias.

Quando o nível de risco justificar essa medida, o processamento pode ocorrer em um ambiente isolado e incluir análise de conteúdo malicioso. Na revisão, o arquivo precisa ser acompanhado desde o recebimento até o armazenamento e a transformação final.

Quando credenciais ficam expostas no código

Chaves de API, senhas e tokens (credenciais digitais) permitem que uma aplicação acesse outros sistemas. Quando uma dessas informações é inserida diretamente no código, ela pode oferecer um caminho imediato para recursos sensíveis.

Esse risco não desaparece necessariamente quando a credencial é removida da versão atual. A documentação do GitHub sobre vazamento de segredos explica que uma credencial ainda pode permanecer no histórico do repositório ou em registros de automação.

Assistentes de inteligência artificial podem sugerir a inclusão direta de uma chave para testar uma integração. O atalho se torna perigoso quando a credencial permanece ativa depois que o protótipo começa a evoluir.

Como reduzir o risco

Credenciais devem ser armazenadas em uma solução de secrets management (gestão de segredos), separada do código. Cada aplicação deve receber apenas o acesso necessário para executar sua função.

Sempre que possível, os segredos devem ter validade curta e rotação automatizada. Também é importante impedir que eles apareçam em registros e utilizar ferramentas que detectem credenciais adicionadas ao repositório.

Uma credencial exposta deve ser considerada comprometida. Remover o texto do arquivo não basta: é necessário revogar o valor antigo, criar outro e verificar se houve uso indevido.

Quando uma dependência compromete a aplicação

Quase toda aplicação moderna utiliza bibliotecas criadas por terceiros. A software supply chain (cadeia de suprimentos de software) acelera o desenvolvimento, mas também faz com que a segurança do produto dependa de componentes externos.

A OWASP Top 10:2025 inclui falhas nessa cadeia entre os principais riscos para aplicações web. O problema pode surgir quando um componente possui uma vulnerabilidade conhecida ou quando o processo de distribuição é comprometido.

A geração de código acrescentou uma variação específica. O estudo We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (Temos um pacote para você: uma análise abrangente de alucinações de pacotes por modelos de geração de código), publicado no 34º USENIX Security Symposium em 2025, analisou 576 mil amostras produzidas por 16 modelos e encontrou recomendações de pacotes inexistentes.

Esse fenômeno é chamado de package hallucination (alucinação de pacote). Um agente malicioso pode registrar um nome inventado em um repositório público e esperar que alguém instale o pacote sem confirmar sua origem.

Como reduzir o risco

Toda dependência sugerida por inteligência artificial deve ser confirmada na documentação oficial do projeto. Antes da instalação, é preciso verificar quem mantém o pacote e se ele continua recebendo atualizações.

As versões utilizadas devem ser registradas de forma reproduzível e verificadas continuamente contra bases de vulnerabilidades. A OWASP também recomenda manter um inventário dos componentes e remover dependências que não possuem uma função necessária.

Atualizações não devem entrar automaticamente em sistemas importantes sem testes. Na revisão, cada componente externo precisa ter origem e versão confirmadas. Também deve existir um processo de acompanhamento durante toda a vida da aplicação.

Quando ninguém define limites de consumo

Uma aplicação pode sofrer abuso mesmo quando não há acesso indevido a dados. Basta permitir que uma operação legítima seja repetida sem limites adequados.

Esse cuidado é especialmente importante quando uma solicitação aciona um serviço cobrado por uso, como um modelo de inteligência artificial. Uma chamada individual pode custar pouco, mas a repetição automatizada pode gerar uma despesa relevante antes que alguém perceba.

O OWASP API Security Top 10:2023 descreve esse problema como Unrestricted Resource Consumption (consumo irrestrito de recursos). Além do custo financeiro, o abuso pode esgotar a capacidade do sistema e causar indisponibilidade.

Como reduzir o risco

A aplicação deve limitar quantas solicitações cada usuário pode realizar em determinado período. Também precisa restringir o tamanho das entradas e a quantidade de dados retornada por operação.

Processamentos demorados devem ter tempo máximo de execução e limites próprios de memória. Para serviços externos, a empresa deve configurar tetos de gasto ou alertas de orçamento.

Esses valores precisam refletir o uso legítimo do produto. Na revisão, toda operação com custo ou consumo relevante deve ter um limite mensurável e uma resposta definida para quando ele for atingido.

Quando o incidente acontece e ninguém percebe

Mesmo uma aplicação bem revisada pode enfrentar erros ou tentativas de abuso. A diferença está na capacidade de perceber o comportamento anormal e iniciar uma resposta antes que o impacto aumente.

A categoria Security Logging and Alerting Failures (falhas no registro de segurança e nos alertas), da OWASP Top 10:2025, trata de situações em que eventos importantes não são registrados ou não geram uma ação adequada.

O relatório de 2025 da IBM atribuiu parte da redução do custo médio global de violações à identificação e contenção mais rápidas. Registros bem planejados ajudam a reconstruir o ocorrido, mas apenas quando são acompanhados por alertas e um processo de resposta.

Como reduzir o risco

A aplicação deve registrar falhas de autenticação e operações sensíveis com contexto suficiente para investigação. Os registros precisam ser protegidos contra alterações e mantidos pelo período necessário.

O guia de registro de eventos da OWASP alerta que senhas e credenciais de acesso não devem ser armazenadas nos registros. O registro de dados pessoais também deve ser limitado ao necessário, e essas informações precisam receber proteção adequada.

A empresa deve definir quais comportamentos geram alertas e quem será responsável por avaliá-los. Esse fluxo precisa ser testado, porque um alerta que ninguém recebe ou compreende não melhora a capacidade de resposta.

Uma revisão mínima antes do uso real

Os riscos apresentados podem ser convertidos em perguntas práticas:

  1. Os dados externos permanecem separados dos comandos executados pela aplicação?
  2. As operações autenticadas possuem proteção contra solicitações forjadas?
  3. As integrações conseguem acessar somente os destinos necessários?
  4. Os arquivos são validados, limitados e processados em condições seguras?
  5. As credenciais permanecem fora do código e podem ser revogadas rapidamente?
  6. As dependências possuem origem confirmada e acompanhamento de vulnerabilidades?
  7. As operações possuem limites de volume e custo?
  8. Eventos suspeitos geram registros, alertas e uma resposta definida?

Essa lista não substitui uma análise técnica. O rigor necessário depende dos dados envolvidos e das consequências de uma falha.

Uma ferramenta local sem informações reais pode passar por um processo mais simples. Uma aplicação que atende clientes ou executa operações críticas precisa de arquitetura, testes e acompanhamento compatíveis com essa responsabilidade.

Desenvolvedores experientes continuam importantes porque transformam recomendações gerais em decisões adequadas ao contexto. Eles identificam caminhos de abuso, escolhem controles proporcionais e verificam se as proteções continuam funcionando conforme a aplicação evolui.

Conclusão

O login resolve apenas uma parte da segurança. Mesmo depois de controlar identidade e permissões, a aplicação ainda precisa tratar conteúdo externo com desconfiança, limitar sua comunicação com outros sistemas e proteger os componentes dos quais depende.

Também precisa controlar o consumo de recursos e manter visibilidade sobre comportamentos anormais. Sem essas camadas, um sistema pode funcionar corretamente durante a demonstração e continuar vulnerável quando entra em uso real.

A inteligência artificial generativa reduz o tempo necessário para transformar uma ideia em software funcional. Essa vantagem torna ainda mais importante a revisão baseada no contexto do negócio e nas consequências de uma falha.

Quando uma aplicação começa a afetar clientes ou operações importantes, segurança deixa de ser uma melhoria posterior e passa a fazer parte do próprio produto.

Fontes

Leia Mais

Link copiado