Lista de Verificação de Segurança DeFi Antes de Assinar uma Transação

Porque é que uma lista de verificação de segurança em DeFi importa mais do que um "bom projeto"

Se passou algum tempo no Twitter cripto, já viu publicações que parecem obituários: uma carteira drenada, uma aprovação de tokens explorada, um site de airdrop falso, uma ponte que enviou silenciosamente fundos para um atacante. O detalhe que quase nunca é mencionado é que o utilizador, e não o protocolo, clicou no último botão. O protocolo pode ser honesto, auditado e bem conhecido, e ainda assim pode perder tudo ao assinar a coisa errada no sítio certo.

Isto parece desolador, mas é na verdade uma boa notícia. Significa que o modo de falha é humano e processual, não criptográfico. Não há nenhuma exploração para corrigir, nenhum zero-day para esperar. Há uma rotina para construir, e a rotina cabe num cartão de índice. O objetivo desta lista de verificação de segurança em DeFi é dar-lhe essa rotina: um pequeno conjunto de verificações que executa sempre pela mesma ordem, antes de assinar uma transação numa carteira de autocustódia.

Antes de percorrer os sete passos, ajuda dar nome ao que está efetivamente a defender. Três padrões são responsáveis pela esmagadora maioria das perdas reais para utilizadores comuns, e cada um é tratado por um passo específico mais à frente neste artigo.

• Phishing e sites imitadores. Um domínio que parece idêntico a um real, mas registado por um atacante. Um resultado de pesquisa, um anúncio ou uma ligação paga podem levá-lo até lá.
• Aprovações mal compreendidas. Assina uma aprovação de tokens que concede a um contrato permissão para mover um token da sua carteira, às vezes em quantidade ilimitada, e essa permissão vive on-chain até a revogar.
• Transações com aparência de não-assinatura que fazem algo inesperado. Um botão de "reclamar airdrop" que é na verdade uma aprovação de tokens, uma "troca" que é uma assinatura permit que permite a terceiros mover os seus fundos, ou uma ponte que deposita num contrato com uma backdoor.

Os riscos reais: como os utilizadores de DeFi efetivamente perdem dinheiro

Vale a pena ser concreto sobre os modos de falha, porque avisos abstratos sobre "fazer a sua própria investigação" não mudam comportamentos. Alguns padrões são responsáveis pela maioria das perdas, e cada um é evitável com um hábito específico.

Os drenos baseados em aprovações são a maior categoria individual. Quando troca um token numa exchange descentralizada, o site pede-lhe normalmente que aprove o contrato do router para gastar esse token em seu nome. Essa aprovação fica armazenada on-chain e sobrevive entre sessões. Se o contrato do router for mais tarde atualizado, sequestrado ou nunca tiver sido de confiança, o atacante pode chamar transferFrom nessa aprovação e mover os seus tokens a qualquer momento. Aprovações ilimitadas são convenientes, mas são também uma responsabilidade de longa duração. Uma regra prática útil: trate cada aprovação como uma chave que está a entregar a um estranho e pergunte quanto tempo quer que essa chave dure.

Assinaturas permit (EIP-2612) e assinaturas off-chain acrescentam uma segunda camada. Algumas dapps pedem-lhe que assine uma mensagem em vez de uma transação. A mensagem pode parecer um disparate, mas pode conceder o mesmo poder de gasto que uma aprovação, sem custo de gás e sem registo on-chain por defeito. Ferramentas que descodificam assinaturas existem precisamente porque este formato é fácil de usar indevidamente. Se assinar um permit de um site malicioso, o atacante pode submetê-lo on-chain mais tarde e mover os seus tokens sem qualquer interação adicional da sua parte.

Pontes e trocas cross-chain são um terceiro ponto crítico. Fazer bridge de ETH da mainnet para ARB ou versões wrapped de SOL envolve normalmente bloquear fundos num contrato na cadeia de origem e cunhar um equivalente wrapped no destino. Bugs em contratos de ponte produziram algumas das maiores perdas na história da DeFi, e a superfície de ataque é mais ampla do que numa troca típica. Fazer bridge tende também a ser uma das operações em que os utilizadores toleram mais fricção, que é exatamente quando os scammers pressionam mais.

Por fim, há o velho e simples falhanço de higiene da carteira. Uma única hot wallet que foi usada para assinar aprovações para vinte dapps diferentes ao longo de dois anos é um ponto único de falha. Revogar aprovações antigas é um hábito real e útil, não paranoia. Sites como revoke.cash existem para facilitar isto, e uma passagem trimestral por eles vale bem os dez minutos.

Passo 1: Aceda ao URL correto, pelo método convencional

