Um aplicativo feito inteiramente por IA vazou 1,5 milhão de registros em 3 dias: 5 coisas para ficar atento e evitar isso

Em janeiro deste ano, uma rede social chamada "Moltbook" foi lançada.

Era uma rede social incomum, onde apenas agentes de IA podiam postar, e foi construída quase inteiramente por IA. Isso é o que se pode chamar de vibe coding.

Em três dias após seu lançamento, um pesquisador de segurança notou algo:

"Qualquer um pode ler e reescrever o conteúdo do banco de dados deste aplicativo."

O que vazou foram cerca de 1,5 milhão de tokens de autenticação, aproximadamente 35.000 endereços de e-mail e milhares de mensagens privadas.

A administração corrigiu o problema imediatamente, mas, até lá, qualquer um podia pegar o que quisesse por vários dias.

Meu trabalho envolve apoiar o desenvolvimento interno de ferramentas de IA e realizar verificações de segurança.

Este incidente, na verdade, apresentou exatamente a mesma vulnerabilidade que vejo com mais frequência em empresas que construíram ferramentas internas usando IA.

Aqui está o que aconteceu e cinco pontos para ficar atento e evitar que isso aconteça com você.

====

O Que Aconteceu

Houve apenas duas causas.

Primeiro. O banco de dados não tinha uma regra que dissesse "você só pode ver seus próprios dados."

Segundo. A chave usada para conectar ao banco de dados foi escrita diretamente no código do lado do navegador.

Qualquer um pode ver uma chave escrita no navegador apenas abrindo as ferramentas do desenvolvedor.

Se você se conectar ao banco de dados com essa chave, todos os dados são retornados porque não há regras restringindo.

Em outras palavras, tudo estava visível pela porta dos fundos, sem sequer passar pela interface do aplicativo.

A IA construiu com sucesso um "aplicativo funcional."

No entanto, ela não construiu a parte de "esconder isso dos outros" porque não foi solicitada.

Esta é a maior armadilha ao construir com IA.

====

1. "Conseguir Fazer Login" e "Não Ver os Dados dos Outros" São Duas Coisas Diferentes

Ao desenvolver um aplicativo, um recurso de login quase sempre está incluído.

As pessoas tendem a pensar: "Adicionei um recurso de login por enquanto, então está tudo bem", mas isso está incorreto.

Fazer login é um recurso para verificar "quem" alguém é.

O que "essa pessoa tem permissão para ver" deve ser construído separadamente.

O Moltbook também tinha um sistema de login.

No entanto, após o login, os usuários podiam acessar os dados de outras pessoas.

A verificação é simples.

Crie duas contas de teste, faça login com a Conta A e tente abrir o URL dos dados da Conta B diretamente.

Se você conseguir ver, está exposto.

Aqui está o prompt para a IA:

"Certifique-se de que os usuários só possam acessar seus próprios dados. Garanta que, mesmo se abrirem o URL dos dados de outra pessoa, não consigam vê-los."

====

2. Coloque uma Regra "Ver Apenas o Próprio Compartilhamento" Também no Lado do Banco de Dados

O primeiro ponto era sobre o lado do aplicativo.

No entanto, como no Moltbook, alguém pode se conectar diretamente ao banco de dados pela porta dos fundos sem passar pelo aplicativo.

Portanto, você deve colocar uma regra no próprio banco de dados que diga "esta pessoa só pode ver esta linha."

Com isso em vigor, mesmo que a chave vaze, os dados de outras pessoas não podem ser recuperados.

Os serviços de banco de dados frequentemente usados no desenvolvimento recente de IA têm esse recurso.

No entanto, ele geralmente está desligado por padrão. A IA não o ativará a menos que seja solicitada.

Aqui está o prompt:

"Ative uma regra em todas as tabelas do banco de dados para que os usuários só possam ler suas próprias linhas."

====

3. Não Coloque Chaves no Lado do Navegador

A outra causa do Moltbook foi que a chave estava escrita no navegador.

Um aplicativo tem "código que roda no lado do servidor" e "código que roda no lado do navegador."

