5 dicas de auditoria de segurança do MSQ Snap e Consensys Diligence

Consensys Diligence é uma divisão de auditoria da Consensys Software Inc., reconhecida por sua expertise incomparável na condução de auditorias meticulosas em um espectro que abrange Solidity, Cairo e uma variedade de bibliotecas ZK. A equipe Diligence está liderando os padrões de auditoria e segurança para o MetaMask Snaps e trabalha em estreita colaboração com a equipe do MetaMask para garantir a segurança do recurso de carteira. Além disso, a equipe Diligence é pioneira no desenvolvimento de ferramentas de segurança e soluções de fuzzing contínuo de ponta, validadas nos ambientes de produção mais exigentes.

O projeto MSQ foi lançado recentemente na MetaMask Snaps Store. O MSQ é um Snap que permite aos usuários interagir com a rede Internet Computer, gerenciar tokens baseados em IC, autorizar com segurança em dapps baseados em IC e pagar por bens e serviços digitais. Em essência, é uma carteira de criptomoedas integrada ao MetaMask, projetada especificamente para o Internet Computer com recursos distintos de autorização e pagamentos.

Juntas, as equipes Diligence e MSQ identificaram cinco áreas-chave a serem abordadas neste artigo — Documentação, Design de Software, Código, Cadeia de Suprimentos e Correções — fornecendo uma lista de práticas empregadas pela equipe MSQ durante o desenvolvimento, juntamente com comentários da equipe Diligence elaborando sobre os benefícios de segurança dessas práticas, tornando-o um recurso útil para qualquer pessoa que esteja desenvolvendo um Snap para a MetaMask Wallet ou qualquer outro sistema crítico de segurança sujeito a possível auditoria de segurança. Vamos começar!

1. Crie documentação em múltiplas camadas

A documentação transforma os conceitos que estão na sua cabeça em algo visível para os outros. A documentação em camadas ajuda o leitor a entender esses conceitos da forma que você pretende, imergindo-o gradualmente no contexto. Obviamente, quanto mais clara for a documentação, mais ampla será a perspectiva que ela pode oferecer sobre o seu projeto, e melhor os outros irão compreendê-lo.

Definimos as camadas de documentação na ordem inversa de como um leitor normalmente as acessaria, com cada camada oferecendo um nível mais alto de abstração. Dessa forma, os leitores que começam com a visão geral irão progressivamente se aprofundar nos detalhes.

1.1 Código

A fonte definitiva de informações sobre o seu software é o próprio código, que serve como a camada fundamental da sua documentação. Embora contenha todas as informações necessárias, é difícil processar essas informações. Quanto mais limpo for o código, mais fácil será extrair as abstrações de nível mais alto. Mas em sistemas reais, essas abstrações estão ocultas por trás de interações complexas dos componentes do sistema, semanas de dívida técnica e soluções rápidas e improvisadas.

Portanto, antes de tudo, você quer proteger as pessoas que leem seu código de serem induzidas ao erro por partes complicadas do seu sistema. A melhor maneira de fazer isso é reduzir a carga cognitiva necessária para ler seu código. Algumas estratégias incluem:

• Tornar seu código navegável, permitindo fácil travessia em IDEs.

• Usar nomenclatura detalhada para esclarecer o propósito e a funcionalidade dos elementos do código.

• Empregar linguagens fortemente tipadas para definir formatos de dados claros.

O MSQ Snap e os frontends do dapp são desenvolvidos em TypeScript, o que evitou inúmeros erros potenciais, em contraste com as armadilhas do JavaScript puro. Da mesma forma, nosso backend utiliza Rust, conhecido por seu robusto sistema de tipos. Além disso, o MSQ Snap exporta vários métodos que podem ser executados por um aplicativo de terceiros. No entanto, não usamos strings para identificar esses métodos; em vez disso, usamos constantes. Temos um objeto constante como este:

export const SNAP_METHODS = {
  protected: {
    identity: {
      login: "protected_identity_login",
      ...
    },
    icrc1: {      
	    ...
    },
    ...
  },
  public: {
    identity: {
      sign: "public_identity_sign",			
      ...
    },
    ...
  },
};
Copiar

No código, esse objeto constante pode ser usado como guia para acessar o método correto, e os leitores podem entender muito sobre esse método pelo seu identificador no objeto. Por exemplo, o método SNAP_METHODS.protected.identity.login só pode ser executado pelo dapp companion do MSQ e permite que o usuário faça login. Essa abordagem melhora a clareza do código e simplifica a refatoração, pois as alterações nos nomes dos métodos são gerenciadas de forma centralizada, em vez de serem atualizadas em múltiplas ocorrências.

Para corresponder aos nomes dos métodos, usamos uma grande expressão switch com ramificações como esta:

case SNAP_METHODS.protected.identity.login: {
  result = protected_handleIdentityLogin(req.params.body);
  break;
  }
Copiar

Como você pode ver, é muito difícil interpretar algo de forma errada ao ler aqui — tudo é nomeado com precisão, sem deixar espaço para a imaginação.

Comentário da Diligence O tempo é um fator crítico. Enquanto os desenvolvedores têm semanas para entender uma base de código, os engenheiros de segurança frequentemente têm apenas dias para identificar riscos. Essa restrição destaca a importância de reduzir a carga cognitiva no código — uma prática que beneficia tanto a eficiência dos desenvolvedores quanto a segurança.

O que podemos aprender com a base de código do MSQ é que um código claro e navegável, com nomenclatura descritiva e tipagem forte (como TypeScript), reduz mal-entendidos, uma fonte comum de vulnerabilidades.

Mas lembre-se: as anotações de tipo do TypeScript são verificadas apenas em tempo de compilação! Para qualquer dado que seja processado ou analisado em tempo de execução (RPC, JSON, ...), são necessárias verificações adicionais de tipo, formato de dados e limites! Para esse fim, o MSQ utiliza elegantemente o zod, uma biblioteca de validação de esquemas com prioridade para TypeScript e inferência de tipo estático, e recomendamos que as equipes sigam essa abordagem.

O MSQ encontrou o equilíbrio ideal ao tornar as intenções do código claras por meio da quantidade certa de comentários. Essa clareza ajuda os pesquisadores de segurança a compreender rapidamente o "fio condutor" e os conceitos centrais da base de código. Ao escrever código fácil de entender, os desenvolvedores aumentam significativamente a eficácia das revisões de segurança rápidas.

1.2 Comentários de código

Acreditamos que comentar não significa cobrir 100% do seu código. É fundamental anotar as partes que são complexas ou mal escritas. Áreas como expressões regulares, criptografia e manipulações de strings se beneficiam especialmente de comentários claros.

Por exemplo, no MSQ, temos uma função que escapa possíveis caracteres de controle de Markdown em uma string. Seu corpo é uma única linha de código, mas há correspondência de expressão regular, então descrevemos sua funcionalidade em um comentário:

/**
 * Escapes Markdown control characters, newline characters, and backticks in a string.
 * This function takes a string and returns a new string with all Markdown control characters, newline characters, and backticks escaped.
 * Escaping is done by prefixing each control character and backtick with a backslash (`\\`), and newline characters are replaced with `\\\\n`.
 *
 * Control characters include: `{`, `}`, `[`, `]`, `(`, `)`, `#`, `!`, `|`, `\\`, and `` ` ``.
 * Newline characters are replaced with a visible escape sequence (`\\\\n`) for demonstration or specific formatting needs.
 * Since all newlines are escaped, list creating characters `-`, `+` and `.` are allowed.
 * Text styling characters `*`, `_` are also allowed
 *
 * @param {string} text The string to be escaped.
 * @return {string} The escaped string, safe to be used in Markdown without triggering formatting, with newline characters visually represented and backticks escaped.
 */
