Short Address Attack

⚡ Definición Rápida

Un Short Address Attack (ataque de dirección corta) es una vulnerabilidad de seguridad en la capa de cliente de Ethereum que ocurre cuando una billetera o interfaz no valida correctamente la longitud de una dirección. Al procesar una dirección incompleta, el ataque manipula el relleno (padding) de datos en la transacción, haciendo que el parámetro de cantidad se desplace y se interprete como un valor mucho mayor al intencionado.

Términos relacionados: Address • Smart Contract • Gas • Reentrancy Attack • EVM

❓ ¿Qué es un Short Address Attack y por qué sigue siendo relevante?

Un Short Address Attack es un exploit que se aprovecha de cómo la Máquina Virtual de Ethereum (EVM) codifica y decodifica los parámetros de las transacciones. A diferencia de ataques que explotan bugs en el código de un contrato inteligente, este ataque se enfoca en la interfaz de usuario o la billetera que construye la transacción.

Imagina que quieres enviar 100 tokens a una dirección que, por error, solo tiene 19 bytes en lugar de los 20 requeridos. Una billetera vulnerable no rechazará esta dirección; en su lugar, la pasará tal cual a la EVM. La EVM, al decodificar los parámetros, tomará prestado un byte del campo de «cantidad» para completar la dirección de 20 bytes. El resultado: la cantidad enviada se multiplica por 256 (0x6400 = 25,600 tokens), y los fondos van a la dirección del atacante.

Aunque es un ataque clásico y menos común hoy en día gracias a las mejoras en billeteras modernas, su estudio es fundamental para entender la seguridad en Web3. Muestra cómo un simple error de validación puede tener consecuencias catastróficas y subraya la importancia de la seguridad en todas las capas de la pila tecnológica.

📖 Definición Técnica

El ataque explota el proceso de codificación ABI (Application Binary Interface) de Ethereum. Cuando una billetera construye una transacción para una función como transfer(address _to, uint256 _value), espera que los datos de la llamada (calldata) tengan una longitud específica: 4 bytes para el selector de función + 32 bytes para _to (rellenado a la izquierda) + 32 bytes para _value.

Si la dirección _to se proporciona con solo 19 bytes, el calldata total será de 63 bytes en lugar de 64. La EVM, al decodificar, lee los primeros 32 bytes como _to, tomando los 19 bytes de la dirección y el primer byte (0x00) del campo _value. Luego, lee los siguientes 32 bytes como _value, que ahora comienzan en el segundo byte del valor original y terminan con un byte de relleno (0x00) al final. Este desplazamiento multiplica el valor por 256 por cada byte faltante en la dirección.

🏗️ Short Address Attack vs. Otros Ataques a Smart Contracts

Para contextualizar mejor este ataque, es útil compararlo con otras vulnerabilidades comunes en el ecosistema Ethereum.

Aspecto	Short Address Attack	Reentrancy Attack	Flash Loan Attack
Vector de ataque	Validación de entrada en el cliente (billetera/interfaz)	Llamada recursiva a un contrato vulnerable antes de actualizar su estado	Manipulación de precios o liquidez usando préstamos flash
Objetivo principal	Robar tokens manipulando la cantidad enviada	Drenar fondos de un contrato que no sigue el patrón Checks-Effects-Interactions	Obtener ganancias mediante arbitraje, liquidaciones o manipulación de oráculos
Complejidad técnica	Baja (requiere conocimiento básico de ABI y padding)	Media (requiere entender la ejecución en la EVM y el flujo de llamadas)	Alta (requiere entender DeFi, pools de liquidez y oráculos)
Mitigación principal	Validar longitud de direcciones y usar checksums (EIP-55) en el frontend	Usar bloqueos de reentrada (reentrancy guard) y actualizar el estado antes de llamadas externas	Usar oráculos descentralizados, límites de deslizamiento y mecanismos de prevención de manipulación
¿Explota el contrato?	No (explota el cliente que construye la transacción)	Sí (explota el código del contrato inteligente)	Sí (explota la lógica del protocolo DeFi)

⚙️ Mecánica del Ataque: Desglose Técnico