O lado do navegador é enviado inteiramente para o PC do usuário. Em outras palavras, escrever uma chave lá é o mesmo que distribuí-la para todos.

Como verificar: Abra as ferramentas do desenvolvedor e pesquise por "key", "token" ou "secret".

Se uma string longa que se pareça com uma delas aparecer, você precisa ter cuidado.

Aqui está o prompt:

"Mantenha chaves e senhas estritamente no lado do servidor. Nunca as inclua no código do lado do navegador."

====

4. Tenha uma "IA Diferente" Fazendo o Papel de Vilão Antes do Lançamento

Se você perguntar à IA que o construiu: "É seguro?", ela dirá "Sim." Porque ela mesma o construiu.

Portanto, você deve ter uma IA diferente daquela usada no desenvolvimento revisando-o da perspectiva de um atacante.

Pergunte a ela: "Se você fosse invadir este aplicativo, por onde entraria?"

Quando faço isso com as ferramentas dos clientes, vulnerabilidades que eles não notaram aparecem em abundância.

As duas vulnerabilidades no Moltbook estão em um nível que normalmente seria encontrado com essa pergunta.

Aqui está o prompt:

"Você é um atacante. Liste todas as maneiras de visualizar os dados de outras pessoas neste aplicativo. Se encontrar alguma, forneça também as correções."

====

5. Após o Lançamento, Registre "Quem Viu o Quê" e Verifique Diariamente na Primeira Semana

O Moltbook foi corrigido porque um pesquisador externo o encontrou e entrou em contato.

Eles não tinham notado por conta própria.

Com ferramentas internas, ninguém vai entrar em contato com você.

Portanto, mantenha um registro de "quem fez login quando e quais dados visualizou."

Em seguida, verifique esse registro todos os dias durante a primeira semana após o lançamento.

Uma fonte de acesso desconhecida, acesso massivo no meio da noite ou uma pessoa abrindo os dados de todos.

Você pode perceber essas coisas imediatamente olhando os registros.

Aqui está o prompt:

"Mantenha um registro de quem acessou quais dados e quando. No entanto, não escreva senhas ou informações pessoais nos registros."

====

Resumo

Para resumir o incidente do Moltbook em uma linha:

"A IA constrói o que é solicitado a construir, mas não constrói o que não é solicitado a construir."

Ao criar ferramentas internas, comunicamos "quero este tipo de recurso."

Mas não dizemos "Não mostre para os outros" ou "Não coloque a chave no navegador."

Porque não dizemos, isso não é incluído.

Por outro lado, todas essas cinco coisas podem ser incluídas apenas adicionando uma única frase à IA.

Primeiro, tente criar duas contas de teste com uma ferramenta que você tem atualmente em execução e abra o URL dos dados de outra pessoa.

Só de fazer isso, você saberá se tem a mesma vulnerabilidade do Moltbook.

====

Finalmente, um anúncio.

Nossa empresa oferece um serviço para desenvolver agentes de IA específicos para tarefas para sua empresa do zero.

Em vez de treinamento ou introdução de ferramentas, entrevistamos você sobre seu fluxo de trabalho real de negócios e entregamos algo "utilizável a partir de amanhã" como está. Oferecemos suporte consistente até a melhoria pós-introdução e desenvolvimento interno.

Também oferecemos um serviço onde engenheiros acompanham você para verificar a segurança e a operação das ferramentas internas de IA, bem como lidar com a manutenção e modificações subsequentes. Uma característica chave é que não terminamos apenas após a construção, mas estabelecemos um "sistema de proteção contínua" sob as perspectivas dos cinco pontos deste artigo.

Se você é um empresário ou gerente que pensa: "Nossa ferramenta pode mostrar dados se alguém abrir o URL de outra pessoa", por favor, deixe-nos conversar com você.

A consulta inicial é gratuita, e podemos mostrar uma demonstração da verificação da perspectiva do atacante introduzida neste artigo na hora. Como podemos começar organizando onde seu sistema está vulnerável juntos, sinta-se à vontade para nos contatar via DM ou LINE.

Apenas dizer "IA" está perfeitamente bem↓

LINE: https://line-harness.r-yagi.workers.dev/r/x