A Ilusão da Segurança: Como Aprendi a Contornar Filas Virtuais (e Por Que a Proteção do Lado do Cliente é um Teatro)

Como é engraçado, com o avanço do progresso, ganhamos um pouco daquela velha União Soviética na internet – estou falando de filas virtuais. É verdade que ficar em uma fila na internet não é tão cansativo quanto na vida real, mas também não é muito agradável.

Aqui, você não pode pedir a um vendedor conhecido para deixá-lo entrar ou até mesmo entrar pelos fundos e pegar o item desejado antes de todo mundo... Ou pode?

Encontrei um artigo interessante na internet sobre como hackear filas virtuais – aqui está uma tradução ligeiramente adaptada.

A Faísca

Eu estava tentando comprar um disco de vinil de edição limitada da minha banda favorita. Eles anunciaram um lançamento surpresa – 2.000 cópias em todo o mundo, numeradas à mão, sem possibilidade de reimpressão.

Eu era fã deles há onze anos. E até tatuei suas letras no meu antebraço.

O início das vendas estava marcado para as 15h. Tirei meio dia de folga do trabalho. Configurei três alarmes. Abri e preparei a página com antecedência, 15 minutos antes.

Chega 15:00:00. Eu clico.

"Por favor, espere. Você foi colocado na fila. Tempo estimado de espera: 52 minutos."

Tudo dentro de mim se contraiu. Eu observei os números derreterem. 48 minutos. 39 minutos. 22 minutos. Comecei a ter esperança. Mas o resultado foi lamentável:

"Desculpe, este item está esgotado."

Fiquei sentado atordoado por muito tempo. Algo dentro de mim quebrou naquele dia. Não houve drama – eu não virei mesas nem jurei vingança contra o universo. Apenas um vazio que preencheu tudo por dentro.

E então eu pensei:

Como isso realmente funciona?

E pela primeira vez na vida, abri as ferramentas de desenvolvedor no navegador.

Aprendendo a Ver

O primeiro mês foi um golpe no meu ego.

Eu não entendia o que era uma requisição de rede. Eu não entendia como os cookies funcionavam. Nunca tinha ouvido falar de endpoints de API. O console do desenvolvedor me parecia uma coleção de hieróglifos chineses para os escolhidos.

Mas eu sou teimoso. Patologicamente teimoso. Comecei com vídeos tutoriais no YouTube. Então passei para a documentação. Então – para fóruns onde as pessoas discutiam parsing e automação. Lentamente, dolorosamente, mas a névoa da incompreensão estava se dissipando.

Eu aprendi que os sites não são monolíticos. São conjuntos de serviços que se comunicam entre si. O frontend fala com o backend. O backend fala com o banco de dados. O middleware fica entre eles e toma decisões.

As filas são esse middleware. Elas interceptam sua requisição antes que ela chegue ao site em si e decidem se você pode passar. Caso contrário, em vez de conteúdo real, elas o redirecionam para uma sala de espera.

Mas o que me interessou foi: as filas não veem o quadro completo. Elas veem apenas o que estão configuradas para ver. E a configuração é feita por pessoas. Pessoas que cometem erros. Pessoas que se esquecem de exceções. Pessoas que fazem deploy na noite de sexta-feira e perdem alguma coisa.

Primeira Vitória

No segundo mês de estudo de parsing e automação, uma marca de streetwear anunciou uma colaboração de edição limitada. Era uma daquelas coisas que se esgotam em segundos e depois aparecem em plataformas de revenda cinco vezes mais caras.

Eu entendi que eles usariam uma fila virtual. Naquela época, todo mundo estava usando. Mas eu estava pronto.

Duas semanas antes do lançamento, eu entrava no site deles todos os dias. Não para olhar as coisas, mas para estudá-lo. Eu rastreava cada requisição de rede. Documentava cada endpoint. Construí um mapa de sua infraestrutura digital.

A fila foi configurada para disparar em URLs de páginas de produtos:

/products/collab-*

Configuração padrão com proteção razoável. Mas eu notei algo mais. O site deles tinha uma função de lista de desejos (wishlist). E essa lista tinha sua própria API:

POST /api/wishlist/add
{"product_id": "collab-hoodie-black", "size": "L"}