Entender el ataque paso a paso es crucial para apreciar su sutileza.

1. Generación de la Dirección «Veneno»: El atacante genera una dirección de billetera que termina en uno o más bytes cero (0x00). Luego, promueve esta dirección omitiendo esos ceros finales. Por ejemplo, la dirección real 0x1234...5600 se promueve como 0x1234...56.
2. Construcción de la Transacción Vulnerable: La víctima copia la dirección corta en una billetera que no valida la longitud. Al construir la llamada a transfer(_to, _value), la billetera no rellena la dirección a 32 bytes (el tamaño estándar de un parámetro ABI) antes de ensamblar los datos. El calldata resultante tiene un byte de menos.
3. Decodificación por la EVM: La EVM espera que el calldata tenga una estructura fija. Al leer los primeros 32 bytes como _to, toma los 19 bytes de la dirección corta y el primer byte (0x00) del campo _value. El campo _value ahora comienza un byte después, y la EVM lo lee como un valor de 32 bytes, añadiendo un byte de relleno (0x00) al final.
4. Ejecución y Pérdida: El contrato ejecuta transfer() con los parámetros malinterpretados. Si el usuario quería enviar 100 tokens (0x64), el valor ahora es 0x6400 = 25,600 tokens. Los tokens se envían a la dirección real del atacante (con los ceros finales), y la víctima pierde una cantidad masiva de fondos.

🎯 Escenarios y Variantes del Ataque

El Short Address Attack no se limita a una sola forma de ejecución. Aquí hay algunas variantes:

Ataque Directo a Usuarios: Un atacante publica una dirección de «airdrop» o «venta» acortada en redes sociales. Los usuarios que la copian en una billetera vulnerable pierden tokens.
Explotación en Exchanges: En el pasado, algunas APIs de exchanges no validaban la longitud de las direcciones de retiro. Un atacante podía solicitar un retiro a una dirección corta, y el exchange enviaría una cantidad mucho mayor.
Ataque a approve(): La función approve(_spender, _value) es igual de vulnerable. Un usuario que aprueba un gasto a una dirección corta podría estar aprobando 256 veces más fondos de los que pensaba.
Generación de Múltiples Direcciones: Un atacante puede generar sistemáticamente direcciones que terminen en varios bytes cero (0x00, 0x0000, etc.). Cuantos más ceros, mayor el multiplicador del ataque (x256, x65536, etc.).

⚖️ Prevención: Responsabilidades del Cliente y del Contrato

Mitigar este ataque requiere acción tanto a nivel del cliente como, en menor medida, a nivel del contrato inteligente.

Capa	Medida de Prevención	Implementación	Efectividad
Cliente (Wallet/Interfaz)	Validación Estricta de Longitud: Rechazar cualquier dirección que no tenga exactamente 20 bytes (40 caracteres hex + ‘0x’).	Chequeo en el campo de entrada: `if (address.length !== 42) throw Error();`	✅ Altamente efectiva. Elimina el vector por completo.
Cliente (Wallet/Interfaz)	Checksum (EIP-55): Requerir y validar direcciones con checksum. Las direcciones acortadas manualmente casi siempre invalidarán el checksum.	Usar librerías como `ethers.js` que implementan EIP-55.	✅ Muy efectiva. Añade una capa de detección.
Cliente (Wallet/Interfaz)	Simulación de Transacción: Simular la transacción y alertar si el `gasUsed` es anormalmente bajo o si los balances resultantes son inesperados.	Llamar a `eth_estimateGas` y analizar el resultado.	⚠️ Detecta algunos casos, pero no es infalible.
Contrato Inteligente	Verificación de Longitud de Calldata: Un contrato puede verificar que `msg.data.length` sea exactamente el esperado para la función llamada.	En la función: `require(msg.data.length == 4 + 20 + 32);`	⚠️ Agrega gas y rompe compatibilidad con algunos clients. No es común en ERC-20 estándar.
Usuario Final	Educación y Conciencia: Verificar siempre la longitud completa de las direcciones y preferir copiarlas con herramientas integradas.	Usar enlaces clickeables o escáner QR de confianza.	✅ Buena práctica, pero no confiable como única defensa.