export function escapeMarkdown(text: string) {
  return text.replace(/([{}\\[\\]()#!|\\\\`])|\\n/g, (match) => (match === "\\n" ? "\\\\n" : "\\\\" + match));
}
Copiar

Se você não se importa com IA no seu fluxo de trabalho, o ChatGPT é ótimo para gerar bons comentários para essas funções utilitárias rapidamente (apenas verifique o resultado que ele fornece).

Comentário da Diligence Como revisores de segurança, usamos os comentários de funções como roteiros pelo código desconhecido. Lembre-se de que temos um tempo limitado para revisar o código, e quando os comentários não correspondem à implementação, não é apenas confuso — é um sinal de alerta.

Eles frequentemente revelam que a função ou sua descrição se desvia da especificação, sinalizando possíveis vulnerabilidades. Talvez uma função ignore verificações prometidas ou trate dados de forma inesperada, o que pode levar a consequências graves.

Portanto, mantenha seus comentários concisos e precisos, de forma semelhante ao que o MSQ faz em sua base de código. Os comentários inline não são apenas notas; são balizas que nos guiam pelo seu código, e desalinhamentos são pistas de que algo pode estar errado.

1.3 Documentação em nível de sistema

Após garantir que seu código e suas complexidades estejam bem documentados, o próximo passo é delinear a arquitetura do sistema. Isso envolve detalhar as interações entre componentes e os protocolos, algoritmos e estruturas de dados que seu software emprega. Essa camada utiliza principalmente formatos legíveis por humanos, como texto e diagramas, em vez de código.

A documentação do sistema MSQ inclui uma visão geral da arquitetura e um guia de integração. Esses documentos, repletos de descrições textuais, exemplos e diagramas, esclarecem como as diferentes partes do sistema interagem.

Os diagramas de sequência são inestimáveis para visualizar as interações entre componentes. Recomendamos o uso do diagrams.net (draw.io), uma ferramenta gratuita que se mostrou versátil em vários projetos.

Comentário da Diligence Ao contrário dos comentários inline que detalham funções, os documentos do sistema fornecem uma visão de alto nível, revelando todo o panorama de uma aplicação. Essa perspectiva é crucial para identificar problemas entre componentes ou vulnerabilidades no fluxo do usuário que frequentemente são invisíveis no nível do código.

Pense em uma revisão de segurança como um jogo de Command & Conquer. Você começa com um mapa quase totalmente obscurecido. À medida que você explora, os documentos do sistema funcionam como unidades de reconhecimento, revelando toda a arquitetura — permissões, interações Snap-dApp, interações do usuário. Essa visão geral progressiva permite que os revisores rastreiem as jornadas dos usuários, como acompanhar os movimentos das unidades no jogo, para identificar caminhos que possam contornar a segurança.

Além disso, documentos de sistema abrangentes devem conter observações relevantes para a segurança e, idealmente, o resultado de um exercício de modelagem de ameaças. Fornecendo uma visão clara dos principais componentes, interações, riscos, atores e fluxos típicos de usuários. Isso ajuda os revisores a se concentrarem nas áreas de alta prioridade e a identificar desvios da especificação.

Para os desenvolvedores, uma boa documentação do sistema não é apenas burocracia; é um mapa compartilhado que orienta as estratégias ofensivas e defensivas, transformando as revisões de segurança de sondagens cegas em operações estratégicas.

1.4 Documentação de visão geral

Essa camada inclui uma grande variedade de materiais, como artigos, landing pages, posts de blog, vídeos de demonstração e muito mais.

Essas informações são principalmente sobre aspectos de negócios, mas respondem muito bem à pergunta "O quê?", enquanto todas as camadas anteriores respondiam à pergunta "Como?" com diferentes níveis de detalhe.

Um recém-chegado provavelmente conhecerá seu projeto por meio desse tipo de material, portanto, manter essa camada o mais simples e visual possível é uma boa ideia. Além disso, esse tipo de material geralmente é o único que mostra o software em ação — como um usuário pode ir do estado A ao estado B usando seu software. Ao vê-lo em ação, as pessoas se familiarizam com a ideia principal do seu software, permitindo que façam suposições sobre como ele funciona por baixo dos panos.

Por exemplo, a tela principal da landing page do MSQ diz em letras grandes: "USE THE INTERNET COMPUTER WITH METAMASK". Após ler essa simples frase, o leitor provavelmente pensaria: "Ah, então isso é um Snap de carteira que pode armazenar tokens da blockchain Internet Computer. Provavelmente funciona da mesma forma que outros Snaps para outras blockchains, apenas usando tecnologias do ecossistema de desenvolvimento do IC" — o que é uma suposição 100% correta.

Comentário da Diligence Nossa experiência com o MSQ e inúmeros outros projetos de blockchain mostrou consistentemente que uma documentação clara e de alto nível não é apenas benéfica — é fundamental tanto para a adoção pelos usuários quanto para a segurança. Durante nossa revisão do Snap do MSQ, ficamos positivamente surpresos com a abordagem de documentação em múltiplas camadas deles. Um vídeo explicativo do desenvolvedor nos colocou rapidamente a par do projeto. Conseguimos entender os recursos do Snap mesmo antes de olhar para o código em si. Essa visão geral de alto nível mostrou a interface do usuário, com comentários sobre os comportamentos esperados e os fluxos típicos dos usuários. Esses recursos visuais são inestimáveis, permitindo que especialistas em segurança compreendam os "caminhos felizes" codificados na aplicação muito mais rapidamente e procurem vulnerabilidades que frequentemente estão ocultas fora desses caminhos. Isso, combinado com uma demonstração ao vivo do snap e do código, é tipicamente o início ideal para uma revisão de segurança.

2 Restrinja o design sempre que possível

Esta parte é provavelmente a mais importante para a segurança do seu projeto. Seu código pode estar 100% livre de bugs, e sua infraestrutura pode estar protegida com medidas que valem milhões de dólares. Mas todos esses esforços não significariam nada se o seu design contiver alguma falha fundamental que possa ser explorada por agentes maliciosos.

Embora exemplos específicos variem de acordo com o caso de uso, oferecemos algumas dicas universais.

2.1 Desenvolva diretrizes de segurança e siga-as

No início do MSQ, estabelecemos princípios de segurança fundamentais que se alinham com nossa visão:

• A equipe MSQ não sabe de nada: Não coletamos nenhuma informação sensível do usuário, incluindo materiais de chave, dados de sessão de autorização ou detalhes de conta.

• O material criptográfico nunca sai do Snap: A entropia protegida do MetaMask do usuário é processada exclusivamente dentro do Snap, gerada sob demanda e descartada imediatamente após o uso.

• O MSQ é determinístico: Os usuários podem recuperar todos os fundos, identidades e pares de chaves de forma determinística usando sua frase semente raiz, sem precisar de conhecimento adicional.

• O MSQ prioriza a privacidade: Nossos esforços priorizam a privacidade do usuário acima de tudo.

Esses princípios são adaptados às necessidades específicas do MSQ. No entanto, a equipe do MetaMask também fornece um conjunto de diretrizes de segurança para desenvolvedores de Snap, às quais o MSQ adere, disponíveis aqui.

Por exemplo, há o princípio de Permissões mínimas, que basicamente significa que quanto menos permissões seu Snap solicitar de um usuário, melhor será sua segurança. O MSQ solicita apenas 4 permissões:

• endowment:rpc

• snap_dialog

• snap_manageState

• snap_getEntropy

Não precisamos de endowment: network access porque o MSQ é responsável apenas por assinar transações, não por entregá-las ao IC — o dapp integrador é responsável por isso.

Você deve fazer o mesmo no seu Snap — pegue a diretriz padrão do MetaMask, estenda-a com suas regras específicas e siga-as.

Comentário da Diligence Dizemos aos nossos clientes: "Segurança não é um recurso que você adiciona; é um princípio em torno do qual você projeta." O estabelecimento de princípios de segurança fundamentais pelo MSQ desde o início do projeto é exatamente o que procuramos. Com muita frequência, os projetos tratam a segurança como uma reflexão tardia, adicionando medidas após a arquitetura central estar definida. Essa abordagem retroativa inevitavelmente deixa falhas fundamentais que correções no nível do código não conseguem resolver verdadeiramente.

Na Consensys Diligence, fornecemos serviços especializados em segurança, ferramentas e defendemos os direitos dos usuários finais. Isso inclui garantir que o material de chave dos usuários permaneça seguro dentro dos limites de confiança da carteira, nunca exposto involuntariamente fora dessa zona. Também nos concentramos em preservar a privacidade do usuário, idealmente evitando até mesmo vazamentos de metadados ou informações de canal lateral para terceiros. Além disso, incentivamos os snaps a solicitar apenas as permissões mínimas necessárias para a funcionalidade — o princípio do menor privilégio.

A postura proativa do MSQ está alinhada com esses princípios. Ao priorizar a segurança desde o início, eles estão construindo uma base mais sólida — uma que é inerentemente mais resistente a vulnerabilidades.

2.2 Proteja o usuário a todo custo

Esta é mais uma meta-diretriz — é um princípio que deve ser implementado em qualquer software: de jogos online a sistemas bancários.

O exemplo mais notável disso no MSQ é nossa abordagem ao gerenciamento de identidade. Como você deve saber, a maioria das carteiras disponíveis fornece ao usuário um conjunto de identidades (endereços, contas, etc.). Esse conjunto pode ser acessado por qualquer dapp, com o consentimento do usuário. Por exemplo, para assinar algumas transações.

Isso é muito útil para integrações entre dapps, porque qualquer dapp pode invocar métodos de contratos inteligentes de outros dapps em nome do usuário e estender as capacidades uns dos outros dessa forma. Por exemplo, uma plataforma de pagamento em criptomoedas pode chamar os contratos inteligentes da Uniswap para trocar automaticamente os tokens do comprador, de modo que correspondam ao que o vendedor espera receber como pagamento por um determinado bem ou serviço.

Mas isso é prejudicial para a segurança, pois sites fraudulentos podem enganar as pessoas para que assinem transações maliciosas e esvaziem suas carteiras.

Em contraste, o MSQ adota a técnica de escopo de identidade — cada dapp (cada origem de URL distinta) tem seu próprio conjunto separado de identidades de usuário com as quais pode interagir, sem capacidade de interagir com as identidades do usuário de outros dapps. Isso não apenas resolve o problema de sites fraudulentos, mas também ajuda muito com a privacidade, pois os dapps não podem mais rastrear o usuário e ver com quais contratos inteligentes (chamados de canisters no IC) eles interagem. Esse método, inspirado no Internet Identity e na especificação WebAuthn, mitiga significativamente os riscos de segurança.

Por exemplo, se um dapp conhecido for comprometido, as carteiras tradicionais ficariam vulneráveis em todos os dapps. Em contraste, o escopo de identidade do MSQ confina a ameaça ao dapp comprometido, evitando danos mais amplos.

No entanto, esse método limita a integração direta entre dapps, pois os usuários têm identidades distintas em cada um. O MSQ oferece soluções para cenários específicos, como permitir o compartilhamento de identidade entre dapps com consentimentos duplos, útil para situações como mudanças de nome de domínio.

Além disso, o MSQ garante que os dados que um dapp pode acessar estejam estritamente vinculados à identidade relevante, protegendo ainda mais as informações do usuário e mantendo a privacidade em diferentes aplicações.

Comentário da Diligence A troca de integração direta limitada entre dApps é uma escolha ponderada. Em nossas avaliações de risco, frequentemente discutimos o "orçamento de segurança" — reconhecendo que a segurança perfeita pode prejudicar a funcionalidade. O MSQ gastou esse orçamento com sabedoria. Ao restringir as interações entre dApps, eles reduziram drasticamente um dos riscos mais graves (abuso generalizado de identidade) enquanto preservam as funções essenciais da carteira.

3 Escreva código sólido

Já falamos um pouco sobre o código quando discutimos a documentação. Aqui queremos enfatizar alguns outros aspectos do código, que estão mais relacionados à técnica do que à legibilidade.

3.1 Seu código

"Sólido" aqui significa que o código se comporta de forma previsível, cobrindo todas as entradas esperadas e inesperadas. Por exemplo, como seu Snap deve reagir se receber uma string base64 quando espera hex? Ou se os métodos forem chamados em uma sequência não intencional, ou se um método RPC indefinido for invocado?

Abordar essas incertezas requer:

1. Tratamento claro de erros: Certifique-se de que cada ramificação e caso no seu código seja verificado e tratado adequadamente. No Snap do MSQ, usamos verificações exaustivas do TypeScript em instruções switch-case para capturar quaisquer chamadas de método inesperadas, conforme mostrado abaixo:

default: {
  err(ErrorCode.INVALID_RPC_METHOD, request.method);
}
Copiar

Essa configuração captura casos em que um identificador de método RPC desconhecido é usado.

1. Sanitização de entrada: Validar dados de entrada em relação a tipos e formatos esperados pode ser complexo, mas é essencial para a segurança. Utilizamos a biblioteca zod em TypeScript para isso, estendendo o sistema de tipos do TypeScript para verificações em tempo de execução. O Zod permite definições de esquema detalhadas, garantindo que apenas dados válidos sejam processados.

Por exemplo, nosso método SNAP_METHODS.protected.identity.login usa um esquema zod para validar a entrada rigorosamente:

export const ZIdentityLoginRequest = z.object({
  toOrigin: ZOrigin,
  withIdentityId: ZIdentityId,
  withLinkedOrigin: z.optional(ZOrigin),
});

export const ZOrigin = z.string().url();
export const ZIdentityId = z.number().int().nonnegative();
Copiar

Aqui, ZOrigin e ZIdentityId não são meras strings ou números, mas subtipos especificamente validados, garantindo que as entradas não sejam apenas corretas em tipo, mas também contextualmente apropriadas.

Ao definir esquemas zod com a maior precisão possível, você pode resolver preventivamente muitos problemas potenciais. Os auditores recomendaram a aplicação de validação rigorosa no MSQ, que, após a implementação, identificou e corrigiu vários riscos de segurança.

Comentário da Diligence Esta não é a primeira vez que ouvimos de nossos clientes que a implementação de validação mais rigorosa com base em nossas recomendações para um cenário de ataque específico revelou vários outros riscos de segurança. Isso reflete precisamente nossa experiência, e é por isso que sempre defendemos a validação rigorosa de entrada para reduzir a superfície de ataque. Em muitas revisões de segurança, começamos examinando a validação de entrada. Ao apertar isso, frequentemente surgem problemas latentes — um efeito dominó em que a correção de uma vulnerabilidade revela outra. É um sinal claro de que o projeto leva nosso feedback a sério, fortalecendo iterativamente seu sistema. Com uma superfície de ataque reduzida, fica progressivamente mais difícil para os atacantes explorar com sucesso as fraquezas.

3.2 Código de terceiros

No MSQ, consideramos nossa responsabilidade fornecer aos desenvolvedores de dapp uma biblioteca intuitiva, facilitando a interação correta e eficiente com nosso Snap. Isso permite que não apenas o MSQ, mas também desenvolvedores terceiros mantenham bases de código limpas e sólidas.

Essa biblioteca é benéfica por vários motivos:

• Simplifica a complexidade da API: Abstraímos as complexidades do Snap em uma API amigável ao usuário. Por exemplo, a biblioteca cliente do MSQ usa CBOR para codificação de dados, contornando as restrições do JSON-RPC e poupando os desenvolvedores do trabalho de codificação e decodificação manual de dados.

• Garante interações seguras e diretas: Certas funcionalidades do Snap são exclusivas do nosso dapp companion. Para facilitar isso, gerenciamos os processos de redirecionamento e transferência de dados, garantindo um fluxo contínuo via postMessage. Esse tratamento interno garante que desenvolvedores terceiros interajam com nosso Snap por meio de uma API clara e direta.

• Melhora a clareza semântica: Uma API limpa é mais do que apenas uma ferramenta; é um meio de comunicação, tornando o código mais legível e compreensível, livre da desordem de processos intrincados de codificação/decodificação e camadas operacionais adicionais.

Ao priorizar esses aspectos, o MSQ visa criar um ecossistema onde tanto nosso Snap quanto os dapps integradores possam operar de forma eficiente e segura.

Comentário da Diligence A abordagem do MSQ para integração de código de terceiros por meio de sua biblioteca demonstra um compromisso com a simplificação do desenvolvimento enquanto mantém a segurança. Embora em sua essência a segurança deva ser estritamente aplicada no contexto do Snap, uma biblioteca voltada para dapps pode fornecer uma maneira conveniente de se comunicar com o Snap. No entanto, deve-se sempre observar que o desenvolvedor do dapp precisa garantir a interação segura com o Snap e a codificação segura dos dados quando usados no contexto do dapp.

4 Proteja sua cadeia de suprimentos

O recente backdoor do XZ enfatizou mais uma vez como é importante trabalhar contra a entrada de código malicioso em algumas de suas dependências. No MSQ, usamos o pnpm para gerenciar dependências, mas na verdade não faz diferença qual gerenciador de pacotes você prefere. Há duas coisas que fazemos no MSQ para nos proteger contra esses vetores de ataque:

4.1 Vincule pacotes a versões específicas

Usar pnpm install --save <package-name> normalmente instala a versão mais recente de um pacote, aderindo à especificação semver, que permite atualizações automáticas para versões mais recentes sem quebras. Isso é indicado pelo símbolo de circunflexo (^) no package.json, significando um intervalo de versões aceitáveis:

No entanto, para evitar riscos de atualizações maliciosas, é mais seguro bloquear as dependências em versões específicas:

1. Elimine o circunflexo (^) do seu package.json para fixar cada versão de dependência. Remova quaisquer arquivos de lock existentes e node_modules, depois execute pnpm install para alinhar estritamente com as versões definidas.

2. Use a flag --save-exact para instalações futuras (pnpm install --save-exact <package-name>) para evitar atualizações automáticas.

A confiança é um fator nessa decisão. Por exemplo, no MSQ consideramos os namespaces de dependência @metamask e @dfinity seguros e permitimos atualizações dentro de seu intervalo semver. No entanto, ao fazer isso, tenha cuidado com possíveis vulnerabilidades de dependências transitivas.

Comentário da Diligence Migrar projetos para versões exatas de dependências evitou inúmeros problemas:

• Impediu que atualizações silenciosas reintroduzissem vulnerabilidades corrigidas.

• Evitou o "desvio de versão", onde diferentes módulos veem comportamentos diferentes da biblioteca.

• Foi crucial em investigações pós-incidente, permitindo-nos replicar o ambiente exato. Cada próxima atualização pode ser maliciosa, em qualquer namespace, qualquer pacote. Ao revisar os pacotes usados e vincular apenas a versões seguras conhecidas, evitando atualizações acidentais, a superfície de ataque para ataques à cadeia de suprimentos é ainda mais reduzida. Confiar em determinados fornecedores é aceitável, desde que as novas versões sejam verificadas manualmente para garantir que não contenham código malicioso antes do uso. Observe que, especialmente pacotes bem conhecidos usados por muitos projetos são alvos preferenciais para agentes maliciosos e, como o passado demonstrou, qualquer biblioteca central pode ser vítima de ataques sofisticados à cadeia de suprimentos (veja o ataque backdoor do XZ)

4.2 Faça commit dos arquivos de lock no seu repositório

Para garantir consistência em sua equipe e manter builds reproduzíveis, faça commit dos seus arquivos de lock no sistema de controle de versão. No MSQ, utilizamos pnpm workspaces e turborepo, necessitando de um único arquivo de lock raiz, pnpm-lock.yaml. No entanto, sua configuração pode exigir a manutenção de vários arquivos de lock; todos devem ser versionados para garantir a consistência do ambiente.

Comentário da Diligence Essa prática, embora às vezes negligenciada como uma mera conveniência de desenvolvimento, é na verdade um componente crítico para manter uma base de código segura e estável. Nossos anos de auditoria de contratos inteligentes, componentes de blockchain e agora MetaMask Snaps mostraram repetidamente que builds reproduzíveis não são apenas algo desejável, mas um requisito fundamental de segurança. Fazer commit dos arquivos de lock é uma peça do quebra-cabeça para reduzir a superfície de ataque para ataques à cadeia de suprimentos. Quando npm install não é mais uma loteria, versões e checksums concretos deixam uma trilha de auditoria no repositório, os builds são mais determinísticos e as discussões de "Funciona na minha máquina" deixam de existir.

5 Corrija de forma rápida e limpa

Embora isso não seja diretamente sobre nosso Snap, entender como abordar as descobertas de auditoria de forma eficiente é fundamental.

Assim que a equipe de auditores reportar uma descoberta, você deve começar a trabalhar em uma correção. O tamanho e a complexidade da correção dependem claramente da descoberta, mas há um conselho para torná-la menor e mais limpa — corrija a causa, não o sintoma, sempre que possível.

Por exemplo, no MSQ, os auditores descobriram que é possível injetar caracteres de controle de Markdown em nossas mensagens de consentimento do MetaMask. Em vez de corrigir cada mensagem de consentimento separadamente, fazendo múltiplas alterações em diferentes partes do código, simplesmente redefinimos os elementos text() e heading() (do @metamask/snaps-sdk), para que primeiro passem seu conteúdo pela função escapeMarkdown() e só então o renderizem. Isso nos permitiu simplesmente substituir as expressões import em todos os arquivos com mensagens de consentimento pelos nossos elementos personalizados, em vez de corrigir cada invocação de text() e heading() separadamente, o que foi uma correção muito mais limpa.

A resolução eficaz não apenas melhora o problema específico, mas também protege preventivamente contra vulnerabilidades não detectadas.

Comentário da Diligence Com muita frequência, vemos projetos adotarem uma abordagem de "apagar incêndios" para a segurança, corrigindo cada problema individual à medida que ele aparece, sem considerar a classe de vulnerabilidade subjacente. Ao abordar a causa raiz dos problemas e não hesitar em eliminar classes de vulnerabilidade globalmente, o MSQ demonstra que entende a segurança não como uma série de patches, mas como uma disciplina holística. Como especialistas em segurança, só podemos recomendar aos nossos clientes que não se apressem nas correções e dediquem tempo suficiente para transformar uma descoberta de segurança em um evento que tenha um efeito positivo na segurança do projeto.

Conclusão

Com isso, concluímos nossas percepções sobre como navegar com sucesso por uma auditoria de segurança do MetaMask Snaps. Seguir essas diretrizes ajudou a equipe MSQ a receber um relatório positivo da equipe Diligence. Esperamos que compartilhar a experiência do MSQ ajude você em suas preparações para auditoria de segurança, garantindo um processo completo e eficaz.

A Consensys Diligence ajudou uma ampla gama de projetos em todo o ecossistema blockchain a garantir que seus protocolos estejam prontos para o lançamento e construídos para proteger os usuários. Ficamos felizes em verificar seu Snap em busca dessas e de outras vulnerabilidades em uma auditoria personalizada. Entre em contato e solicite um orçamento!