Adicionar algo à lista de desejos não deveria acionar uma fila. É uma ação passiva. Você não está comprando nada. Mas a API da lista de desejos tinha um detalhe interessante. Se o item estivesse em estoque e você estivesse logado com informações de pagamento salvas, a resposta retornaria um quick_buy_token.

Este token era válido para pagamento direto. Nenhuma visita à página do produto era necessária. Nenhum gatilho de fila.

No dia do lançamento, executei um script que consultava a API da lista de desejos a cada 200 milissegundos. No momento em que os itens ficaram à venda, eu já tinha tokens para finalizar a compra – antes mesmo de o sistema de fila perceber que os itens estavam disponíveis.

Eu consegui um hoodie do meu tamanho. Minhas mãos tremiam quando recebi o e-mail de confirmação.

Lição aprendida:

As filas protegem caminhos específicos. Qualquer endpoint desprotegido é um atalho potencial.

Imersão Profunda

Esse primeiro sucesso foi inebriante. Mas eu apenas tive sorte – tropecei em um erro de configuração específico para um site específico.

Mas eu não queria apenas encontrar bugs, eu queria entender a arquitetura bem o suficiente para prever onde esses bugs existiriam.

E eu recorri ao queue-it – um provedor de sistemas de fila que publica documentação extensa. Eles explicam em detalhes como seu sistema funciona: gatilhos, validação, gerenciamento de tokens, tudo.

A maioria das pessoas que estão em filas virtuais nunca leem algo assim. Eu li três vezes.

Isto é o que eu aprendi: os sistemas de fila são fundamentalmente reativos. Eles esperam que certas condições sejam atendidas e então interceptam. As condições são definidas por regras, e as regras são escritas por administradores que nem sempre entendem completamente seus próprios aplicativos.

Tipos comuns de gatilhos:

• Correspondência de padrões de URL (URL pattern matching)
  • A fila é ativada ao visitar certas páginas.
• Execução de JavaScript
  • O código do lado do cliente o redireciona para a sala de espera.
• Presença de cookies
  • Certos cookies indicam que você precisa ser colocado na fila.
• Inspeção de cabeçalhos (Header inspection)
  • Certos cabeçalhos de requisição acionam a interceptação.
• Limitação de taxa de requisições (Rate limiting)
  • Muitas requisições em um curto período de tempo o enviam para a fila.

Cada tipo desses gatilhos tem pontos fracos. E cada ponto fraco pode ser explorado.

A Falácia do JavaScript

Muitas implementações de fila dependem de JavaScript.

Quando você visita uma página protegida, o servidor retorna o conteúdo real da página – mas junto com um script que verifica instantaneamente seu status na fila e o redireciona para a sala de espera se você não passar na validação.

A lógica se parece com algo assim:

javascript
(function() {
 if (!hasValidQueueToken()) {
 window.location.href = '/queue/waiting-room';
 }
})();

Simples e eficaz, mas falho.

Porque este código é executado em sua máquina. Em seu navegador. Sob seu controle.

Eu aprendi a interceptar JavaScript antes que ele fosse executado. Extensões de navegador. Ferramentas de proxy. Às vezes, eu simplesmente desativava o JavaScript completamente e via o que acontecia.

Uma plataforma de ingressos entregava a página inteira do evento com a verificação da fila em JavaScript. Desative os scripts – você obtém a página bruta junto com os botões "Comprar ingressos" funcionando.

E os botões realmente funcionavam. Por quê? Porque a integração da fila foi feita preguiçosamente. Os desenvolvedores penduraram uma bela "porta" na forma de um script JS na vitrine, mas se esqueceram de colocar um "guarda" no depósito do banco de dados.

Sim, eles validaram a transação em si no lado do servidor. Mas não havia uma única linha de código no backend que verificasse:

• Este comprador tem um token de passagem na fila?

A fila era puramente cosmética. Este é um erro arquitetônico clássico – transferir a lógica de segurança crítica para o lado do cliente, onde o usuário é rei e deus.

Naquele mês, comprei ingressos para três shows usando apenas a opção "Desativar JavaScript" no Firefox.

Lição aprendida:

Segurança no lado do cliente não é segurança. É teatro.

Endpoints Esquecidos

Os aplicativos web modernos são uma espécie de escavação arqueológica.

Camada por camada, você pode remover o código que se acumulou ao longo dos anos. Novas funções são construídas sobre a infraestrutura antiga. As APIs são declaradas obsoletas, mas nem sempre desativadas. Endpoints que ninguém se lembra mais que existem.

