Modelar ameaças

Numa loja, o navegador envia um pedido ao servidor, que consulta a base de dados e chama um serviço de pagamento. Modelar ameaças pergunta como este sistema pode violar os seus objetivos. Começa por desenhar esse modelo pequeno e explícito: os componentes, os fluxos de dados entre eles, os ativos a proteger e a fronteira de confiança. Usa as definições de princípios de segurança.

Fluxos e fronteiras de confiança

Nesse fluxo, o navegador não é confiável para decidir preços, porque o atacante pode editar o pedido: um preço escondido num campo HTML continua a ser uma entrada controlada pelo cliente. A base de dados não deve aceitar instruções de qualquer cliente da Internet.

Segue o mesmo pedido de compra: o navegador envia produto=7, quantidade=2 e preco=1. O catálogo do servidor tem preço 30 para o produto 7. Ao atravessar a fronteira, o servidor usa o identificador para procurar o preço autorizado e calcula $2\times30=60$, em vez de aceitar o total 2 sugerido pelo cliente. Validar que preco=1 é um número positivo não estabelece a política de preços.

O serviço de pagamento recebe o total calculado pelo servidor. A confirmação deve ficar ligada à encomenda e ao montante, para não usar o pagamento de outra compra. Para cada fluxo, identifica produtor, intérprete, identidade e operação autorizada.

Fraquezas, vulnerabilidades e evidência

CWE classifica tipos de fraqueza, como cópia sem verificar limites; um registo CVE identifica uma vulnerabilidade divulgada num produto e versão concretos; um exploit demonstra um caminho para a explorar. O guião prático das semanas 2 e 3 pede exatamente esta caracterização curta: identificação, catalogação, exploit conhecido, ataques observados e correção. Usa as bases CVE, NVD, Exploit-DB e CWE indicadas nesse guião. Nem um identificador CVE nem uma pontuação, por si, dizem que a instalação em análise é explorável: versão, configuração, acesso e mitigação importam.

Num teste de intrusão black-box, o avaliador parte de pouco conhecimento interno; num white-box, dispõe de conhecimento privilegiado, como código ou arquitetura. Ambos precisam de âmbito e autorização. Encontrar uma falha demonstra uma possibilidade; não encontrar falhas numa campanha limitada não prova ausência de vulnerabilidades.

Classificar com STRIDE

STRIDE organiza perguntas sobre falsificação de identidade, alteração de dados, repúdio de ações, divulgação de informação, negação de serviço e elevação de privilégios. A sigla ajuda a não esquecer classes de ameaça; não determina sozinha se um ataque é possível.

Situação	Classe	Condição a verificar
Usar um cookie roubado	Spoofing	O identificador confere a sessão sem prova adicional?
Mudar o preço enviado pelo navegador	Tampering	O servidor confia nesse preço?
Negar uma alteração	Repudiation	Há registos protegidos e identidade suficientemente ligada à ação?
Ler fatura de outra conta	Information disclosure	Existe autorização sobre aquela fatura?
Fazer milhares de operações caras	Denial of service	Que recurso se esgota e onde se limita?
Tornar a própria conta administradora	Elevation of privilege	Quem pode alterar o papel e como o servidor decide?

Uma situação pode pertencer a várias classes. O objetivo é descobrir condições e efeitos, não escolher uma etiqueta única por obrigação.

Árvore de ataque

O objetivo é consultar faturas de outra pessoa. Pode bastar obter a sessão dela, OU explorar uma autorização por objeto em falta. No primeiro ramo do exemplo, obter a sessão E utilizá-la antes de expirar são condições necessárias.

Numa porta OU basta um ramo; numa porta E são necessários todos. Não multipliques probabilidades numa porta E sem justificar independência, nem somes ramos OU que podem ocorrer juntos. A árvore lógica pode ser útil mesmo sem probabilidades.

Autorização por objeto

O servidor aceita GET /faturas/42 e devolve a linha quando existe qualquer sessão válida. O ativo é o conteúdo da fatura. A ameaça é divulgação a outra conta. A fraqueza é verificar autenticação sem verificar o dono do objeto. O atacante precisa de uma sessão própria e de uma referência a uma fatura alheia.

A defesa verifica no servidor a política de acesso à fatura, considerando o utilizador autenticado e o objeto pedido. Para validar, faz dois pedidos com contas e objetos controlados: a própria fatura deve ser legível, e a alheia deve ser negada. Um identificador aleatório dificulta a descoberta, mas não substitui a verificação.

O risco residual inclui uma conta legítima comprometida, erros noutra rota e fugas em logs ou exportações. A correção de uma rota não demonstra que todo o sistema cumpre a política.

Responder a uma pergunta aberta

Começa com a condição concreta que permite o ataque; descreve depois a sequência de ações e o resultado observável. Explica por que o controlo proposto interrompe essa sequência. Declara os limites e as hipóteses, como a autoridade do atacante e o componente que consideraste confiável, porque é aí que o avaliador distingue uma análise completa de uma etiqueta.

Pratica apenas em ambientes teus ou expressamente autorizados. Os exemplos desta página são análises de sistemas fictícios, sem pedidos a serviços externos.