Modelo de ameaças e autoatestação OWASP ASVS L1

Este modelo cobre a implantação de produção do vaulted.fyi incluindo seu frontend web, suas rotas de API e o armazenamento no Upstash Redis. Também cobre o CLI publicado e o servidor MCP na medida em que interagem com a mesma API.

Fora do escopo:

• O dispositivo do usuário (navegador, sistema operacional, extensões, área de transferência, tela).
• O canal de comunicação pelo qual o link compartilhado é entregue (e-mail, Slack, SMS, etc.).
• O tratamento posterior do texto simples por parte do destinatário.
• Vulnerabilidades no Vercel ou Upstash abaixo da superfície de API que consumimos.

Ativo principal: o segredo em texto simples. Ele nunca deve chegar ao servidor, persistir fora dos navegadores do remetente e do destinatário, nem ser recuperável apenas a partir do estado do lado do servidor.

Ativos secundários: o texto cifrado, os IVs, os contadores de visualizações, os carimbos de tempo de expiração e a integridade / disponibilidade do serviço.

Fronteiras de confiança (em ordem decrescente de confiança):

1. Navegador do remetente — confiável com o texto simples e a chave.
2. Navegador do destinatário — confiável com o texto simples e a chave após abrir o link.
3. Rede entre o cliente e o servidor — não confiável; mitigado por TLS 1.3 e pela decisão de projeto de que apenas o texto cifrado a atravessa.
4. Servidor do Vaulted (nós) — parcialmente confiável. Tratado como um armazenamento passivo de texto cifrado. O modelo de ameaças assume que o próprio Vaulted poderia ser comprometido sem expor o texto simples.
5. Upstash Redis — mesmo nível de confiança que o servidor. Apenas blocos criptografados.

Observador passivo da rede. ISP, ator no caminho com acesso a metadados de TLS. Derrotado pelo TLS e pela ausência de texto simples ou chave no canal.

Atacante ativo da rede. Pode tentar um MitM. Derrotado por TLS, precarga de HSTS e validação de certificados. Um comprometimento bem-sucedido do TLS ainda revela apenas texto cifrado.

Servidor comprometido / operador hostil. Inclui nós. Não consegue ler os segredos armazenados porque a chave nunca chega. Pode negar o serviço ou modificar o bundle de JS servido — o que é abordado nos riscos residuais mais abaixo.

Atacante não autenticado com um link compartilhado válido. Por design, qualquer pessoa com o link completo pode descriptografar. Os limites de visualizações, a expiração e a frase-senha opcional reduzem a janela. É uma propriedade deliberada, não uma falha.

Atacante direcionado contra um remetente ou destinatário específico. Pode explorar o dispositivo, o canal de entrega ou o tratamento do texto simples pelo destinatário após a descriptografia. Fora do controle do Vaulted; documentado por honestidade.

• AES-256-GCM no lado do cliente com IVs aleatórios de 96 bits de crypto.getRandomValues.
• Chaves de 256 bits geradas por segredo via crypto.subtle.generateKey; colocadas no fragmento da URL, nunca transmitidas.
• Encapsulamento opcional com frase-senha usando PBKDF2 (alta contagem de iterações) e encapsulamento de chave AES-GCM.
• Aplicação atômica da contagem de visualizações via HINCRBY do Redis com exclusão na mesma transação ao atingir o limite.
• Expiração automática baseada em TTL limitada a 30 dias; sem prorrogação após a criação.
• Limitação de taxa por IP com janela deslizante nos endpoints de criação e visualização.
• noindex nas páginas de visualização /s/[id] para que as URLs dos segredos não possam vazar por meio de buscas.
• TLS 1.3 com precarga de HSTS, cabeçalhos de segurança robustos, sem registro de IP além das janelas de limitação de taxa.

São decisões de fronteira deliberadas, documentadas para que os usuários possam decidir se o Vaulted se encaixa em seu modelo de ameaças.

• Comprometimento do dispositivo. Um keylogger, um navegador infectado ou uma extensão hostil podem ler o texto simples após a descriptografia.
• Vazamento do canal de entrega. Se o link compartilhado for encaminhado, arquivado ou citado em uma thread de e-mail respondida, esse canal se torna a superfície de ataque.
• Troca direcionada do bundle. Uma CDN ou um edge do Vercel comprometidos poderiam servir um JS diferente a um usuário específico. Subresource Integrity e builds reproduzíveis são mitigações parciais e estão no roadmap.
• Comportamento do destinatário. Uma vez descriptografado, o destinatário pode copiar, fazer captura de tela ou encaminhar.
• Frase-senha fraca. Se usada, uma frase-senha fraca é vulnerável a força bruta por qualquer pessoa que tenha a chave encapsulada.
• Coação / tortura. Fora do escopo de qualquer controle técnico.

A matriz a seguir mapeia a implementação do Vaulted contra uma seleção de requisitos do OWASP ASVS nível 1. As categorias que não se aplicam (sessões, autenticação, upload de arquivos) são marcadas como N/A com uma breve justificativa em vez de omitidas, para que a ausência de uma entrada não seja interpretada como evasão.

A numeração segue a estrutura do ASVS 4.0. A lista é selecionada, não exaustiva — o objetivo é ser honesto sobre os controles que se aplicam de forma significativa a um armazenamento de texto cifrado sem estado e sem contas.

Qualquer mudança que afete um item deste documento — novo endpoint, mudança criptográfica, refatoração que afete dependências, mudança de infraestrutura — deve disparar uma revisão desta página no mesmo PR. A versão e a data de publicação acima serão incrementadas quando o documento for atualizado; a versão anterior permanece acessível no histórico público do git.