Durante uma das minhas imersões particularmente profundas, encontrei um site de varejo que usava três sistemas de checkout diferentes simultaneamente:

• Seu checkout atual em React (protegido por fila).
• Um checkout PHP legado de 2018 (parcialmente protegido).
• Um checkout web móvel antigo de 2015 (completamente desprotegido).

O checkout móvel ainda estava funcionando. Ele aceitava os mesmos IDs de produtos, os mesmos tokens de pagamento, tudo a mesma coisa. Mas estava localizado em um URL diferente que ninguém se preocupou em proteger.

• Atual: checkout.example.com/cart
• Legado: example.com/checkout.php
• Antigo: m.example.com/buy.php

Eu escrevi um script que detectava quando os itens apareciam no site principal e então enviava imediatamente requisições de compra através do endpoint móvel.

Sem filas. Sem espera. Acesso direto ao sistema de processamento de pedidos.

Este padrão se repete em todos os lugares. As empresas crescem. As bases de código se expandem. As medidas de segurança são aplicadas ao novo código, mas não são aplicadas retroativamente ao código antigo.

Lição aprendida:

Sempre procure fantasmas do passado. Sistemas legados assombram aplicativos modernos.

Jogo de Três Cartas com Sessões

Os sistemas de fila precisam rastrear quem está esperando e quem já passou na validação. Eles fazem isso usando tokens – identificadores únicos armazenados em cookies ou armazenamento local (local storage).

Uma pergunta interessante: o que exatamente esses tokens provam? Em teoria, o token prova que você esperou sua vez na fila. Na prática, os tokens geralmente provam muito menos.

Eu encontrei um sistema onde a lógica de proteção foi implementada de forma ridiculamente descuidada. Os desenvolvedores terceirizaram a geração de tokens para o lado do cliente e acidentalmente deixaram o "sal secreto" no pacote JavaScript público. Outro sistema nem se preocupou com criptografia e simplesmente codificou os parâmetros da sessão usando Base64 previsível.

token = MD5(session_id + timestamp + "secret_salt")

Depois de vasculhar o código-fonte da página e fazer engenharia reversa de sua lógica do lado do cliente, consegui gerar tokens válidos para qualquer sessão e qualquer hora. Eu não precisava esperar na fila – eu poderia declarar programaticamente que já havia esperado, simplesmente gerando a string correta.

Outro sistema usava IDs de token sequenciais. A primeira pessoa na fila recebia o token 1. A segunda pessoa – o token 2. E assim por diante. A validação verificava se o número do seu token era menor que o número do "atendido atual". Se o atendido atual fosse 5000, os tokens 1-4999 seriam considerados válidos.

Com essa lógica, você pode simplesmente pegar qualquer token de 1 a 4999 e obter acesso imediato.

Lição aprendida:

Os sistemas de token são tão confiáveis quanto a lógica de sua geração e validação. Ambos geralmente têm falhas.

Corrida Contra o Tempo

Esta técnica requer precisão, mas é surpreendentemente eficaz.

Os sistemas de fila não são ativados instantaneamente. Sempre há um atraso – às vezes segundos, às vezes milissegundos – entre o momento em que um item fica à venda e o momento em que o sistema de fila percebe que precisa ativar a proteção.

Isso é chamado de "janela de inserção" (inception window).

Durante um grande lançamento de eletrônicos, estudei seus padrões de implantação por semanas. Os itens consistentemente ficavam à venda 2-3 segundos antes que a fila fosse ativada em suas páginas. Milissegundos importam. E 2-3 segundos são uma eternidade.

Configurei meus scripts para atingir sua API de adicionar ao carrinho (add-to-cart API) exatamente no momento em que os itens apareciam em seu sistema de inventário – o que eu poderia rastrear através de um endpoint de verificação de estoque separado e desprotegido.

Minhas requisições chegaram diretamente na "janela de inserção". No momento em que a fila foi ativada, meus itens já estavam no carrinho.

Esta técnica requer:

• Precisão cirúrgica.
• Sessões pré-preparadas com informações de pagamento salvas.
• Execução rápida (geralmente menos de um segundo).
• Redundância (várias tentativas, várias sessões).

Não funciona sempre. Mas funciona.

Lição aprendida:

Os sistemas de proteção têm um atraso na inicialização. A velocidade mata as filas.

