Modelagem de ameaças com STRIDE: o primeiro modelo de uma aplicação web

#O que é STRIDE

STRIDE é uma lista de seis categorias de ameaça: falsificação de identidade (spoofing), adulteração (tampering), repúdio (repudiation), divulgação de informação (information disclosure), negação de serviço (denial of service) e elevação de privilégio (elevation of privilege). A Microsoft usa o modelo na orientação dela sobre modelagem de ameaças. O STRIDE não encontra ameaças por você. Ele dá seis perguntas para fazer sobre cada parte de um projeto, para que o resultado não dependa do que você lembrou numa tarde específica.

O método vem antes da maioria das ferramentas de segurança. Um scanner olha um sistema que já está rodando. A modelagem de ameaças olha o plano: quais componentes existem, que dados passam entre eles e onde o nível de confiança muda. Dá para começar com papel e caneta, antes de existir qualquer código.

#Por que isso importa

Muitas falhas de segurança em aplicações web são falhas de projeto. O servidor confia no preço que o navegador enviou. Uma rota de administração verifica se o usuário está logado, mas nunca verifica se ele é administrador. Um arquivo de log guarda tokens de sessão. Cada um desses problemas pode ser corrigido no código, mas o código costuma seguir o projeto que recebeu. O problema começa no projeto.

A OWASP Threat Modeling Cheat Sheet diz a mesma coisa. Antes de saber quais ameaças se aplicam, você precisa entender os fluxos de dados, as fronteiras de confiança e as outras partes do sistema. A modelagem de ameaças registra esse entendimento de um jeito que outras pessoas conseguem revisar.

#Os blocos básicos

#Diagramas de fluxo de dados

Um diagrama de fluxo de dados (DFD) tem quatro tipos de elemento:

• Entidades externas: pessoas ou sistemas fora do seu controle, como o navegador de um cliente.
• Processos: código que recebe, altera ou envia dados, como uma API web.
• Armazenamentos de dados: lugares onde os dados ficam guardados, como um banco de dados ou um arquivo de log.
• Fluxos de dados: setas que mostram dados passando entre os outros três.

Mantenha o diagrama em uma página. Se ele precisar de uma segunda, provavelmente você está desenhando dois sistemas.

#Fronteiras de confiança

Uma fronteira de confiança é a linha em que os dados passam de um lugar com um nível de confiança para outro. O seu servidor fica dentro da linha. O navegador fica fora, porque quem o usa pode alterar qualquer requisição antes de ela chegar a você. Todo fluxo que cruza uma fronteira precisa de validação, e a maior parte das ameaças interessantes está nesses cruzamentos. A cheat sheet da OWASP chama esses pontos de possíveis pontos de ataque.

Fronteiras não são só bordas de rede. Um processo que roda com outra conta do sistema operacional, um provedor de identidade de terceiros ou um banco de dados que aceita conexões de vários serviços podem, cada um, ser uma fronteira.

#As seis categorias

Cada categoria quebra uma propriedade de segurança.

Essas descrições seguem a documentação de modelagem de ameaças da Microsoft. Spoofing, por exemplo, é usar a informação de autenticação de outro usuário.

Nem toda categoria se aplica a todo elemento. Um mapa inicial comum, usado em muitas ferramentas de modelagem, é este: entidades externas recebem spoofing e repudiation; processos recebem as seis; armazenamentos recebem tampering, repudiation, information disclosure e denial of service; fluxos recebem tampering, information disclosure e denial of service. Trate o mapa como um lembrete, não como regra. Se uma categoria parecer irrelevante para um elemento, anote o motivo, para que quem revisar possa contestar.

#Como funciona, passo a passo

1. Defina o escopo. Escreva uma frase que diga o sistema, a versão e o que está fora. "A aplicação Juice Shop e a sua API, rodando localmente, sem contar o sistema operacional do host" já basta.
2. Desenhe o diagrama de fluxo de dados. Adicione entidades externas, processos, armazenamentos e fluxos. Escreva em cada fluxo o que ele transporta.
3. Desenhe as fronteiras de confiança. Coloque uma linha onde a confiança muda de mãos.
4. Passe cada elemento pelas categorias. Para cada categoria que se aplica, faça a pergunta da tabela e escreva a ameaça em uma frase curta. Uma forma útil é dizer quem faz o quê e o que dá errado: "Um token de sessão roubado permite que um atacante faça pedidos em nome do cliente."
5. Escolha uma resposta para cada ameaça: uma mitigação, um risco aceito com motivo escrito ou uma transferência para outra parte. Uma ameaça sem resposta continua aberta.
6. Guarde o modelo no controle de versão, ao lado do código, e marque uma data para revisá-lo.