✅ Ventajas de Conocer este Ataque

Conciencia de Seguridad: Entender este ataque te hace más consciente de la importancia de validar las direcciones antes de enviar fondos.
Mejores Prácticas de Desarrollo: Para desarrolladores, es una lección fundamental sobre la seguridad en la capa de cliente y la importancia de usar librerías auditadas.
Auditoría de Contratos: Los auditores de seguridad revisan si los frontends y APIs realizan validaciones de entrada adecuadas.
Protección de Activos: Usar billeteras y exchanges que implementen estas protecciones reduce significativamente el riesgo de ser víctima de este ataque.
Educación Comunitaria: Compartir este conocimiento ayuda a crear una comunidad más segura y resiliente.

⚠️ Críticas y Desafíos

Bajo Riesgo Actual: Las billeteras modernas (MetaMask, Trust Wallet) y los exchanges principales han endurecido sus interfaces, haciendo que este ataque sea poco común hoy en día.
Dependencia del Cliente: La mitigación principal recae en el cliente, no en el contrato inteligente. Esto significa que incluso si un contrato es perfecto, una interfaz mal construida puede ser explotada.
Complejidad para Nuevos Desarrolladores: Los desarrolladores novatos pueden pasar por alto esta validación si no están familiarizados con el estándar ABI de Ethereum.
Falsa Sensación de Seguridad: Algunos usuarios pueden pensar que solo por usar una billetera «segura» están protegidos, sin entender que la seguridad también depende de cómo interactúan con las interfaces.
Variantes con Múltiples Bytes: Un ataque con una dirección que falten 2 bytes (terminando en 0x0000) multiplicaría el valor por 65,536, haciendo el ataque aún más devastador si la interfaz no valida.

🧠 Guía Práctica: Cómo Protegerte y Proteger tus dApps

Si eres usuario: Usa siempre billeteras actualizadas y de buena reputación. Verifica la longitud de las direcciones (deben tener 42 caracteres incluyendo ‘0x’). Prefiere copiar direcciones usando el botón de copia en exploradores de bloques o wallets en lugar de hacerlo manualmente.
Si eres desarrollador: Usa librerías como ethers.js o web3.js que validan automáticamente las direcciones. Implementa una validación de longitud en tu frontend. Considera usar el estándar EIP-55 para checksums.
Si eres auditor: Revisa que el frontend de la dApp valide las direcciones antes de construir la transacción. Verifica que no haya APIs que acepten direcciones sin validar.
Si eres exchange: Implementa validación estricta de direcciones en tus APIs de retiro. Realiza pruebas de penetración para identificar posibles vulnerabilidades.
Si eres educador: Incluye este ataque en tus materiales de seguridad para mostrar cómo un error simple puede tener consecuencias graves.

🔮 El Futuro de la Seguridad en la Capa de Cliente

Aunque el Short Address Attack es menos común hoy, su legado es importante. Ha llevado a la industria a adoptar mejores prácticas de seguridad en el frontend. Las perspectivas futuras incluyen:

Validación Automática en Librerías: Las librerías modernas como ethers.js v6 ya incluyen validación de direcciones por defecto, haciendo que este ataque sea casi imposible si se usan correctamente.
Estandarización de Checksums: EIP-55 se ha convertido en un estándar ampliamente adoptado. Las billeteras que no lo implementan son cada vez más raras.
Herramientas de Simulación: Las billeteras están integrando cada vez más herramientas de simulación de transacciones que alertan a los usuarios sobre resultados inesperados.
Educación Continua: La comunidad sigue educando a desarrolladores y usuarios sobre este y otros ataques, reduciendo la probabilidad de que ocurran.
Auditorías de Frontend: Las auditorías de seguridad ahora incluyen la revisión del frontend y las APIs, no solo del contrato inteligente.

🎯 Conclusión: Un Ataque Clásico que Enseña Lecciones Duraderas