Loteria Geográfica

Empresas globais gerenciam infraestrutura global. E a infraestrutura global é difícil de manter em um estado sincronizado.

Descobri isso durante o lançamento de um tênis que começou simultaneamente em várias regiões. O site nos EUA tinha uma fila brutal – o tempo de espera era de duas horas. O site britânico mostrou a mesma imagem.

Mas o site australiano? Fila de quinze minutos. Concorrência mínima. Os mesmos itens.

Melho ainda: não havia fila em seu site japonês. Eles planejavam implementá-lo, mas não terminaram a implantação. Fiz uma compra pelo Japão. Enviei para um serviço de encaminhamento de encomendas. Dez dias depois, o tênis estava em minhas mãos.

Isso acontece o tempo todo. A implantação de sistemas de segurança ocorre em etapas. As equipes de marketing se esquecem de coordenar com os engenheiros. As variações regionais escapam pelas rachaduras.

Lição aprendida:

Sempre verifique regiões alternativas. Global não significa uniforme.

O Truque do Referenciador

Este é o mais simples de todos.

Alguns sistemas de fila decidem se devem interceptá-lo ou não com base em onde você veio. Acesso direto à página do produto? Na fila. Acesso da página inicial ou da página da categoria? Pule para não quebrar a experiência normal do usuário.

O referenciador é apenas um cabeçalho HTTP. Você o controla totalmente.

Referer: https://www.example.com/homepage

Encontrei um grande varejista cuja fila só era acionada se o referenciador estivesse vazio ou de uma fonte externa. Se o seu referenciador mostrasse que você veio de um link interno em seu site, você contornaria completamente a fila.

Uma única modificação de cabeçalho. Isso é tudo o que foi preciso.

Escapando da Sala de Espera

As salas de espera são páginas da web. Elas têm JavaScript. Elas consultam os servidores. Elas atualizam sua posição. E às vezes elas mesmas são uma vulnerabilidade.

Uma das implementações que estudei consultava um endpoint de status a cada cinco segundos:

GET /queue/status?token=xyz

Response: {"position": 23481, "ready": false}

Quando o status ready se tornava true, o JavaScript o redirecionava para a página protegida com um token de conclusão. O token de conclusão era gerado no lado do servidor. Mas a lógica de redirecionamento era do lado do cliente.

O que acontece se você mesmo enviar uma requisição para o endpoint de conclusão, sem esperar pelo status ready?

GET /queue/complete?token=xyz

O servidor verificou se meu token era válido. Ele não verificou se eu realmente esperei na fila. Ele simplesmente gerou um certificado de conclusão e me deixou passar. A fila validou o formato do token, não o fato de ter passado pela fila.

Lição aprendida:

Sempre explore a saída, não apenas a entrada.

O Carrinho Sombrio

Esta técnica requer paciência e planejamento, mas é praticamente invisível.

A maioria das plataformas de e-commerce permite que você adicione itens ao carrinho antes que eles sejam oficialmente "lançados". O item existe no banco de dados. O sistema de carrinho o aceita. Ele simplesmente não pode ser pago até o horário de lançamento.

Eu aprendi a identificar os IDs dos itens antes dos anúncios oficiais – através de padrões de URL, força bruta de API e até metadados em imagens promocionais.

Alguns dias antes do lançamento, eu adicionava itens ao meu carrinho com chamadas diretas à API:

POST /api/cart/add

{"product_id": "unreleased-item-2024", "quantity": 1}

O carrinho os aceitou e o item ficou lá esperando.

Quando chegou a hora do lançamento, todos os outros começaram sua jornada: visitar a página, esperar na fila, adicionar ao carrinho, finalizar a compra. Eu fui direto para a finalização da compra. Meu carrinho foi carregado com antecedência. A fila protegia a página do produto – não o carrinho que eu havia montado alguns dias antes.

Para ser justo, esse truque não funcionará em todos os lugares hoje. Os gigantes modernos do e-commerce fazem uma verificação rígida de disponibilidade no momento da transação final. Mas então eu encontrei um sistema onde o status "disponível para venda" só era verificado no estágio de adicionar ao carrinho. O backend na finalização da compra confiava cegamente no que já estava no meu carrinho virtual.

Lição aprendida:

O processo de compra tem vários pontos de entrada. A preparação antecipada pode contornar completamente esse gargalo.