Para uma funcionalidade pequena, os passos de 1 a 5 levam cerca de uma hora. Na primeira vez, espere refazer o diagrama pelo menos uma vez. Isso é normal.

#Mão na massa: modelar o OWASP Juice Shop

O OWASP Juice Shop é uma aplicação web intencionalmente insegura, feita para treino. Neste laboratório você não explora nada. Você desenha o projeto dela, lista ameaças e escreve mitigações. As ameaças saem da leitura do projeto, não de um ataque à aplicação.

Rode o laboratório só na sua máquina, com o acesso preso a 127.0.0.1. Se você ainda não preparou o contêiner, siga antes OWASP Juice Shop com Docker.

#Pré-requisitos

Você precisa de:

• Docker, para rodar o contêiner do laboratório
• Git, para registrar o modelo
• OWASP Threat Dragon para desktop, gratuito e de código aberto, na página de releases: https://github.com/OWASP/threat-dragon/releases
• Uma pasta vazia para o repositório do laboratório

Na máquina de teste usada para este artigo, git --version mostrou:

git version 2.49.0.windows.1

#Passo 1: subir o laboratório

docker run --rm -d --name juice-shop-lab -p 127.0.0.1:3000:3000 bkimminich/juice-shop

A parte -p 127.0.0.1:3000:3000 publica a porta só na interface de loopback. Outros computadores da sua rede não conseguem acessá-la.

Confirme que a aplicação web responde:

curl -sI http://127.0.0.1:3000/ | head -n 1

Na máquina de teste, a primeira linha da saída foi:

HTTP/1.1 200 OK

Confirme que a API responde. Este é um GET simples para uma lista de produtos:

curl -s -o /dev/null -w "products %{http_code} %{content_type}\n" http://127.0.0.1:3000/api/Products

Saída:

products 200 application/json; charset=utf-8

Verifique a versão que a aplicação informa:

curl -s http://127.0.0.1:3000/rest/admin/application-version

Saída:

{"version":"20.3.0"}

Essa versão foi a informada pela imagem em 8 de novembro de 2026, na máquina de teste. A sua imagem pode informar outra. Anote a versão que você ver, porque o modelo de ameaças descreve uma release específica.

#Passo 2: instalar o Threat Dragon

Baixe o build para desktop do seu sistema operacional na página de releases, instale e abra. Os nomes de menus nos passos abaixo não foram conferidos com um build do Threat Dragon para este artigo, e eles mudam entre versões. Use os nomes que aparecem no seu build.

#Passo 3: desenhar o diagrama

Crie um novo modelo de ameaças e adicione estes elementos:

• Um ator externo chamado Browser, descrito como "navegador do cliente, fora do nosso controle".
• Um processo chamado Juice Shop web e API, descrito como "aplicação web e API em 127.0.0.1:3000".
• Um armazenamento de dados chamado banco SQLite, descrito como "arquivo de dados da aplicação".
• Dois fluxos do navegador para o processo: requisições HTTP e, de volta, respostas HTTP.
• Dois fluxos do processo para o armazenamento: consultas SQL e as linhas retornadas.
• Uma fronteira de confiança que separa o navegador do processo e do armazenamento.

O modelo deve ficar assim:

Browser (ator externo)
   |  requisições e respostas HTTP
   v
=================== fronteira de confiança ===================
   Juice Shop web e API (processo, 127.0.0.1:3000)
   |  consultas SQL e linhas
   v
Banco SQLite (armazenamento de dados)

O esboço em texto serve só de guia. O arquivo real é o que o Threat Dragon salva.

O modelo usa SQLite como armazenamento. Confira a documentação do projeto para a versão que você roda, porque os detalhes de armazenamento podem mudar entre releases.

#Passo 4: listar ameaças por elemento

Aplique o mapa inicial visto antes. O navegador é uma entidade externa, então recebe spoofing e repudiation. Cada fluxo do navegador para a API recebe tampering, information disclosure e denial of service. O processo da API recebe as seis categorias. O armazenamento SQLite recebe tampering, repudiation, information disclosure e denial of service.