Antes de fazer qualquer outra coisa, confirme que está no site verdadeiro. A maioria dos ataques de phishing não é sofisticada; trata-se de um anúncio pago nos resultados de pesquisa ou de uma publicação patrocinada numa rede social que aponta para um domínio que difere do legítimo por um caractere, ou por um carácter Unicode visualmente idêntico. O "l" num URL pode não ser um L minúsculo latino. Pode ser um carácter cirílico que é renderizado de forma idêntica. A única defesa fiável é nunca chegar a um site DeFi através de uma ligação que não tenha criado pessoalmente.

Digite o domínio na barra de endereço ou utilize um marcador que criou na primeira vez que visitou o site legítimo. Se alguém num canal de Discord lhe enviar uma ligação para "a página do airdrop", parta do princípio de que é maliciosa até prova em contrário, independentemente de o nome de utilizador parecer plausível. Verifique o URL caractere a caractere. Confirme o contrato num explorador de blocos como o Etherscan antes de ligar a sua carteira ou assinar qualquer coisa; o endereço do contrato na página verificada do explorador é a fonte de verdade, não o endereço mostrado numa janela pop-up ou num tweet.

Há mais dois hábitos que ajudam. Primeiro, guarde o domínio verdadeiro nos marcadores desde o primeiro dia e nunca clique numa ligação que contorne esse marcador. Segundo, se um site lhe pedir para ligar uma carteira, o pedido de ligação na sua carteira é o momento para parar, não para apressar. Leia o pedido na carteira, não apenas a página web.

Passo 2: Compreenda exatamente que aprovação está a ser solicitada

Uma aprovação é uma permissão separada e persistente na blockchain. Quando assina uma, não está a fazer uma única transação. Está a dizer a um contrato inteligente que, desde agora até a aprovação ser revogada ou gasta, ele pode mover uma determinada quantidade de um determinado token da sua carteira em seu nome. Se aprovar o contrato errado, o atacante pode drenar esse token mais tarde, sem qualquer ação adicional da sua parte.

A maioria das carteiras, incluindo as principais, já mostra o valor em formato legível no ecrã de confirmação. O número a ter em atenção é o segundo, não o primeiro. Se o site diz "trocar 100 USDC por ETH" e o pedido da carteira diz "aprovar USDC sem limite", está a ser solicitado mais do que a troca exige. Para contratos grandes ou desconhecidos, defina uma allowance personalizada suficiente apenas para cobrir a transação e, em seguida, revogue-a depois. O atrito é real. A alternativa é pior.

Preste especial atenção a aprovações de stablecoins como USDC e USDT, e de tokens de elevado valor como ETH. Uma aprovação ilimitada de USDC a um router malicioso é funcionalmente equivalente a entregar a alguém um cheque em branco assinado sobre o seu saldo de stablecoins. Note também que algumas dapps começaram a usar assinaturas permit2 ou EIP-2612 em vez de aprovações on-chain, o que pode acarretar o mesmo risco sem aparecer numa lista típica de aprovações. Se um site lhe pedir para assinar uma mensagem em vez de uma transação, trate-a com a mesma desconfiança que uma aprovação ilimitada.

Passo 3: Simule a transação antes de assinar

As ferramentas de simulação executam a sua transação contra o estado atual da cadeia numa sandbox e mostram-lhe o que ela fará: que contratos serão chamados, que tokens serão movidos e como ficarão os seus saldos depois. Duas opções conhecidas são Tenderly e Blowfish, e muitas carteiras já trazem simulação integrada. Se a sua carteira tiver um painel de simulação, leia-o. Se não tiver, execute primeiro a transação num simulador externo.

O que procurar é qualquer linha que não corresponda à sua intenção. Se pretendia trocar 100 USDC por ETH e a simulação mostra a movimentação de um token diferente, ou de um valor diferente, ou a definição de uma aprovação, pare. Se a simulação mostra que a transação vai falhar on-chain, poupará gás e tempo ao não a enviar. Se mostrar uma chamada de contrato para um endereço que não consegue identificar, não assine.

A simulação não é uma bala de prata. Atacantes sofisticados podem criar transações cujo comportamento malicioso só se ativa em condições específicas, e uma simulação estática pode não detetar isso. Mas para o caso comum de um utilizador prestes a cometer um erro de digitação ou a aterrar num site de phishing, a simulação é um dos hábitos com maior retorno que pode adotar, e é gratuita.

Passo 4: Use uma carteira de "navegação", separada da carteira de "assinatura"

As configurações com uma única carteira são a razão mais comum para um pequeno erro se transformar numa perda total. A solução é estrutural: mantenha uma carteira para a interação quotidiana em DeFi e uma segunda, financiada apenas quando necessário, para armazenamento. Este é o hábito mais importante de toda a lista e o mais fácil de adiar.

