Não transforme um app de desktop em scanner da sua rede interna: proteção contra SSRF para agentes de IA

O essencial

• Se um assistente de IA pode pedir a um app de desktop para buscar um link, uma instrução maliciosa pode apontá-lo para o seu roteador, para um serviço local ou para um endereço de metadados de nuvem, em vez de um vídeo.
• O mesmo endereço pode ser escrito de muitas formas: 127.1, 2130706433, 0x7f000001 e [::ffff:127.0.0.1] levam todos a este computador. O KwaFlux interpreta os nomes de host como os navegadores fazem, então cada grafia é verificada como o endereço que ela de fato é.
• Quando um download está prestes a começar, o KwaFlux também resolve o nome do host e o recusa se ele apontar para este computador ou para uma rede privada, sem bloquear a faixa de endereços que ferramentas de proxy usam no modo fake-IP.
• Redirecionamentos durante um download e DNS rebinding ainda não estão cobertos. Dizemos isso com clareza, e os dois estão no nosso roadmap.

Quando um assistente de IA pede ao KwaFlux para baixar um link, quem se conecta é o motor de download do KwaFlux. Esse motor roda no seu computador, dentro da sua rede. Se o link apontar para http://192.168.1.1/ em vez de uma página de vídeo, um app descuidado se conectaria ao seu roteador sem hesitar, a pedido do assistente.

O KwaFlux impede que os links enviados por um assistente cheguem a este computador e a redes privadas. Veja como isso funciona e onde essa proteção termina.

Neste guia, você vai ver o que SSRF significa para um app de desktop, por que listas de bloqueio falham diante de grafias alternativas de um endereço, como o KwaFlux verifica tanto o host escrito quanto o resolvido e quais casos ainda estão em aberto.

Conteúdo

1. O que é SSRF?
2. Por que um app de desktop operado por IA fica exposto
3. Um endereço, muitas grafias
4. Camada 1: interpretar o host como um navegador
5. Camada 2: verificar para onde o nome resolve
6. A exceção do fake-IP
7. Onde a proteção termina
8. Perguntas frequentes

O que é SSRF?

Server-side request forgery (SSRF, falsificação de requisição do lado do servidor) é um ataque em que alguém faz um programa enviar uma requisição a um destino escolhido pelo atacante, em geral um que ele não consegue alcançar diretamente, como um serviço na mesma máquina ou uma rede interna.

O nome vem dos servidores web, mas o padrão vale para qualquer programa que busca URLs a pedido de outra pessoa. As orientações de segurança do MCP listam os alvos habituais: IPs internos como http://192.168.1.1/admin, endpoints de metadados de nuvem em http://169.254.169.254/ e serviços em localhost como http://localhost:6379/.

Por que um app de desktop operado por IA fica exposto

Três coisas se somam:

1. O app busca URLs. O recurso de Download de arquivo do KwaFlux se conecta a qualquer link que receber.
2. O app fica dentro da sua rede. A partir do seu computador, 192.168.x.x é o seu roteador, NAS ou impressora, e 127.0.0.1 é cada serviço que você roda localmente.
3. O link pode vir de um texto que o modelo leu. A descrição de um vídeo ou uma página da web pode dizer ao assistente para “verificar este link primeiro”. Para entender como isso acontece, veja injeção de prompt em títulos de vídeos da web.

Um motor de download que busca um endereço interno pode não mostrar a resposta a ninguém, mas até uma mensagem de erro pode dizer a um atacante se existe um dispositivo naquele endereço. É isso que queremos dizer com transformar um app de desktop em um scanner da sua rede interna.

Um endereço, muitas grafias

Bloquear 127.0.0.1 e localhost por comparação de strings não basta. Os parsers de URL aceitam muitas outras formas de escrever o mesmo endereço. Veja o que o parser de URL WHATWG do Node.js 20 faz com algumas delas:

Todas as linhas, menos as duas últimas, levam a este computador. 10.0.0.1 é um endereço privado, e 169.254.169.254 é o endereço link-local que as plataformas de nuvem usam para os metadados da instância.

O URL Standard do WHATWG explica o motivo: uma parte que começa com 0x é lida em base 16, uma parte que começa com 0, em base 8, e um endereço com menos de quatro partes deixa a última parte preencher os bytes restantes. O guia de prevenção de SSRF da OWASP alerta para as mesmas codificações “Hex, Octal, Dword”, e as orientações de segurança do MCP acrescentam: “Evite implementar a validação de IP manualmente. Os atacantes exploram truques de codificação (octal, hexadecimal, IPv6 mapeado para IPv4) que parsers personalizados muitas vezes deixam passar.”

Camada 1: interpretar o host como um navegador

