Modo Debug Controlado pelo Cliente Vaza o Prompt de Sistema Oculto
O desafio
Esta é a requisição que o widget de chat envia ao backend de IA. O cliente pode definir uma flag debug no corpo, e o servidor a respeita - quando debug está ligado, a resposta devolve o prompt de sistema oculto dado ao modelo. Ligue o debug, envie e leia o flag embutido nesse prompt vazado.
O que você vai aprender
- Reconhecer uma falha de divulgação de informações via modo debug em um endpoint de chat de IA
- Identificar uma flag de debug no corpo da requisição que o cliente nunca deveria controlar
- Alterar um campo booleano em uma requisição capturada para revelar o estado oculto do servidor
- Ler a resposta de uma API para extrair um prompt de sistema vazado e o segredo contido nele
- Explicar por que a saída de debug e os prompts de sistema devem ser controlados no servidor e nunca retornados aos clientes
Habilidades testadas
Pré-requisitos
- Entendimento básico de requisições HTTP, corpos JSON e cabeçalhos de autenticação de API
- Familiaridade com a ideia de que um LLM é guiado por um prompt de sistema oculto
Como funciona
Aplicações de modelos de linguagem grandes são guiadas por um prompt de sistema - um bloco de instruções, persona e, às vezes, segredos que o operador fornece ao modelo antes da mensagem do usuário. Esse prompt é configuração do lado do servidor. Ele pode conter nomes internos de ferramentas, regras de política e, como aqui, tokens de build ou integração, então nunca deve ser retornado ao cliente.
Este endpoint trazia um recurso de debug que, quando ativado, anexa o contexto bruto do modelo - incluindo o prompt de sistema - à resposta. O erro é que a flag que o controla fica no corpo da requisição, de modo que qualquer chamador pode definir debug=true e receber o estado interno. O valor é um booleano válido; nada está malformado. A falha é que uma conveniência de desenvolvimento foi ligada a um interruptor controlado pelo cliente e ficou acessível em produção.
Isso é um caso clássico de divulgação de informações através de um caminho de debug esquecido, e é especialmente perigoso para sistemas de IA porque o prompt de sistema vazado revela como manipular o modelo e pode carregar credenciais. A saída de debug deve ser controlada por sinais confiáveis do lado do servidor - uma flag de ambiente, uma rede interna, um papel de operador - nunca por um parâmetro que o chamador pode alternar.
Erros comuns
- Assumir que a flag de debug é meramente cosmética ou somente leitura, quando na verdade o servidor muda sua resposta com base nela.
- Tentar fazer jailbreak no modelo com uma mensagem elaborada em vez de notar o interruptor de debug que entrega o prompt diretamente.
- Enviar um valor não booleano como
1ouone desistir quando o servidor o rejeita - o campo é validado como booleano, então precisa sertrue. - Tratar o vazamento como um mau comportamento do modelo em vez da falha real: o servidor anexou estado interno a uma resposta porque uma flag controlada pelo cliente mandou.
Como se proteger
Nunca deixe o cliente decidir se uma saída de debug ou verbosa interna é retornada, e nunca inclua o prompt de sistema ou outra configuração do lado do servidor em qualquer resposta voltada ao cliente. Proteja qualquer saída de diagnóstico atrás de sinais confiáveis do lado do servidor.
- Controle o comportamento de debug a partir de uma variável de ambiente do servidor ou de um papel de operador autenticado, e ignore qualquer campo
debugenviado pelo cliente. - Remova o contexto interno - prompt de sistema, nome do modelo, definições de ferramentas, tokens - das respostas antes que saiam do servidor.
- Mantenha segredos totalmente fora do prompt de sistema; injete credenciais na camada de ferramentas, onde o modelo nunca as vê.
- Registre e alerte quando uma requisição tentar ativar um modo debug ou verboso, para que a sondagem seja visível.