Na prática: a sua carteira de "navegação" ou "quente" guarda pequenas quantias, liga-se a dapps e assina aprovações. A sua carteira "cofre" ou "fria" guarda a maior parte dos seus fundos e raramente se liga a qualquer coisa. Quando quiser fazer algo relevante, envie apenas o valor de que precisa do cofre para a carteira quente, execute a operação e (se apropriado) devolva o saldo restante. Se a carteira quente for comprometida, a perda está limitada ao que nela se encontrava no momento.

Este padrão também lhe permite usar uma carteira limpa para a primeira interação com um novo protocolo. A primeira vez que visita um site, está no maior risco de aterrar numa variante de phishing. Fazer essa primeira visita com uma carteira vazia não lhe custa nada se correr mal. Só depois de ter confirmado o contrato, guardado o URL nos marcadores e visto uma transação bem-sucedida é que deve considerar mover fundos reais para lá.

A mesma lógica aplica-se a cadeias nas quais ainda não confia. Se está a experimentar uma nova bridge para SOL pela primeira vez, faça-o a partir de uma carteira que guarde uma pequena quantia, não da carteira que contém a sua reserva principal. Novas cadeias, novos contratos e novas bridges são onde tende a concentrar-se o phishing mais agressivo.

Passo 5: Atenção à cadeia e ao ativo

Uma parte surpreendentemente grande dos pedidos de suporte do tipo "para onde foram os meus tokens" vem de um simples erro de cadeia. O utilizador ligou a sua carteira, viu um saldo que parecia correto e aprovou uma transação numa cadeia que não era a sua intenção. O caso mais comum é ETH na mainnet versus uma L2 como ARB, ou uma cadeia EVM versus SOL: o formato do endereço é semelhante, a dapp é semelhante, o URL é semelhante, e o utilizador não repara em que rede está a sua carteira naquele momento.

Verifique o indicador de rede na sua carteira em cada transação. Verifique o símbolo do ativo: "USDC" na mainnet não é o mesmo contrato que "USDC" na ARB, e nenhum deles é a versão bridged emitida por uma bridge de terceiros. Se um site diz que aceita USDC e a sua carteira está a mostrar a USDC da rede errada, a aprovação que está prestes a assinar pode ser para um token que o site não consegue realmente receber, ou pior, para um token que o site consegue receber e vender em seu benefício.

Para SOL, aplicam-se hábitos equivalentes. As carteiras de SOL mostram um indicador de rede claro, e o universo de tokens SPL é grande o suficiente para que um token de phishing consiga imitar um real. Verifique o endereço de mint do token num explorador de blocos em vez de confiar no símbolo numa lista. O mesmo princípio aplica-se a todos os ecossistemas: o identificador on-chain é a verdade, o símbolo é um rótulo.

Passo 6: Revogar aprovações antigas com regularidade

As aprovações são persistentes. Uma vez que concede a um contrato permissão para mover os seus USDC, essa permissão permanece até ser revogada, mesmo que nunca mais utilize a dapp. Se o contrato for mais tarde explorado, atualizado de forma maliciosa, ou sempre tiver sido uma burla, os seus tokens ficam acessíveis através dessa aprovação antiga. É por isso que uma passagem periódica de revogação faz parte da rotina, e não uma tarefa pontual.

Ferramentas como revoke.cash tornam isto simples. Elas leem a cadeia, listam todas as aprovações atuais e permitem submeter uma transação de revogação para qualquer uma delas. Uma cadência razoável é uma vez por trimestre, ou imediatamente após qualquer interação com uma dapp que não planeia voltar a usar. A revogação custa gas, mas alguns dólares de gas são um preço pequeno comparado com a perda do saldo subjacente.

Duas notas práticas. Primeiro, não precisa de revogar todas as aprovações de cada vez; concentre-se nas aprovações ilimitadas e em contratos que já não reconhece. Segundo, ao revogar, também está a confirmar que a dapp ainda está a funcionar, o que é um efeito colateral útil: uma dapp que ficou offline pode ter deixado os seus contratos sob novo controlo, e ao revisitá-la para revogar, pode atualizar os seus marcadores em conformidade.

Passo 7: Ler o pedido da carteira, sempre

O ecrã de confirmação da carteira é a última linha de defesa, e é aquele que os utilizadores saltam com mais frequência. É também onde aparece a informação mais relevante: o endereço do contrato que está a ser chamado, a função que está a ser invocada, o ativo e o montante, e qualquer payload de assinatura. Lê-lo demora alguns segundos. Saltá-lo pode custar tudo.

Concretamente, verifique quatro coisas. O endereço do contrato: cole-o num explorador de blocos e confirme que é o contrato que esperava, com o estado de verificação que esperava. A função: "approve" é diferente de "swap", e uma assinatura "permit" é ainda diferente. O montante: um número personalizado é diferente de "unlimited", e "0" geralmente significa que está a assinar um cancelamento, o que é positivo. O endereço de receção: se o pedido mostrar uma transferência para um endereço que não reconhece, pare.