Medindo WebSockets

HTTP não é o único protocolo.

Os aplicativos web modernos estão usando cada vez mais WebSockets para funções em tempo real: chats ao vivo, notificações instantâneas, edição colaborativa, atualizações dinâmicas.

Os sistemas de fila monitoram o tráfego HTTP. E muitas vezes eles ignoram completamente os WebSockets.

Encontrei uma plataforma de venda de ingressos onde a seleção de assentos ocorria por meio de conexões WebSocket. A fila protegia o endpoint HTTP para visualizar os assentos disponíveis. Mas assim que você estabelecesse uma conexão WebSocket, você poderia selecionar e reservar assentos diretamente.

json
{"action": "select_seat", "event": "concert-123", "seat": "A-15"}
{"response": "seat_held", "hold_token": "abc123", "expires": 300}

Este token de reserva era válido para finalização da compra. Nenhuma fila era necessária. O truque era estabelecer uma conexão WebSocket com antecedência – durante a janela de pré-venda, antes que a fila fosse ativada. E então mantê-lo até o momento do lançamento.

Conexão estabelecida. Assentos selecionados. Fila ignorada.

Lição aprendida:

Protocolos diferentes, níveis de proteção diferentes. WebSocket é frequentemente um ponto cego.

Fardo Moral

Mas há algo que precisa ser resolvido aqui. Esses métodos têm consequências.

Para cada fila que eu contorno, outra pessoa espera mais. Para cada item de edição limitada que eu compro pela porta dos fundos, um verdadeiro fã não consegue. É um jogo de soma zero.

O conhecimento em si é neutro: entender como os sistemas funcionam não é inerentemente prejudicial. Mas a aplicação importa. Usei esses métodos para compras pessoais que eu realmente precisava. Também compartilhei conhecimento que outros transformaram em armas para obter lucro.

Eu não posso "desver" o que eu sei. Mas posso ser honesto sobre as consequências. A fila existe por um motivo. É uma tentativa imperfeita de alcançar a justiça. Hackear esse sistema serve aos meus interesses às custas de outros.

O Que Realmente Impede Isso

Para os engenheiros de segurança que estão lendo isto, aqui está o que funciona:

• Validação no lado do servidor para tudo.

  Toda decisão importante deve ser tomada no backend. Não confie em nada no cliente.

• Cobertura completa de endpoints.

  Mapeie sua própria superfície de ataque. Proteja tudo, não apenas os caminhos óbvios.

• Vinculação de tokens.

  Vincule os tokens de fila a impressões digitais de dispositivos, padrões de comportamento, intervalos de endereços IP. Torne-os impossíveis de falsificar ou transferir.

• Detecção de anomalias em tempo real.

  As pessoas têm padrões de comportamento. Os bots têm padrões de comportamento. São padrões diferentes. Detecte-os.

• Proteção independente de protocolo.

  HTTP, WebSocket, GraphQL – a lógica da fila deve ser aplicada uniformemente a todos os canais de comunicação.

• Auditoria de sistemas legados.

  Encontre seus fantasmas. Desative-os ou proteja-os.

• Verificação global de implantação.

  Verificações automatizadas de que as medidas de segurança sejam consistentes em todas as regiões e em todos os servidores.

Conclusão

Três anos hackeando filas me ensinaram coisas que nenhum livro didático pode ensinar.

Eu aprendi que a segurança é uma ilusão mantida por consentimento mútuo. Os sistemas confiam que você seguirá as regras. E quando você não segue, eles muitas vezes não percebem a diferença.

Eu aprendi que a complexidade gera vulnerabilidade. Quanto mais recursos uma plataforma tem, mais desvios potenciais existem. Simplicidade é segurança.

Eu aprendi que a documentação é poder. As respostas estão escondidas à vista de todos: na documentação da API, nos guias de frameworks, nos próprios artigos técnicos dos provedores de fila. Leia tudo.

Eu aprendi que o tempo decide mais do que qualquer outra coisa. A lacuna entre a implantação e a ativação da proteção. Milissegundos antes da ativação da fila. A janela entre o anúncio e o lançamento. A velocidade é o desvio final.

Mais importante: aprendi que entender os sistemas muda seu relacionamento com eles. Você deixa de ser um usuário passivo e se torna um participante ativo. Você vê o andaime por trás da bela fachada.