Criptografando IDs com Rede de Feistel: Protegendo APIs sem Modificar o Banco de Dados
Descubra como a Rede de Feistel pode ser utilizada para tornar IDs de API não adivinháveis, oferecendo uma camada adicional de segurança sem a necessidade de alterações complexas no banco de dados ou migrações extensas.
MundiX News·01 de maio de 2026·7 min de leitura·👁 1 views
Em muitos projetos de desenvolvimento web, por razões de escassez de tempo, recursos ou legados de código, a prioridade muitas vezes recai sobre a simplicidade em detrimento da segurança. Um problema recorrente nesses cenários é a exposição de chaves primárias numéricas em URLs, como GET /invoices/1043. Essa prática, que permite a enumeração de dados através de um simples loop, foi a causa de vazamentos significativos, como o da APCOA em 2025, e figura anualmente no topo da lista OWASP como Broken Access Control / IDOR.
A solução ideal envolve a implementação de verificações de autorização robustas em cada endpoint. No entanto, essa é uma tarefa complexa que demanda tempo e planejamento. Enquanto um projeto de autorização não é implementado, uma linha de defesa secundária e de rápida implementação pode ser adotada: ocultar as chaves primárias expostas. Em vez de números sequenciais, a API pode retornar um valor opaco, como um inteiro de 64 bits, que é único e reversível no servidor. Isso impede que um atacante adivinhe IDs adjacentes ou explore padrões sequenciais.
A Rede de Feistel oferece uma abordagem elegante para este problema. Com cerca de quarenta linhas de código, ela permite a criação de uma cifra reversível sobre um bloco de tamanho fixo, utilizando uma função com chave F(data, key). O processo envolve dividir a entrada ao meio, aplicar a função F em uma das metades e combiná-la com a outra metade através de uma operação XOR, repetindo o processo em vários rounds. A reversibilidade é garantida pela estrutura da rede, mesmo que a função F seja irreversível por si só. Essa técnica, que fundamenta algoritmos como DES e Blowfish, é aqui aplicada de forma simplificada para tornar um ID como /persons/1 indetectável.
No contexto de um projeto .NET, a implementação pode ser feita através de um ValueConverter no Entity Framework Core. Este conversor atua na fronteira entre o código da aplicação e o banco de dados, garantindo que o código de negócio e os DTOs operem com um tipo PersonId que encapsula o ID criptografado. O banco de dados continua a armazenar o bigint original, enquanto a API expõe apenas o valor criptografado. A função RoundFunction pode ser uma implementação simples, como SHA-256 truncado para 32 bits, aplicada em um número fixo de rounds. Na prática, IDs sequenciais como 1, 2, 3 se transformam em sequências aparentemente aleatórias, como 5823901847263…, 9174625038192…, 2847193650471…, impedindo que a adição de uma unidade ao ID revele informações sobre outros registros.
As vantagens dessa abordagem incluem simplicidade de implementação e manutenção, sem a necessidade de novas dependências, colunas ou migrações. A estrutura do banco de dados permanece inalterada, com índices densos e inserções eficientes. A cifra é uma bijeção, garantindo que cada ID interno corresponda a um único ID externo e vice-versa, sem a necessidade de tabelas de mapeamento. O custo em tempo de execução é mínimo, com poucos microsegundos por operação. Além disso, os URLs permanecem estáveis, pois o ID criptografado é uma função determinística do ID primário, o que é crucial para a persistência de links e referências.
É fundamental ressaltar que esta técnica não substitui a autorização. Ela impede a enumeração de IDs, mas não autoriza o acesso a um registro específico. Um atacante com um ID válido ainda pode tentar acessar o recurso correspondente. A segurança da chave é um ponto crítico de falha; seu vazamento reabilita a capacidade de enumeração. A rotação da chave é um processo complexo que invalida todos os IDs existentes, quebrando links antigos. Além disso, esta não é uma cifra certificada para proteção de dados sensíveis, mas sim para ofuscação de identificadores. O uso de um bloco de 64 bits sem nonce significa que IDs criptografados idênticos indicam o mesmo registro, mas não revelam o número total de registros ou sua ordem de inserção.
A criptografia de IDs com Rede de Feistel é mais adequada quando APIs expõem IDs sequenciais e a migração para UUIDs é inviável ou indesejada, e quando uma linha de defesa secundária e de rápida implementação é necessária antes da adoção de um sistema de autorização completo. Para cenários que exigem rotação de chave frequente, a assinatura de IDs com HMAC pode ser uma alternativa. Para a proteção de dados em si, algoritmos de criptografia padrão como AES-GCM devem ser utilizados. Em resumo, a Rede de Feistel oferece uma maneira econômica de tornar IDs públicos não adivinháveis sem alterar o banco de dados, mas não deve ser confundida com controle de acesso. É uma ferramenta valiosa para mitigar ataques triviais e melhorar a segurança em projetos com recursos limitados, elevando o custo de ataques automatizados.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Em muitos projetos de desenvolvimento web, por razões de escassez de tempo, recursos ou legados de código, a prioridade muitas vezes recai sobre a simplicidade em detrimento da segurança. Um problema recorrente nesses cenários é a exposição de chaves primárias numéricas em URLs, como GET /invoices/1043. Essa prática, que permite a enumeração de dados através de um simples loop, foi a causa de vazamentos significativos, como o da APCOA em 2025, e figura anualmente no topo da lista OWASP como Broken Access Control / IDOR.
A solução ideal envolve a implementação de verificações de autorização robustas em cada endpoint. No entanto, essa é uma tarefa complexa que demanda tempo e planejamento. Enquanto um projeto de autorização não é implementado, uma linha de defesa secundária e de rápida implementação pode ser adotada: ocultar as chaves primárias expostas. Em vez de números sequenciais, a API pode retornar um valor opaco, como um inteiro de 64 bits, que é único e reversível no servidor. Isso impede que um atacante adivinhe IDs adjacentes ou explore padrões sequenciais.
A Rede de Feistel oferece uma abordagem elegante para este problema. Com cerca de quarenta linhas de código, ela permite a criação de uma cifra reversível sobre um bloco de tamanho fixo, utilizando uma função com chave F(data, key). O processo envolve dividir a entrada ao meio, aplicar a função F em uma das metades e combiná-la com a outra metade através de uma operação XOR, repetindo o processo em vários rounds. A reversibilidade é garantida pela estrutura da rede, mesmo que a função F seja irreversível por si só. Essa técnica, que fundamenta algoritmos como DES e Blowfish, é aqui aplicada de forma simplificada para tornar um ID como /persons/1 indetectável.
No contexto de um projeto .NET, a implementação pode ser feita através de um ValueConverter no Entity Framework Core. Este conversor atua na fronteira entre o código da aplicação e o banco de dados, garantindo que o código de negócio e os DTOs operem com um tipo PersonId que encapsula o ID criptografado. O banco de dados continua a armazenar o bigint original, enquanto a API expõe apenas o valor criptografado. A função RoundFunction pode ser uma implementação simples, como SHA-256 truncado para 32 bits, aplicada em um número fixo de rounds. Na prática, IDs sequenciais como 1, 2, 3 se transformam em sequências aparentemente aleatórias, como 5823901847263…, 9174625038192…, 2847193650471…, impedindo que a adição de uma unidade ao ID revele informações sobre outros registros.
As vantagens dessa abordagem incluem simplicidade de implementação e manutenção, sem a necessidade de novas dependências, colunas ou migrações. A estrutura do banco de dados permanece inalterada, com índices densos e inserções eficientes. A cifra é uma bijeção, garantindo que cada ID interno corresponda a um único ID externo e vice-versa, sem a necessidade de tabelas de mapeamento. O custo em tempo de execução é mínimo, com poucos microsegundos por operação. Além disso, os URLs permanecem estáveis, pois o ID criptografado é uma função determinística do ID primário, o que é crucial para a persistência de links e referências.
É fundamental ressaltar que esta técnica não substitui a autorização. Ela impede a enumeração de IDs, mas não autoriza o acesso a um registro específico. Um atacante com um ID válido ainda pode tentar acessar o recurso correspondente. A segurança da chave é um ponto crítico de falha; seu vazamento reabilita a capacidade de enumeração. A rotação da chave é um processo complexo que invalida todos os IDs existentes, quebrando links antigos. Além disso, esta não é uma cifra certificada para proteção de dados sensíveis, mas sim para ofuscação de identificadores. O uso de um bloco de 64 bits sem nonce significa que IDs criptografados idênticos indicam o mesmo registro, mas não revelam o número total de registros ou sua ordem de inserção.
A criptografia de IDs com Rede de Feistel é mais adequada quando APIs expõem IDs sequenciais e a migração para UUIDs é inviável ou indesejada, e quando uma linha de defesa secundária e de rápida implementação é necessária antes da adoção de um sistema de autorização completo. Para cenários que exigem rotação de chave frequente, a assinatura de IDs com HMAC pode ser uma alternativa. Para a proteção de dados em si, algoritmos de criptografia padrão como AES-GCM devem ser utilizados. Em resumo, a Rede de Feistel oferece uma maneira econômica de tornar IDs públicos não adivinháveis sem alterar o banco de dados, mas não deve ser confundida com controle de acesso. É uma ferramenta valiosa para mitigar ataques triviais e melhorar a segurança em projetos com recursos limitados, elevando o custo de ataques automatizados.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.