Se alguma destas quatro verificações não corresponder ao seu modelo mental do que está a fazer, não assine. Feche o pedido, reveja o site a partir do seu marcador e comece de novo. A frase mais cara em DeFi é "tenho a certeza, basta assinar". A mais barata é "deixe-me reler isto".

O que fazer se algo correr mal

Mesmo com uma rotina perfeita, acontecem erros. A resposta importa tanto quanto a prevenção, e os primeiros minutos são os que contam. Se perceber a meio da assinatura que algo está errado, não assine. Se já assinou e agora suspeita da aprovação, vá diretamente a revoke.cash e revogue a aprovação a partir de um dispositivo limpo. Se os fundos já foram movidos, geralmente são irrecuperáveis on-chain, e qualquer pessoa que o contacte a prometer recuperá-los mediante pagamento está a aplicar uma segunda burla sobre a primeira.

Para além do momento imediato, alguns hábitos tornam incidentes futuros sobrevíveis. Mantenha um registo escrito de que carteira guarda o quê, para poder agir rapidamente sem ter de perceber tudo sob pressão. Mantenha um saldo pequeno "de estreia" em qualquer carteira nova que utilize. Pratique o fluxo de revogação uma vez, numa aprovação de teste, antes de precisar dele sob pressão. Nada disto é entusiasmante. Tudo isto funciona.

O resumo honesto é este: a segurança em DeFi não se trata de encontrar um protocolo que não possa ser atacado, porque esse protocolo não existe. Trata-se de reduzir o raio de ação dos erros que inevitavelmente vai cometer, e de tornar o custo desses erros suficientemente pequeno para serem recuperáveis. A lista de verificação acima é uma rotina pequena e aborrecida. É esse o objetivo. Rotinas aborrecidas são aquelas que as pessoas realmente seguem.

Como seguir a segurança em DeFi de forma inteligente

DeFi move-se depressa, e a notícia em torno dela também: novos exploits, novas campanhas de phishing, atualizações de contratos, encerramentos de pontes. Tentar acompanhar o sinal manualmente, especialmente em várias chains como Ethereum, Arbitrum e Solana, é um jogo perdido. O Zippfeed destaca notícias de DeFi e segurança com classificação de sentimento, bullish, neutral ou bearish, e uma avaliação de importância, para que possas detetar protocolos arriscados e avisos de sites falsos antes de chegarem à tua wallet, e não depois. Combina esse feed com a lista de verificação acima, e a rotina aborrecida torna-se rápida.

Perguntas frequentes

DeFi é seguro para iniciantes?

DeFi é mais seguro para iniciantes que seguem uma rotina, e mais arriscado para quem a trata como um site qualquer. A tecnologia em si é auditada e on-chain, mas o utilizador é a última linha de defesa contra phishing, aprovações erradas e sites falsos. Se estás a começar, começa com um saldo pequeno numa wallet separada de "navegação" e só moves fundos maiores depois de teres usado um protocolo com sucesso algumas vezes. Isto é educação, não aconselhamento financeiro; faz sempre a tua própria pesquisa antes de assinar qualquer transação.

Como funciona afinal uma aprovação de token?

Uma aprovação é uma mensagem on-chain que permite a um smart contract mover um token específico da tua wallet, até um limite que defines, até a revogares. As aprovações ilimitadas são convenientes, mas dão a esse contrato um direito de gasto de longa duração. Revogar uma aprovação, através de uma ferramenta como a revoke.cash, é uma transação separada que custa gas, mas remove esse direito. Trata as aprovações como chaves e entrega-as apenas a contratos em que confias, durante o tempo que precisares.

Devo usar uma hardware wallet para DeFi?

Uma hardware wallet acrescenta uma camada forte de proteção porque a chave privada nunca toca no teu computador, mas por si só não te impede de assinar uma aprovação maliciosa. O dispositivo mostrará os detalhes da transação, o que é uma verdadeira vantagem, mas ainda tens de os ler. Combinar uma hardware wallet com a lista de verificação acima, especialmente os passos de simulação e revisão de aprovações, é uma configuração sensata para saldos maiores.

Qual é a forma mais rápida de verificar se o URL de uma dapp é real?

Não cliques em links de resultados de pesquisa, redes sociais ou mensagens diretas. Em vez disso, escreve o domínio na barra de endereço ou abre-o a partir de um marcador que criaste da primeira vez que visitaste o site legítimo. Depois, confirma o endereço do contrato num explorador de blocos. O hábito em dois passos de "URL mais endereço do contrato" apanha a grande maioria das tentativas de phishing em menos de um minuto.