Atribuição em massa.

A atribuição em massa ocorre quando frameworks (Rails, Spring, ASP.NET, NestJS, Django) mapeiam automaticamente campos JSON ou de formulário recebidos para atributos do modelo, sem uma allow-list explícita. Um atacante adiciona propriedades extras — isAdmin, role, balance, tenantId — que o servidor então persiste. A falha é difícil de detectar em revisão de código porque a atribuição é implícita: uma única chamada update_attributes(params) ou de um model-binder oculta o fato de que todos os atributos são graváveis. Está catalogada como CWE-915 e aparece no OWASP API Security Top 10 (2019 A6, incorporada em API3 "Broken Object Property Level Authorization" em 2023).

O incidente canônico é o ataque de Egor Homakov ao GitHub em março de 2012: como o formulário de chave SSH vinculava public_key[user_id] sem uma whitelist, ele adicionou um campo forjado, anexou sua chave à conta de organização do Rails e enviou um commit para rails/rails. O GitHub corrigiu em poucas horas, e o episódio levou o Rails a tornar a whitelist attr_accessible — mais tarde strong_parameters — o padrão.

As mitigações incluem DTOs ou esquemas de entrada explícitos, allow-lists rigorosas de campos vinculáveis, separação de atributos internos dos modelos vinculáveis pelo usuário e testes negativos que enviam chaves JSON inesperadas.

flowchart TD
  A["Cliente envia POST com JSON<br/>{name, isAdmin:true}"] --> B[Auto-binder do framework]
  B --> C{Allow-list explícita<br/>de campos?}
  C -->|Não — atribuição em massa| D[Todas as chaves gravadas no modelo]
  D --> E[(isAdmin=true<br/>persistido no BD)]
  C -->|Sim — DTO / strong params| F[Apenas campos permitidos vinculados]
  F --> G[(Campos privilegiados ignorados)]