Modelagem de ameaças STRIDE

O QuickBite está adicionando pedidos online. Os clientes escolhem a comida, pagam e esperam o restaurante confirmar o pedido.

O caminho feliz é claro. Um cliente envia um pedido, a cozinha o recebe e o app manda atualizações.

Segurança faz uma pergunta diferente: o que pode dar errado antes de construirmos isso?

Essa pergunta se chama modelagem de ameaças. Você olha para um design, imagina formas de usá-lo mal e decide o que o código precisa fazer para evitar isso.

A modelagem de ameaças acontece antes do relatório de bug

A revisão de código olha para um código que já existe.

A modelagem de ameaças olha para a funcionalidade enquanto ainda é barato mudá-la.

A lista STRIDE

STRIDE é uma técnica de memorização para seis formas de um atacante bagunçar um sistema. As letras significam:

Letra	Ameaça	Pergunta simples
S	Spoofing (falsificação)	Alguém pode fingir ser outra pessoa?
T	Tampering (adulteração)	Alguém pode mudar dados que não deveria mudar?
R	Repudiation (repúdio)	Alguém pode negar ter feito algo porque não existe registro?
I	Information disclosure (divulgação de informação)	Alguém pode ver dados que não deveria ver?
D	Denial of service (negação de serviço)	Alguém pode impedir o app de funcionar para outras pessoas?
E	Elevation of privilege (elevação de privilégio)	Alguém pode fazer mais do que o seu papel permite?

A frase do curso é útil: o STRIDE te dá seis formas de um atacante bagunçar o seu sistema.

Vamos direcionar essas seis perguntas para o QuickBite.

JunoA lista STRIDE STRIDE é um checklist para a sua imaginação. Ele evita que você faça só a primeira pergunta de segurança que vem à cabeça.

As letras ficam menos assustadoras quando você as transforma em perguntas simples: alguém pode fingir, mudar, negar, ler, bloquear ou fazer mais do que deveria?

JunoA lista STRIDE Use o STRIDE para impedir que a revisão dependa de quem por acaso está na sala. Seis perguntas, na mesma ordem, para cada funcionalidade.

O resultado útil não é a sigla. É a linha que você consegue transformar em trabalho concreto: o servidor verifica quem é o dono do pedido antes de exibi-lo, o valor do pagamento é calculado no servidor, as mudanças no pedido são registradas com conta e horário.

JunoA lista STRIDE O STRIDE surgiu de um trabalho de modelagem de ameaças da Microsoft no final dos anos 1990, o que é um bom lembrete de que a parte duradoura não foi a ferramenta. Foi a lista de perguntas repetível.

As letras não são uma garantia. Elas deixam passar abusos em que um usuário faz exatamente o que o seu papel permite, mas em uma escala prejudicial, e não decidem se você deveria ter coletado aquele dado em primeiro lugar.

Trate o STRIDE como uma primeira passada disciplinada, não como um certificado vindo dos deuses da segurança. Os deuses estão indisponíveis e a entrega é sexta-feira.

Percorrendo o QuickBite com o STRIDE

Comece com um fluxo de funcionalidade:

1. O cliente cria um pedido.
2. O servidor calcula o total.
3. O cliente paga.
4. O restaurante aceita ou recusa o pedido.
5. O cliente recebe atualizações.

Agora faça as seis perguntas do STRIDE sobre esse fluxo.

Ameaça	Exemplo no QuickBite	Decisão
Spoofing	Uma requisição afirma ser de outro cliente.	Use a sessão autenticada, não um id de usuário vindo do corpo da requisição.
Tampering	O navegador envia um preço mais barato.	Calcule o preço no servidor a partir dos dados do cardápio.
Repudiation	Um restaurante diz que nunca recusou um pedido.	Registre quem mudou o status do pedido e quando.
Information disclosure	Um cliente lê o pedido de outro cliente.	Verifique a propriedade antes de retornar os detalhes do pedido.
Denial of service	Um usuário envia milhares de pedidos.	Adicione limites de taxa e de tamanho das requisições.
Elevation of privilege	Um cliente chama um endpoint exclusivo de restaurantes.	Verifique o papel e o vínculo com o restaurante no servidor.

Essa tabela já é útil. Ela diz à equipe quais verificações precisam existir antes de a funcionalidade estar segura o suficiente para ser lançada.

Um modelo de ameaças só importa quando cada ameaça vira uma decisão.

JunoPercorrendo o QuickBite com o STRIDE Escolha uma funcionalidade e percorra-a como se fosse uma história. Em cada etapa, pergunte o que alguém poderia fingir, mudar, negar, ler, bloquear ou fazer sem permissão.

Depois escreva a decisão ao lado. Uma preocupação se torna útil quando alguém consegue construir ou testar a resposta.

JunoPercorrendo o QuickBite com o STRIDE A tabela é o artefato. Mantenha-a perto do ticket, não enterrada em um documento separado que ninguém mais abre depois do planejamento.