O KwaFlux não compara strings. Ele interpreta o host com as mesmas regras que os navegadores usam e verifica o resultado:

• A interpretação de host do WHATWG transforma formas abreviadas, partes em octal e hexadecimal, endereços de um número só e um ponto no final no endereço real antes de qualquer verificação.
• O IPv6 é verificado nos 16 bytes, então uma forma IPv6 mapeada para IPv4, como [::ffff:7f00:1], é reconhecida como loopback, e não tratada como um endereço IPv6 desconhecido qualquer.
• **Hosts que contêm % são recusados.** Isso descarta zone IDs de IPv6 e truques de codificação por porcentagem no host.
• Endereços de loopback, privados e link-local são recusados, como 127.0.0.0/8, ::1, 10.0.0.0/8, 192.168.0.0/16 e 169.254.0.0/16.

Isso segue a recomendação da OWASP de “usar o valor de saída do método/biblioteca como endereço IP” na verificação, em vez do texto que o usuário digitou.

Camada 2: verificar para onde o nome resolve

Um nome de host pode parecer inofensivo e, mesmo assim, apontar para dentro da sua rede. router.example.net pode ter um registro DNS que diz 192.168.1.1.

Por isso, quando um download com login está prestes a entrar na fila, o KwaFlux também resolve o nome do host, com um tempo limite de 2 segundos. Se o nome resolver para este computador ou para uma rede privada, o download é recusado.

É essa verificação que pega nomes de host públicos cujos registros DNS apontam para 127.0.0.1 ou para um endereço privado.

A exceção do fake-IP

Algumas ferramentas de proxy funcionam em um modo “fake-IP”: respondem a cada consulta DNS com um endereço de 198.18.0.0/15 e encaminham a conexão real por conta própria. O registro da IANA lista essa faixa como “Benchmarking” (RFC 2544), não como uma faixa privada ou de loopback.

Se o KwaFlux tratasse essa faixa como interna, todos os downloads em um computador que usa um proxy desses falhariam. Por isso, ela fica de fora da verificação do endereço resolvido.

Onde a proteção termina

Queremos ser exatos aqui, porque é fácil vender a proteção contra SSRF como mais do que ela é.

• O que está coberto: o link que o assistente envia. São verificados tanto o host como está escrito quanto o endereço para o qual o nome dele resolve.
• O que ainda não está coberto: o que acontece durante o download. Um link pode resolver para um endereço público na hora da verificação e para um privado instantes depois (DNS rebinding), ou uma página pública pode redirecionar para um endereço interno. As orientações de segurança do MCP chamam o primeiro caso de problema de time-of-check to time-of-use (entre o momento da verificação e o momento do uso), e a OWASP observa que “uma segunda consulta DNS, sem verificação, entre a validação e a conexão pode contornar essas verificações”.

A solução de fundo é fazer as conexões do motor de download passarem por um componente que verifique cada conexão, incluindo cada redirecionamento, no momento em que ela é feita. Isso está no nosso roadmap. Ainda não fizemos porque isso muda a forma como o motor de download acessa a rede em três bases de código separadas e afeta todos os downloads, inclusive os que você mesmo inicia, então precisa de uma versão e de testes próprios.

Então, a afirmação correta é esta: o KwaFlux impede que um assistente de IA o direcione a endereços neste computador e em redes privadas. Ele não promete que nenhuma conexão possa, em hipótese alguma, acabar indo parar lá, e não o descrevemos como “só internet pública”.

Dois outros limites ajudam enquanto isso. Os downloads por agentes vêm desativados, e, no modo que pede confirmação a cada download, você vê o link antes de qualquer coisa ser buscada. Veja por que uma IA não pode aprovar downloads por você.

Conclusão

Verifique o endereço, não a grafia. Interprete os hosts como os navegadores fazem, verifique para onde o nome resolve antes de um download começar, deixe em paz as faixas de fake-IP dos proxies e seja claro sobre o que ainda está em aberto. É assim que o KwaFlux evita que os links de um assistente o transformem em um scanner da sua rede.

Deixe o seu assistente buscar só o que deve

O servidor MCP local do KwaFlux permite que Codex, Claude, Cursor e outros apps MCP trabalhem com os seus arquivos, e verifica cada link que um assistente envia. O processamento de IA roda na sua própria GPU e os seus arquivos de mídia não são enviados para processamento. Roda no Windows 10 (64 bits, versão 1809 ou mais recente), no Windows 11 e no macOS 12 ou mais recente em Apple Silicon. Importar arquivos e explorar o app não exigem conta. O login com um plano pago só é necessário para exportar, converter, reparar um arquivo ou baixar um arquivo de um link.

Baixar o KwaFlux · Ver planos