Por qué se puede vaciar una billetera "sin firma"
Objetivo de esta guía: explicar cómo funcionan los permisos
(la aprobación es el acto de otorgar derechos, allowance es el límite de gasto registrado),
descomponer el principal
EVM es un grupo de redes blockchain compatibles que utilizan las mismas reglas de ejecución de contratos inteligentes,
donde la gestión de tokens y NFT se basa en un sistema de permisos.
En estas redes approve, allowance y
La principal vulnerabilidad aquí es la expectativa de que cada gasto requerirá una firma por separado. En la interfaz de una billetera, la firma parece un paso normal ("permitir", "conectar", "confirmar para el intercambio"), por lo que el usuario confirma no una transferencia, sino una concesión de derechos que se almacena en el contrato y se utiliza posteriormente sin otra ventana de confirmación.
Un allowance innecesario
(un límite registrado en el contrato que define cuántos tokens se pueden gastar)
para una moneda estable o una activa
Si evalúa el riesgo DeFi de forma más amplia que las aprobaciones, agregue superficies de ataque separadas a su lista de verificación: dApp frontends, puentes, MEV, claves y errores operativos. DeFi guía de seguridad: mapa de amenazas y lista de verificación .
El phishing de aprobación utiliza concesiones de permisos a través de approve/permit
(creando o cambiando un allowance)
o
Una firma approve/permit o
Qué es el phishing de aprobación y por qué su “honestidad” es deshonesta
Términos clave en esta sección:
-
Gastador es la dirección de contrato inteligente permitida para gastar los tokens ERC-20 del propietario
dentro de un allowance a través de
transferFrom . -
Operador es una dirección que ha recibido el derecho de transferir el NFTs del propietario a través de
setApprovalForAll , sin límite en el número de fichas de colección. - Asignación es un valor en un contrato ERC-20 que define el número máximo de tokens el spender puede gastar.
- Revoke es una transacción que restablece un allowance o deshabilita un operator, poner fin al derecho a gastar o transferir activos.
El phishing de aprobación utiliza mecanismos de permiso normales: la concesión de derechos parece legítima, no causa una pérdida inmediata de fondos y, por lo tanto, a menudo no se percibe como un riesgo en el momento de la firma.
Phishing de aprobación Es un ataque en el que se persuade a un usuario para que conceda una permiso (aprobación/allowance) para administrar tokens o NFTs, y ese derecho luego se utiliza para retirar activos. La acción peligrosa se disfraza como un paso de interfaz familiar: "confirmar para el intercambio", "permitir acuñación", "firmar para reclamar", "conceder acceso para depósito".
A diferencia del robo de claves, el atacante no necesita la clave privada y no necesita una transferencia directa de fondos. Basta con que el usuario una vez otorgar a una dirección específica el derecho a gastar activos: un spender para tokens ERC-20 o un operator para NFTs. Después de eso, el retiro se realiza sin nuevas ventanas de billetera y sin repetidas confirmaciones por parte del propietario.
A nivel de blockchain, las transacciones parecen válidas: el usuario realmente cambió el estado del contrato y otorgó derechos a una dirección específica. Es por eso que la billetera no es "pirateada" formalmente: los activos salen a través de permisos previamente otorgados, no a través de una omisión de la firma.
Approve normalmente no se transfiere fondos inmediatamente. Registra un límite allowance en el contrato de token, después del cual spender puede llamar
Si bien el equilibrio no ha cambiado, la firma a menudo se percibe como segura. con aprobación ilimitada o setApprovalForAll, un atacante puede retirar activos actuales y cualquier depósito futuro hasta que se restablezca allowance o se deshabilite el estado de operator.
En términos simples: approve no es una transferencia, sino una concesión de derechos de gasto a una dirección específica. El phishing de aprobación significa que se engaña al usuario para que otorgue ese derecho a una dirección controlada por el atacante mientras se presenta como un paso normal de intercambio, acuñación o reclamo.
El phishing de aprobación funciona mediante permisos válidos. El peligro aparece después de la firma, cuando se utiliza un derecho de gasto activo sin la participación del propietario.
Los permisos en EVM son registros de derechos en contratos, no acciones únicas; es por eso que approve puede permanecer activo durante meses y usarse sin una firma repetida.
Cómo funcionan los permisos en EVM: allowance, spender y “infinito approve”
Un permiso EVM es un registro de estado en un token o contrato NFT que conecta su dirección con una dirección spender/operator específica. Este registro define quién puede gastar tokens a través de
- ERC-20: approve → allowance → transferFrom
- El usuario llama approve(spender, importe) y especifica la dirección spender.
- El contrato de token almacena el allowance límite: la cantidad máxima de tokens que el spender puede gastar.
- El spender llama transferFrom y gasta tokens sin nuevas firmas hasta que allowance se convierta en 0 o se agote.
- El contrato verifica allowance durante
transferFrom ; no solicita la firma del propietario para cada gasto.
- La asignación está vinculada al propietario → spender → token
- El permiso existe solo para un token específico y un spender específico.
- Un approve para USDT no otorga acceso a USDC y no se extiende a otros contratos.
- Cada token nuevo o spender nuevo requiere un approve separado.
- La aprobación ilimitada es el valor máximo allowance
- Con approve ilimitado, el allowance almacena el valor numérico máximo.
- El spender recibe el derecho de gastar tokens de ese contrato dentro de este valor, incluidos depósitos futuros en la dirección.
- El permiso permanece activo hasta una transacción revoke, incluso si el servicio ya no se utiliza.
- NFT: setApprovalForAll es el estado operator sin límite
- setApprovalForAll(operator, verdadero) habilita el estado operator para toda la colección NFT del propietario.
- Este no es un límite por cantidad o valor: el derecho permanece hasta setApprovalForAll(operator, falso) se envía.
- Si el operator se ve comprometido, el NFTs se puede retirar sin la confirmación del nuevo propietario.
approve ilimitado para ERC-20 aumenta la cantidad máxima que se puede gastar a través de
Los permisos EVM son registros de derechos de larga duración en los contratos. Un approve puede funcionar durante meses, aumenta ilimitadamente el límite de gasto disponible y
Una firma permit (por ejemplo, EIP-2612) otorga a una aplicación el derecho de configurar allowance a través de un mensaje firmado; Luego, la aplicación usa esa firma en una transacción que otorga derechos y realiza la acción en una sola llamada.
Permiso, Permit2 y firmas de mensajes: cómo se otorgan los permisos sin un approve separado y por qué los atacantes lo usan
Además del approve ordinario, EVM tiene formas de otorgar permiso sin una transacción separada. El usuario simplemente firma un mensaje, y la aplicación usa esa firma en su propia transacción, que otorga el derecho de gasto y realiza la acción: canje, depósito o reclamación. Estas mecánicas se llaman permit y extensiones como Permit2.
Desde el punto de vista de UX, esto parece menos pasos: no hay una transacción approve separada y no se requiere gas para una llamada approve separada. La consecuencia técnica es la misma: un derecho de gasto aparece en el contrato, y ese derecho puede permanecer activo más allá de una sola operación si los parámetros de la firma establecen un límite amplio o un vencimiento prolongado.
Los dos tipos de confirmación que los usuarios suelen confundir:
- Transacción (en cadena): approve / revoke / transferencia: enviado a la red, requiere gas y cambia el estado del contrato.
- Firma del mensaje (fuera de la cadena): permit y mecánicas similares: no se necesita gas en el momento de la firma, pero permiten que una aplicación instale los mismos derechos de acceso.
| ⚙️ Mecanismo | 🧾 Lo que otorgas | 📍Dónde aparece | ⚠️ Riesgo clave |
|---|---|---|---|
| Approve (ERC-20) | Límite de gasto de tokens para un spender | DEX, préstamos, agricultura, puentes | Ilimitado allowance permanece activo hasta revoke |
| Permiso (EIP-2612 y análogos) | Permiso mediante firma sin approve aparte | Swaps, agregadores, interfaces DeFi “con un solo clic” | La firma parece “segura” pero establece derechos reales |
| Establecer aprobación para todos (NFT) | Acceso global a toda la colección. | Mercados, casas de moneda, juegos dApps | NFTs se puede transferir sin repetidas confirmaciones |
Matiz clave: approve y permit conducen al mismo resultado: una dirección específica recibe el derecho de administrar los activos del propietario. El formulario de confirmación difiere: una transacción en cadena o una firma de mensaje que luego se utiliza dentro de una transacción.
Lista de verificación previa a la firma (30 segundos): un filtro rápido para ver si una firma otorga derechos de gasto.
- ¿Qué se está confirmando? Permiso o approve significa una concesión de acceso.
- ¿Quién recibe acceso? Mire spender o operator en los parámetros, no en el diseño del sitio.
- ¿Cuál es el límite? Ilimitado en tokens líquidos aumenta el monto de gasto disponible.
- ¿Existe setApprovalForAll? Para NFTs, este es el estado operator completo de la colección.
- ¿Hay urgencia? La presión del tiempo se utiliza a menudo para hacer que la gente firme sin comprobar los parámetros.
El permiso y las “firmas sin gas” cambian sólo la forma de confirmación. Una firma de mensaje puede instalar derechos de acceso a tokens o NFTs al igual que approve, por lo que los parámetros de firma deben leerse como concesiones de permisos.
En los esquemas típicos de phishing de aprobación, se lleva al usuario a firmar approve/permit o
Esquemas típicos de phishing de aprobación: cómo llegar a la firma "correcta"
Estos esquemas utilizan interfaces familiares y flujos de trabajo estándar, lo que hace que la concesión de permisos parezca un paso de servicio normal.
Casi todos los ataques siguen la misma lógica: primero, el usuario es llevado a una página que parece una interfaz dApp, luego la página solicita una firma que otorga un derecho de gasto o un derecho operator, y luego el permiso activo se utiliza para retirar activos sin nuevas confirmaciones.
La característica clave es la ausencia de una solicitud directa para enviar una transferencia. En lugar de una transferencia, el sitio solicita approve/permit o
- Clon de un servicio popular
- Un dominio falso o un enlace publicitario conduce a una copia visualmente similar de un DEX o mercado.
- La interfaz solicita approve “para intercambio” o
setApprovalForAll “para listado NFT”. - Los parámetros de firma contienen un spender/operator que no pertenece al servicio real.
- Compromiso de canales oficiales
- Se publica un enlace en Discord, Telegram o X en nombre del proyecto o de un moderador.
- Se utilizan desencadenantes de urgencia: “error de contrato”, “migración de menta”, “última oportunidad”.
- El enlace conduce a una página que solicita approve/permit para la dirección del atacante.
- Ingeniería social a través del “apoyo”
- El atacante envía un mensaje privado haciéndose pasar por servicio de soporte.
- Se solicita una firma con el pretexto de “cancelar una transacción estancada”.
- En la práctica, el usuario firma un permit o otorga approve a una dirección de terceros.
- Sustitución del significado de la firma.
- La ventana de la billetera muestra una llamada técnica sin una explicación clara en la interfaz.
- El usuario confirma sin verificar la dirección spender/operator y el límite.
- El riesgo es mayor cuando la interfaz no muestra el tipo de límite, permiso o límite spender.
Ejemplo: un usuario conecta una billetera a una página de “airdrop”, hace clic en Reclamar y firma un approve ilimitado para una moneda estable. El saldo no cambia, pero luego, cuando llegan los fondos, el spender retira los tokens a través de
Estos ataques no requieren una retirada inmediata. El atacante puede esperar a que crezca el saldo o que llegue liquidez y luego utilizar el permiso activo.
Los esquemas típicos de phishing de aprobación disfrazan la concesión de derechos como acciones familiares. Mientras el estado allowance o operator esté activo, el atacante puede usarlo en cualquier momento sin la confirmación del nuevo propietario.
Asignación y
Errores comunes de los usuarios: por qué las aprobaciones se acumulan y se convierten en una amenaza
El peligro de las aprobaciones rara vez se siente en el momento de la firma porque approve generalmente no cambia el equilibrio. El riesgo aparece más tarde, cuando se utiliza un permiso activo para gastar, y se vuelve más fuerte si dichos permisos permanecen en varias redes y varios tokens.
El error más común: aprobaciones ilimitadas para monedas estables y tokens líquidos. Al momento de firmar, esto parece tener menos pasos, pero técnicamente significa un allowance grande que permite al spender gastar tokens.
La misma lógica se aplica a
Una clase separada de errores proviene de confiar en la marca y el diseño visual. El usuario se centra en el dominio, el logotipo o el diseño, pero siempre se concede permiso a una dirección específica. spender o operator. Si se sustituye la interfaz, el diseño no cambia la dirección en los parámetros de la firma.
Otro error común es considerar cerrado el problema después de revoke en una red. Las aprobaciones están aisladas por red: allowance en Ethereum y allowance en Arbitrum son registros diferentes en contratos diferentes, por lo que un permiso puede permanecer activo en otra red.
Si mueve liquidez entre redes, verifique las aprobaciones después de las operaciones entre cadenas: los puentes y enrutadores a menudo requieren approve para un spender separado en cada red. Puentes criptográficos: cómo funcionan y cuáles son más seguros.
Las firmas sin gas crean confusión adicional. Los permisos y mecanismos similares se perciben como confirmaciones "suaves", pero el resultado es el mismo: la aplicación recibe la capacidad de instalar un permiso que luego se utiliza para gastar.
Los errores se vuelven más peligrosos cuando una billetera se usa al mismo tiempo para almacenamiento, comercio activo y experimentos. En ese modo, un spender/operator innecesario crea acceso a activos que no formaban parte de la operación original.
La principal amenaza de las aprobaciones son los permisos activos que permanecen en los contratos una vez completada una tarea. allowance ilimitado, un NFT operator habilitado y permisos en varias redes aumentan la cantidad de activos disponibles para gastar sin nuevas confirmaciones.
Los permisos se deben verificar por separado para cada red: las listas allowance y operator en Ethereum no coinciden con Arbitrum, Optimism, Polygon o BSC, porque los registros de derechos se almacenan en contratos en la red específica.
Dónde comprobar los permisos: qué inspeccionar exactamente y en qué orden
La revisión de permisos es una secuencia de pasos por red y tipo de activo. Los tokens ERC-20 y NFTs utilizan diferentes mecanismos de acceso, por lo que deben analizarse por separado y cerrarse en orden de prioridad: primero las direcciones desconocidas y los límites amplios, luego los permisos de trabajo restantes.
- Identificar la red con mayor actividad
- Los permisos no son “globales”: Ethereum, Arbitrum, Optimism, Polygon y BSC tienen listas de aprobación independientes.
- Comience con la red donde se concentra la liquidez y donde ocurrieron las últimas transacciones.
- Consulta las aprobaciones ERC-20 y reduce lo innecesario
- La prioridad es para spender desconocidos y allowance ilimitados en monedas estables y tokens líquidos.
- Elimine los permisos no utilizados y reduzca los límites a la cantidad necesaria para la operación actual.
- Verifique las aprobaciones NFT por separado
- Preste especial atención a
setApprovalForAll para mercados y juegos dApps. - Mantenga un operator activo solo durante el período en que sea realmente necesario.
- Preste especial atención a
- Verifica las direcciones que dejas activas
- Haga coincidir las direcciones spender/operator con servicios confiables mediante la dirección en la firma o el explorador.
- Si una dirección no es reconocible, restablezca allowance o desactive operator y otorgue un nuevo permiso solo cuando sea necesario.
| Enfoque | lo que comprueba | lado fuerte | Limitación |
|---|---|---|---|
| Escáner de cadena de bloques de red | ERC-20 allowance y, a menudo, aprobaciones NFT | Datos de red, sin confiar en una interfaz dApp | Necesitas cambiar de red y analizar direcciones. |
| Servicios Revoke | Permisos Token y NFT en la red seleccionada | Lista + botón para restablecer allowance/desactivar operator | La cobertura depende de la red y las integraciones. |
| Carteras con simulación | Gastador, límites, advertencias antes de firmar | Muestra qué dirección recibirá derechos antes de la confirmación. | Pantalla de aprobación con diferente profundidad |
Qué buscar en una lista de permisos
- spender o operator desconocido. Si la dirección no es reconocible, es candidata revoke.
- allowance ilimitado sobre activos líquidos. Un allowance grande aumenta el monto de gasto disponible.
- Permisos en L2s y cadenas laterales. Las aprobaciones pueden permanecer activas en redes en las que no haya realizado transacciones durante mucho tiempo.
- NFT operators sin necesidad actual. Un operator activo puede transferir NFTs sin nuevas confirmaciones.
- Contratos de proxy y actualizaciones. Approve está vinculado a la dirección spender, por lo que un permiso antiguo permanece activo incluso si la lógica cambia mediante una actualización.
Lógica de revisión: primero restablezca los allowance para direcciones desconocidas y elimine los permisos ilimitados en tokens confidenciales, luego reduzca los límites restantes a la cantidad necesaria para las operaciones actuales.
La revisión de permisos debe coincidir con la forma en que se almacenan los permisos: redes separadas, tokens separados, spenders/operators separados. Priorizar permisos desconocidos e ilimitados cierra los principales escenarios de gasto sin nuevas confirmaciones.
Revoke es una transacción que establece allowance en 0 para el propietario → spender → par de tokens o conmutadores
Cómo obtener permisos revoke correctamente: tokens, NFTs y errores comunes
Revoke es una transacción en cadena que cambia allowance o deshabilita un NFT operator. Como resultado, el contrato registra un nuevo estado: una dirección específica ya no tiene derecho a administrar sus bienes. Revoke detiene gastos futuros, pero no revierte transacciones que ya se han ejecutado.
Algoritmo revoke paso a paso para ERC-20
- Identificar la red. Las aprobaciones están aisladas por red: Ethereum, Arbitrum, Optimism y otros L2s tienen listas de permisos independientes.
- Busque el token y spender. Verifique la dirección del contrato del token, el nombre del token y el límite allowance actual, especialmente para monedas estables y activos líquidos.
- Realice revoke. La opción estándar es configurar allowance en 0 hasta approve(spender, 0) o usar un botón revoke en un servicio.
- Comprueba el resultado. Asegúrese de que allowance se convierta en 0 y que el permiso ya no se muestre como activo.
Algoritmo revoke paso a paso para NFTs
- Abra la lista de colección operator. buscar activo
setApprovalForAll entradas y direcciones operator relacionadas. - Deshabilite el operator. El estado debe cambiarse a falso.
- Repita para las colecciones de claves. Verifique primero los cobros con mayor valor y liquidez.
Error común: revoke se realiza en una red mientras que el estado allowance o operator permanece activo en otra. Si utilizó puentes, agregadores y multired dApps, verifique las aprobaciones en cada red por separado.
ERC-20 matiz: algunos tokens requieren la secuencia approve(spender, 0) antes de configurar un nuevo allowance. En esos casos, revoke comienza restableciendo el límite.
Revoke cambia el registro de derechos en el contrato: allowance se convierte en 0 o operator se desactiva. Para que revoke realmente cierre el acceso, se debe realizar en la red correcta y para el par token→spender o colección→operator correcto.
Si concedió approve/permit o
Si ya concediste un approve peligroso: un plan rápido de reducción de daños
En esta situación, el orden de las acciones importa: primero retire los activos de los permisos activos, luego restablezca allowance y deshabilite operator, y solo después investigue el origen de la firma.
si
- Mueva los activos a una dirección "limpia". Una nueva billetera con una nueva frase inicial rompe la conexión con las aprobaciones actuales porque allowance y operator están vinculados a la dirección del propietario anterior.
- Permisos Revoke en la dirección comprometida. Restablezca allowance primero para las monedas estables y los tokens líquidos, luego para los tokens restantes.
- Verifique los permisos NFT. Desactivar
setApprovalForAll para operator que no son necesarios. - Desconecte las sesiones dApp en la billetera. Esto no cambia allowance, pero elimina las sesiones activas del sitio que pueden solicitar otra firma.
- Aislar el ambiente. Si existe riesgo de extensión maliciosa o sustitución de sitio, utilice otro navegador o dispositivo.
No acepte “transferencias de prueba”, “controles de seguridad” o “recuperación de fondos” sugeridas por extraños. Estas solicitudes se utilizan a menudo para obtener una nueva firma o una transferencia directa.
Después de que se haya otorgado un permiso peligroso, la prioridad es reducir la cantidad de activos a los que se puede acceder a través de allowance/operator y luego restablecer esos derechos con las transacciones revoke. Mientras los derechos sigan activos, el gasto puede realizarse sin nuevas confirmaciones.
Prevenir el phishing de aprobación se reduce a controlar dos parámetros: quién recibe el derecho (spender/operator) y qué tan grande o amplio es ese derecho (allowance o
Prevención: cómo conceder permisos sin convertirse en un blanco fácil
La prevención de phishing de aprobación se basa en la gestión de permisos: separar los roles de billetera, limitar allowance y deshabilitar operator una vez completada la tarea.
La mayoría de las pérdidas están ligadas a permisos activos que permanecen en los contratos una vez finalizada una operación: allowance ilimitado, un NFT operator habilitado y el hábito de confirmar firmas sin verificar la dirección. Estos registros de derechos permiten realizar gastos sin nuevas confirmaciones hasta revoke.
Separar roles de billetera
El uso de una dirección para almacenamiento, comercio y experimentos hace que cualquier approve sea crítico para todo el saldo de esa dirección. La separación de direcciones limita la cantidad de activos expuestos a través de allowance o operator. Si elige una billetera de “almacenamiento” a largo plazo, comience con una revisión de billetera criptográfica de hardware y configure el almacenamiento en frío antes del trabajo activo DeFi.
🧩 Configuración básica de tres direcciones
- Almacenamiento (largo plazo): capital principal, interacciones mínimas dApp, sin aprobaciones activas.
- Dirección operativa: actividad regular DeFi, saldo limitado, revisión programada allowance y operator.
- Dirección experimental: lanzamientos aéreos, NFTs, nuevos proyectos; El riesgo se limita a la cantidad almacenada en él.
Reducir el alcance de cada permiso
Incluso cuando trabaje con servicios confiables, considere el escenario de un error o compromiso spender/operator. Para ERC-20, el alcance del derecho está definido por allowance; para NFTs, el alcance está definido por
- Utilice límites exactos. La asignación define la cantidad máxima de tokens que un spender puede gastar.
- Restablezca allowance una vez completada la tarea. Esto pone fin al gasto
transferFrom . - Verifique la dirección spender. El permiso se otorga a la dirección en los parámetros de firma, no a un "sitio".
- Deshabilite setApprovalForAll después de la tarea. El operador no debe permanecer activo después de cotizar en bolsa o de una sesión de juego.
- No confirmar por urgencia. A menudo se utiliza la urgencia para que no se inspeccione la firma.
Modo de revisión: cuándo comprobar las aprobaciones
- Después de una operación única. Si el servicio no se utiliza con regularidad, reinicie allowance o desactive operator una vez completada la operación.
- Para una dirección operativa DeFi. Con actividad constante, revise las aprobaciones una vez cada una o dos semanas y elimine los permisos innecesarios.
- Para una dirección experimental. Para nuevos dApps y lanzamientos aéreos, verifique y cierre los permisos después de cada sesión.
Modelo de trabajo: approve/permit otorga un derecho a una dirección específica, allowance define el límite, revoke cambia el límite a 0 o deshabilita operator.
La prevención de aprobación es la gestión activa de permisos: la separación de direcciones, los límites exactos de allowance y la desactivación de operator después de la tarea reducen la cantidad de activos disponibles para gastar sin nuevas confirmaciones.
Approve permite llamar a los protocolos
Approve como mecanismo: fortalezas y riesgos incorporados
Approve es la base de la infraestructura DeFi: permite que los protocolos realicen operaciones a través de
El mecanismo approve es una compensación entre mantener los activos en su propia dirección y automatizar las acciones del protocolo. Los activos permanecen en su dirección, pero el contrato recibe el derecho de gastarlos dentro del allowance establecido en approve.
✅ Puntos fuertes de approve
- Los activos permanecen en la dirección del propietario hasta que se gasten
transferFrom . - Los protocolos pueden realizar operaciones sin una firma para cada paso utilizando allowance.
- La asignación permite limitar el monto máximo de gasto para un spender específico.
- Los permisos son verificables en cadena y se pueden restablecer con una transacción revoke.
❌ Riesgos incorporados de las aprobaciones
- Un permiso permanece activo hasta revoke y no depende de cerrar un sitio o desconectar una billetera.
- allowance ilimitado aumenta la cantidad de tokens disponibles para gastar si el spender se ve comprometido.
- Si approve se firma sin verificar spender y el límite, es posible que se otorgue el derecho a la dirección incorrecta.
Establecer aprobación para todos para NFTs le otorga a operator el derecho de transferir toda la colección con una sola acción.
Approve es un mecanismo de infraestructura para gestionar derechos. Es conveniente porque la transferencia se ejecuta a través de allowance sin firmas repetidas y arriesgado porque un permiso activo funciona hasta revoke y puede usarse para gastar más tarde.
Casos y lecciones: por qué un “contrato correcto” aún puede convertirse en un problema
Incluso cuando se trabaja con servicios legítimos, las aprobaciones activas crean riesgos: una vulnerabilidad, actualización o sustitución de frontend se vuelve peligrosa si allowance ya está registrado o operator está habilitado en el contrato.
La propiedad clave de las aprobaciones es la ausencia de una “vida útil”. Si se ha concedido un permiso, el contrato no necesita volver a solicitar approve: utiliza los derechos ya registrados. Por lo tanto, el riesgo depende no sólo del servicio actual, sino también de la lista de aprobaciones acumuladas en la dirección.
🔓 Caso 1: vulnerabilidad en un protocolo legítimo + aprobaciones ilimitadas
Un usuario otorga approve ilimitado a un protocolo y luego se encuentra un error en la lógica de gasto eso permite que el contrato gaste más tokens de lo esperado.
- El contrato ya incluye el derecho de gasto hasta allowance, por lo que el ataque no requiere la firma de un nuevo propietario.
- allowance ilimitado aumenta el monto del gasto hasta el saldo del token en la dirección del propietario.
- Los usuarios que no realizan nuevas transacciones siguen siendo vulnerables hasta que se restablezca el allowance.
Unlimited approve convierte un error de protocolo en un riesgo para todo el saldo del token en la dirección. Exact allowance limita el gasto máximo y revoke finaliza el gasto correctamente.
🧩 Caso 2: una actualización del contrato de proxy cambia el comportamiento de acceso
Los contratos actualizables mantienen la misma dirección, pero el código en esa dirección puede cambiar después de una actualización o compromiso de gobernanza.
- Approve está vinculado a la dirección spender, no a una versión de código específica.
- Después de una actualización, el nuevo código puede usar allowance de manera diferente a lo que esperaba el propietario.
- El antiguo allowance permanece activo hasta que una transacción lo restablece.
Cuando se actualizan los protocolos, se deben revisar las aprobaciones anteriores porque allowance permanece activo en la misma dirección spender.
🧠 Caso 3: sustitución del frontend mientras la marca sigue siendo familiar
El usuario visita un sitio familiar, pero la interfaz se sustituye por DNS, anuncios, CDN o extensiones maliciosas.
- La apariencia visual de la interfaz coincide con lo que espera el usuario.
- Approve o permit se otorga a una dirección que no es la del contrato de servicio.
- Al marcar spender/operator en la firma se revela la sustitución; la marca y el diseño no.
Confíe en la dirección spender/operator y el límite allowance en la firma, no en el dominio y el diseño de la página.
🛰️ Caso 4: agregadores y enrutadores como puerta de acceso amplio
Los agregadores y enrutadores utilizan un spender para muchas rutas y protocolos.
- Una dirección spender sirve para muchos escenarios y muchos tokens.
- Si el spender se ve comprometido, el riesgo se extiende a todos los que lo otorgaron allowance.
- Ilimitado allowance aumenta el monto que se puede gastar a través de esta dirección.
Para los enrutadores, el límite allowance define el monto máximo de gasto y el revoke regular elimina los permisos antiguos que ya no son necesarios.
🖼️ Caso 5: setApprovalForAll para NFTs permanece activo durante años
- Este es el estado operator, no un límite por número de NFTs.
- Incluso sin actividad, el operator permanece habilitado en el contrato de cobro.
- El compromiso del operator hace posible transferir NFTs sin la firma de un nuevo propietario.
Deshabilitar
Un incidente se vuelve posible cuando un allowance ya está registrado o un operator está habilitado en el contrato. En ese momento, el gasto se puede ejecutar sin la firma de un nuevo propietario.
En la práctica, los incidentes ocurren porque los permisos permanecen después de completar las operaciones. La revisión periódica y la desactivación de allowance y operator innecesarios limitan la cantidad de activos disponible para gastar sin una nueva firma.
Las preguntas frecuentes ayudan a aclarar qué firmas otorgan derechos y cómo funciona revoke y por qué se puede gastar sin una confirmación repetida.
Preguntas frecuentes sobre el phishing de aprobación, approve y revoke
¿Por qué la gente dice “drenado sin firma” si firmé algo?
La firma era para otorgar derechos, no para transferir fondos. Después de approve, permit o
¿approve ilimitado es siempre un error?
Unlimited approve registra un valor muy grande en allowance. Esto aumenta la cantidad máxima de tokens que el spender puede gastar.
¿revoke puede devolver fondos robados?
No. Revoke cambia el estado del contrato solo para el futuro: allowance se convierte en 0 o operator se desactiva. Las transacciones que ya hayan sido ejecutadas no se revierten.
¿Eliminar la billetera o “desconectar el sitio” elimina las aprobaciones?
No. Los permisos se almacenan en cadena dentro del token y de los contratos NFT. Desconectar un sitio o eliminar una aplicación no cambia el estado allowance o operator en el contrato.
¿Dónde se almacena exactamente approve?
En estado de contrato inteligente. Para ERC-20, este es el registro allowance(propietario, spender); para NFTs son las aprobaciones y operator en el contrato de recogida.
¿Se puede limitar approve a una cantidad específica?
Sí. La llamada approve pasa el parámetro de cantidad y este valor define allowance. El spender no puede gastar más que los allowance permit actuales.
¿Qué es más peligroso: approve para un token o setApprovalForAll para un NFT?
Generalmente
¿Es necesario verificar las aprobaciones en L2s y cadenas laterales?
Sí. Cada red almacena sus propios registros de derechos en sus propios contratos. La asignación en Ethereum y allowance en Arbitrum son valores diferentes, por lo que verificar solo una red no muestra permisos en otras redes.
¿Una billetera de hardware protege contra el phishing de aprobación?
Una billetera de hardware protege la clave privada y el proceso de firma contra robos en el dispositivo, pero no cambia el significado de la acción que se firma. Un approve/permit peligroso o
Las preguntas frecuentes se reducen a una diferencia verificable: una firma puede otorgar derechos (approve/permit/
Un approve/permit equivocado o
Cómo protegerse del phishing de aprobación y mantener los permisos bajo control
Los permisos son la base de la mecánica de DeFi, pero los estados allowance y operator son exactamente los que permiten retirar activos sin una firma repetida si el derecho se concedió a una dirección innecesaria.
Phishing de aprobación es abuso de derechos legítimos. Un approve/permit o
Para evitar dejar derechos activos sobre una dirección, mantenga el control mediante acciones concretas:
- Consulta la dirección de acceso. La parte importante es spender/operator en la firma y en la lista de aprobaciones, no la marca o el diseño.
- Límite allowance. Establezca un límite específico de tarea en lugar de ilimitado y restablezca allowance cuando el derecho ya no sea necesario.
- Deshabilite operator para NFTs. no te vayas
setApprovalForAll habilitado una vez completada la acción. - Verifique todas las redes. La asignación y operator se almacenan por separado en cada red, así que revise cada red donde se utilizó un dApp.
- Separar direcciones por rol. El saldo de una dirección define la cantidad máxima que se puede gastar a través de derechos activos en esa dirección.
Trate las aprobaciones como derechos de acceso activos registrados en los contratos. Los límites mínimos de allowance, los operator deshabilitados y la revisión en todas las redes reducen la cantidad de activos disponibles para gastar sin una nueva firma.