Serviços de links curtos com identificadores sequenciais recebem mais requisições de enumeração do que serviços com identificadores aleatórios

Hipótese

O cheat sheet da OWASP sobre referências diretas inseguras a objetos recomenda verificações de controle de acesso em cada objeto e, como medida de defesa em profundidade, identificadores complexos e impraticáveis de adivinhar. Um link curto é, por concepção, um objeto público sem controle de acesso, de modo que o identificador é a única barreira entre o link e um estranho. Com uma chave sequencial (um contador codificado em base62), um cliente que conhece uma chave pode requisitar as vizinhas e alcançar todos os links já criados; com uma chave aleatória de comprimento fixo, a maioria das tentativas falha. A hipótese é que os dois modelos produzem tráfego visivelmente diferente: num serviço sequencial, uma fatia maior dos redirecionamentos bem-sucedidos vem de clientes que nunca receberam o link (chegam sem referrer, em ordem monótona de chaves, a partir de poucas origens de rede, em intervalos típicos de máquina), enquanto num serviço de chaves aleatórias esses clientes produzem sobretudo respostas 404. Uma afirmação secundária é que a taxa bruta de 404, por si só, não separa os dois casos, porque um serviço de chaves aleatórias vê tentativas que falham e um serviço sequencial vê tentativas que acertam.

Previsão

Para dois serviços de tamanho e idade semelhantes, as sessões reconstruídas a partir dos logs de acesso (um cliente, uma hora) mostrarão, no serviço sequencial, uma fatia mensurável de sessões que requisitam muitas chaves existentes distintas em ordem crescente ou decrescente, sem referrer; no serviço de chaves aleatórias essa fatia é próxima de zero e os mesmos clientes aparecem, em vez disso, como rajadas de 404. Bloquear ou limitar a taxa dessas sessões no serviço sequencial reduz de forma notável o volume de redirecionamentos bem-sucedidos; no serviço de chaves aleatórias, muda pouco.

Teste proposto

1. Obter logs de acesso de um serviço de cada tipo referentes ao mesmo período, ou de um único serviço antes e depois da troca da geração de chaves, contendo chave, status, presença de referrer, rede do cliente e horário.
2. Reconstruir as sessões e classificar como enumeração a sessão que requisita mais do que um limite de chaves distintas, em sua maioria adjacentes na ordem das chaves, sem referrer.
3. Informar, para cada serviço, a fatia dos redirecionamentos bem-sucedidos atribuível a sessões de enumeração, a fatia de 404 e o número de chaves distintas alcançadas por essas sessões.
4. Publicar as regras de classificação e os limites, para que outro operador possa aplicá-los aos próprios logs.

Estado

Nenhum resultado é afirmado. Entre os fatores de confusão estão os rastreadores de mecanismos de busca, que seguem links de forma legítima, as diferenças na forma como os dois serviços são divulgados e limites de taxa que já ocultam o comportamento em um dos logs; o teste deve registrar quais limites de taxa estavam em vigor.