Veja um exemplo por categoria. Um modelo real terá mais linhas para cada elemento.

Use a documentação do projeto para ver quais fraquezas a sua versão inclui de propósito. Descreva cada ameaça em termos de projeto. Não escreva passos de exploração no modelo. Este laboratório não precisa de tráfego de ataque.

No Threat Dragon, adicione cada ameaça ao elemento a que ela pertence, com título, descrição e mitigação. Se o seu build tiver campo de status, marque como aberta as mitigações que você ainda não implementou.

#Passo 5: exportar e commitar

Exporte o modelo como JSON pelo menu de arquivo e dê o nome juice-shop-threat-model.json. Depois, na pasta do laboratório:

git init
cp /caminho/para/juice-shop-threat-model.json .
git add juice-shop-threat-model.json && git commit -m "First STRIDE model"

O Git mostra um resumo curto com o nome do branch e a mensagem do commit. O texto exato depende da sua versão do Git e das configurações. Se o Git pedir uma identidade, defina a sua com git config user.name e git config user.email, e faça o commit com o seu nome.

Antes de commitar, leia o arquivo. Ele não deve conter nomes de host reais, tokens nem dados de clientes. Este modelo usa apenas 127.0.0.1.

Pare o laboratório quando terminar:

docker stop juice-shop-lab
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 http://127.0.0.1:3000/

Na máquina de teste, a saída foi:

juice-shop-lab
000

A primeira linha vem do docker stop. O 000 significa que o curl não recebeu resposta da porta, ou seja, o laboratório está parado.

#Um modelo de ameaças é um documento vivo

Um modelo de ameaças descreve um projeto no dia em que foi escrito. Quando o projeto muda, o modelo fica desatualizado. Gatilhos comuns:

• um novo endpoint ou um novo papel
• um novo provedor de login
• um banco de dados movido para outro serviço, o que adiciona um fluxo de rede e, talvez, uma nova fronteira de confiança
• um novo tipo de dado, como dados de pagamento ou dados pessoais
• uma dependência que agora roda com mais acesso do que antes

O Threat Modeling Manifesto diz que a modelagem de ameaças deve acompanhar as mudanças de projeto, em iterações, cada uma limitada a uma parte gerenciável do sistema. Na prática, são três hábitos. Mantenha o arquivo JSON no repositório, ao lado do código. Adicione uma pergunta de revisão em pull requests que mexem em autenticação, fluxos de dados ou integrações externas: o modelo ainda corresponde ao sistema? Registre a data e a versão da aplicação que o modelo descreve. Ameaças marcadas como mitigadas continuam sendo histórico útil, então mantenha-as.

#Erros comuns

• Desenhar o sistema que você gostaria de ter. Desenhe o que roda de verdade, incluindo proxy, cache e jobs em segundo plano.
• Começar pela empresa inteira. Comece com uma funcionalidade e um fluxo, depois expanda.
• Listar ameaças sem mitigação nem responsável. Ameaça sem resposta continua aberta.
• Escrever uma mitigação como "usar criptografia" sem detalhe. Diga o que está protegido, onde, e como alguém verifica.
• Deixar de desenhar as setas. A maior parte das ameaças está nos fluxos e nas fronteiras, não dentro das caixas.
• Tratar as seis categorias como uma lista de tarefas para zerar. Elas são lembretes. O resultado útil é uma decisão para cada ameaça.
• Testar sistemas que você não controla para confirmar uma ameaça. O modelo não precisa de testes ao vivo, e qualquer teste pertence ao seu laboratório autorizado.

#Como ir além

• Leia lado a lado a lista de ameaças da Microsoft e a cheat sheet da OWASP. Anote onde concordam nas categorias e onde a redação muda.
• Modele uma funcionalidade de um projeto que você mantém, como login ou recuperação de senha.
• Siga para o OWASP Top 10 para desenvolvedores. Ele lista as fraquezas web que você mais vai encontrar, e elas se encaixam bem nas linhas da sua tabela.
• Saiba que existem outros métodos, como árvores de ataque e métodos voltados à privacidade, para perguntas que o STRIDE responde de forma menos direta.

#Fontes

• Microsoft: Threat modeling tool threats
• OWASP Threat Modeling Cheat Sheet
• OWASP Threat Dragon
• Threat Modeling Manifesto
• OWASP Juice Shop project
• Docker port publishing