Controlo de acesso quebrado: ainda o risco web número um

De todas as categorias de vulnerabilidade web que reportamos, o controlo de acesso quebrado é a que encontramos com mais frequência e a que causa mais danos quando passa despercebida. Está no topo do OWASP Top Ten desde 2021, e nada nos nossos próprios dados de intervenções sugere que isso vá mudar.

A razão é estrutural. A maioria das outras classes de vulnerabilidade são falhas de uma biblioteca, de um interpretador ou de uma configuração — coisas que um scanner reconhece. O controlo de acesso é uma falha de lógica de negócio. A aplicação faz exatamente aquilo para que foi escrita; foi apenas escrita para confiar na coisa errada.

Como se manifesta na prática

O exemplo clássico é um identificador no URL. Uma fatura está em /faturas/4821, o utilizador muda para /faturas/4822 e aparece a fatura de outra pessoa. Chama-se normalmente IDOR — referência direta insegura a objeto — e continua notavelmente comum, sobretudo em APIs construídas para um produto de inquilino único e mais tarde estendidas a vários clientes.

Mas os casos interessantes raramente são tão evidentes. Os que mais vemos em produção são estes:

• Lacunas ao nível da função. A interface esconde o botão «exportar todos os utilizadores» de quem não é administrador, mas o endpoint por trás verifica apenas que existe sessão iniciada.
• Verificações no sítio errado. A autorização é aplicada no controlador que desenha a página, mas um segundo controlador — uma exportação, um webhook, um endpoint móvel — chega aos mesmos dados por outro caminho e nunca recebeu a verificação.
• Fronteiras de inquilino que falham em objetos secundários. O registo principal está corretamente limitado à sua organização, mas os anexos, comentários ou registos de auditoria associados são obtidos pelo próprio identificador, sem filtro de inquilino.
• Fluxos que podem ser saltados. Um passo de aprovação é garantido pela sequência de ecrãs em vez de o ser pelo servidor, pelo que submeter diretamente para o passo final o contorna.
• Privilégios que sobrevivem a uma alteração. Um utilizador é despromovido de administrador a membro, mas a sessão existente, o token de API ou as permissões em cache mantêm os direitos antigos até expirarem.

Porque os scanners não encontram isto

Um scanner automático não sabe que a fatura 4822 pertence a uma empresa diferente da 4821. Vê duas respostas HTTP 200 válidas. Detetar a falha exige saber o que a aplicação deve permitir, o que implica conhecer os perfis, o modelo de inquilinos e as regras de negócio. Esse conhecimento vem de uma pessoa a ler a aplicação, não de uma base de assinaturas.

É esta a diferença prática entre uma análise de vulnerabilidades e um teste de intrusão, e é por isso que testamos aplicações autenticadas com várias contas de níveis diferentes, e não apenas com uma.

Como testar a sua própria aplicação

Não precisa de ferramentas especializadas para encontrar boa parte destes casos. Precisa de duas contas e de método.

• Crie dois utilizadores em organizações diferentes, e mais dois na mesma organização com níveis distintos — por exemplo um administrador e um membro só de leitura.
• Como utilizador com mais privilégios, percorra a aplicação e registe todos os pedidos que o navegador faz. O separador de rede do navegador chega para começar.
• Repita cada um desses pedidos com a sessão do utilizador com menos privilégios, sem alterar mais nada. Depois repita com a sessão da outra organização.
• Qualquer pedido que devolva dados em vez de uma recusa clara é uma constatação. Preste atenção a respostas HTTP 200 com corpo vazio ou a redirecionamentos — aplicação parcial continua a ser lacuna.
• Repita para os identificadores: incremente-os e experimente identificadores que sabe pertencerem ao outro inquilino.

Comece pelos endpoints que mais importam: tudo o que exporta, tudo o que lista, tudo o que toca em faturação e tudo o que foi acrescentado nas últimas duas versões. As funcionalidades novas são onde a verificação é mais vezes esquecida.

Corrigir de forma duradoura

A correção duradoura não são mais verificações espalhadas pelos controladores — é mover a decisão para um único sítio. Negar por omissão e autorizar centralmente: uma camada por onde passa todo o acesso a dados, que recebe o utilizador e o objeto pedido e responde sim ou não. As formas variam — objetos de política, segurança ao nível da linha na base de dados, um middleware que limita todas as consultas por inquilino — mas o princípio é o mesmo. Se um programador tiver de se lembrar de acrescentar a verificação, mais cedo ou mais tarde alguém não se lembrará.

Dois hábitos de apoio fazem muita diferença. Primeiro, torne os identificadores não adivinháveis — não como controlo de segurança em si, mas porque elimina a enumeração trivial. Segundo, registe as recusas de autorização e alerte sobre picos: um utilizador a gerar centenas de pedidos recusados está a dizer-lhe algo útil.

Se levar daqui apenas uma ideia: teste a sua aplicação com uma segunda conta, de menor privilégio. A maioria das falhas de controlo de acesso que reportamos teria sido apanhada por alguém a fazer exatamente isso antes do lançamento.