Escreva as linhas como critérios de aceitação sempre que possível. "O servidor calcula o total a partir dos dados do cardápio" é algo que dá para construir. "É possível adulterar o preço" é uma anotação com a qual alguém concorda e depois esquece.

JunoPercorrendo o QuickBite com o STRIDE O modo de falha silencioso é escrever ameaças sem dono. Toda linha deveria terminar como uma de três coisas: corrigir agora, aceitar com uma justificativa, ou adiar com um responsável nomeado.

Isso parece burocrático até a revisão de um incidente perguntar por que o total do pedido confiava no navegador. Um risco aceito e datado é uma decisão. Uma coluna de decisão vazia é arqueologia com iluminação pior.

Modelagem de ameaças potenciais

A modelagem de ameaças potenciais começa de forma ampla. Em vez de olhar para uma funcionalidade, você olha para um sistema inteiro ou uma parte grande dele.

Para o QuickBite, isso pode significar:

• tudo o que um cliente pode fazer depois de entrar na conta
• tudo o que um dono de restaurante pode fazer
• todo o caminho do pagamento
• todo lugar por onde os dados do pedido saem do app

Esse estilo é útil quando você herda um app, lança um novo sistema ou quer encontrar problemas antigos de design.

O risco é o escopo crescer sem controle. "O app inteiro" vira uma reunião longa e uma sala cansada. Escolha um limite que as pessoas consigam apontar.

Defina o escopo antes de começar

A modelagem de ameaças potenciais precisa de um escopo fixo e de um tempo fixo.

Sem os dois, o exercício se expande até que todo mundo pare de tomar decisões.

JunoModelagem de ameaças potenciais A modelagem de ameaças potenciais é a versão ampla. Você olha para uma área inteira, como o caminho do pagamento, e pergunta o que poderia dar errado ali.

Mantenha a fronteira pequena o suficiente para enxergar. "O caminho do pagamento" é útil. "O app inteiro" geralmente vira uma máquina de fumaça.

JunoModelagem de ameaças potenciais Use a modelagem de ameaças potenciais quando a forma do sistema importa mais do que uma única funcionalidade. Ações do cliente, ações do dono do restaurante, pagamento, uploads e ferramentas administrativas são bons escopos.

Antes de a reunião começar, escreva o limite. Se uma ameaça ficar fora dele, deixe-a de lado. Caso contrário, a sessão vira um passeio por tudo que preocupa no produto.

JunoModelagem de ameaças potenciais A varredura ampla raramente produz trabalho do tamanho de uma sprint. Ela produz problemas estruturais: um fluxo de pagamento com chamadores demais, uma superfície administrativa que compartilha a sessão do cliente, um caminho de webhook que ninguém é responsável.

Isso ainda é valioso, mas direcione o resultado para o planejamento. Classifique as descobertas pelo custo de deixá-las como estão, e escreva o argumento com clareza suficiente para que alguém consiga viabilizar isso depois sem precisar reconstruir a reunião de memória. A memória é onde as decisões de risco viram folclore.

Coloque em prática

O QuickBite adiciona uma funcionalidade: um cliente pode deixar uma avaliação em um pedido concluído, e o restaurante pode responder.

Percorra-a com o STRIDE. Para cada letra, nomeie uma coisa que poderia dar errado e a verificação que resolve isso.

Compare suas respostas

Letra	O que poderia dar errado	A verificação
S Spoofing	Alguém publica uma avaliação como se fosse outro cliente	O servidor pega o autor a partir da sessão, nunca do corpo da requisição
T Tampering	Um restaurante edita o texto ou a nota de uma avaliação depois do fato	Só o autor pode editar a própria avaliação, e as respostas são registros separados
R Repudiation	Um restaurante nega ter publicado uma resposta abusiva	Registre quem escreveu o quê e quando, com o id da conta
I Information disclosure	Uma avaliação expõe o nome completo ou o endereço do cliente	Decida o que é público antes de armazenar, e retorne só esses campos
D Denial of service	Alguém publica milhares de avaliações, ou uma avaliação com um megabyte de texto	Um limite de tamanho no texto e um limite de taxa no endpoint
E Elevation of privilege	Um cliente responde como se fosse o restaurante	A rota de resposta verifica se a conta é dona daquele restaurante

Duas coisas merecem atenção. O R é o que as pessoas costumam pular, porque nada está quebrado até alguém contestar o que aconteceu, e nesse momento o registro ou existe, ou não existe.

E o S tem uma única correção que resolve tudo: pegar a identidade a partir da sessão, nunca de um campo enviado por quem chama. Uma avaliação que carrega o próprio authorId é uma avaliação que qualquer um pode assinar com o nome de outra pessoa.

Para onde isso vai a seguir

O STRIDE te dá as seis perguntas. O próximo capítulo muda a escala.

Em vez de varrer um sistema inteiro, a modelagem de ameaças por funcionalidade coloca essas perguntas em uma funcionalidade de cada vez. Essa é a versão que a maioria dos desenvolvedores consegue usar dentro do planejamento normal.