El Short Address Attack es un ejemplo perfecto de cómo una vulnerabilidad en la capa de cliente puede tener consecuencias devastadoras. No requiere explotar un bug en un contrato inteligente, sino simplemente aprovechar la falta de validación en la interfaz de usuario. Aunque las billeteras modernas han mitigado en gran medida este riesgo, su estudio sigue siendo fundamental para entender la seguridad en Web3.

Para los usuarios, la lección es clara: siempre verifiquen las direcciones y usen herramientas confiables. Para los desarrolladores, es un recordatorio de que la seguridad no termina en el contrato inteligente; el frontend y la infraestructura son igual de críticos. En el ecosistema descentralizado, cada capa de la pila tecnológica debe ser defendida.

❓ Preguntas Frecuentes sobre Short Address Attack

¿El Short Address Attack sigue siendo un riesgo hoy en día?

Es un riesgo bajo para la mayoría de los usuarios de billeteras modernas como MetaMask o Trust Wallet, ya que estas validan automáticamente la longitud de las direcciones. Sin embargo, sigue siendo relevante para desarrolladores que construyen interfaces personalizadas o para exchanges que no hayan actualizado sus sistemas.

¿Cómo puedo protegerme como usuario?

Usa siempre billeteras actualizadas y de buena reputación. Verifica que las direcciones tengan 42 caracteres (incluyendo ‘0x’). Copia direcciones usando el botón de copia en exploradores de bloques o wallets, en lugar de hacerlo manualmente.

¿Este ataque afecta a todos los tokens ERC-20?

Sí, cualquier token que implemente la función `transfer()` o `approve()` según el estándar ERC-20 puede ser vulnerable si la interfaz que construye la transacción no valida las direcciones correctamente. El ataque no depende del token en sí, sino de cómo se construye la transacción.

¿Qué es EIP-55 y cómo ayuda?

EIP-55 es un estándar que introduce un checksum en las direcciones de Ethereum usando mayúsculas y minúsculas. Esto permite detectar errores tipográficos o direcciones mal formadas. Las billeteras que implementan EIP-55 pueden rechazar direcciones que no pasen la verificación del checksum.

¿Puedo recuperar los tokens perdidos en un Short Address Attack?

En la mayoría de los casos, no. Una vez que la transacción es confirmada en la blockchain, es irreversible. Por eso la prevención es tan importante. En casos muy raros, si el atacante es identificado y se toman acciones legales, podría haber una recuperación, pero no es común.

📚 ¿Quieres profundizar en seguridad blockchain?

Explora más recursos de La Cryptoguía sobre seguridad y vulnerabilidades:

🔗 Reentrancy Attack – El ataque más famoso a smart contracts.

⚡ Flash Loan Attack – Cómo los préstamos flash pueden ser explotados.

🛡️ Guía de Seguridad Crypto – Principios fundamentales para proteger tus activos.

🔷 ERC-20 – El estándar de tokens más utilizado.

💡 Transferir Criptomonedas – Mejores prácticas para enviar activos de forma segura.

🔧 10 Estafas Crypto Más Comunes – Contextualiza este ataque entre otras amenazas.

📖 ¿Qué es Blockchain? – Refuerza tu comprensión de la tecnología base.

🚀 ¿Empezando en Seguridad Blockchain?

Construye una base sólida con nuestra guía completa gratuita para principiantes antes de explorar vulnerabilidades avanzadas.

📋 ¿Por qué confiar en esta definición? Cada término de la Cryptopedia sigue una metodología de verificación con fuentes primarias, whitepapers y legislación oficial. Conoce nuestro proceso →

⚠️ Disclaimer: Este artículo es de naturaleza puramente informativa y educativa. No constituye asesoramiento de seguridad, financiero o legal. Si bien las medidas descritas pueden mitigar riesgos, no garantizan protección absoluta. La implementación de seguridad en sistemas blockchain es compleja y en constante evolución. Siempre realiza tu propia investigación (DYOR), usa herramientas auditadas y considera auditorías profesionales para proyectos críticos. El autor y el editor no se hacen responsables de cualquier pérdida derivada del uso de esta información.

📅 Actualizado: Marzo 2026
📖 Categoría: Seguridad y Riesgos / Auditoría y Smart Contracts

« Volver al Glosario