Proteger un contrato inteligente no es opcional. A diferencia del software tradicional, una vez desplegado en la blockchain, el código no se puede modificar. Cualquier vulnerabilidad, ya sea un error de programación o un flujo lógico mal pensado, queda expuesta de forma permanente. Por eso, entender los riesgos y aplicar buenas prácticas de seguridad desde el diseño es fundamental para cualquier desarrollador que trabaje con Solidity.
¿Por qué las llamadas externas son el mayor riesgo de seguridad?
El 99 % de las vulnerabilidades en contratos inteligentes está relacionado con llamadas externas [01:10]. Cuando un contrato consume otro contrato, como ocurre al generar un número aleatorio o al interactuar con tokens, se abre una puerta a posibles ataques.
Las recomendaciones clave son:
- Limitar la cantidad de llamadas externas y realizarlas solo a direcciones conocidas.
- Verificar que las direcciones de los contratos consumidos provengan de un explorador confiable o que nosotros mismos hayamos hecho el deploy.
- Asegurarse de que el contrato no permita modificar esas direcciones sin los permisos adecuados, ya que cualquier cuenta con acceso podría redirigir a un contrato malicioso.
También hay que considerar el efecto cascada: si un contrato externo es vulnerado, nuestro contrato puede verse afectado. Por ejemplo, si el contrato de moneda sufre un ataque, el marketplace que depende de él quedaría comprometido [02:30].
¿Qué es el ataque de reentrancy y cómo prevenirlo?
El reentrancy es uno de los ataques más graves en contratos inteligentes [03:28]. Ocurre cuando un atacante aprovecha que el estado del contrato no está completamente actualizado para ejecutar una misma función múltiples veces antes de que termine la primera ejecución.
La defensa principal es seguir el patrón checks-effects-interactions: primero se valida, luego se actualiza el estado local y el almacenamiento, y las llamadas externas se colocan siempre al final del código [03:08]. De esta forma, cuando se ejecuta la llamada externa, el contrato ya refleja su estado correcto.
OpenZeppelin ofrece un reentrancy guard que protege contra este ataque cuando involucra transferencia de ethers [03:50]. Es importante distinguir que la transferencia de ethers y la transferencia de tokens son mecanismos diferentes y requieren protecciones distintas.
¿Cómo evitar una denegación de servicio en un contrato?
La denegación de servicio (denial of service) sucede cuando una llamada externa falla siempre, bloqueando el flujo completo del contrato [04:10]. Imaginemos que alguien logra sustituir la dirección del contrato de moneda por un contrato falso cuya función de emisión ejecuta un revert permanente. En ese escenario, ninguna partida del juego podría finalizar con un ganador.
La solución recomendada es separar los saldos de los pagos [05:15]:
- En lugar de emitir tokens dentro de la lógica del juego, se acumulan los saldos en un mapping.
- Se crea una función de retiro independiente donde el usuario reclama sus tokens.
- Si el retiro falla, el juego no queda bloqueado y el registro del saldo permanece intacto.
Este patrón, conocido como pull over push, garantiza que la lógica principal del contrato no dependa del éxito de una llamada externa.
¿Qué herramientas de análisis estático existen para Solidity?
Slither es una herramienta de análisis estático disponible en GitHub que examina el código de contratos inteligentes en busca de vulnerabilidades [06:05]. Se integra con frameworks como Truffle y ejecuta la compilación junto con el análisis de forma automática.
Por ejemplo, Slither puede detectar que una versión muy reciente de Solidity, como la 0.8.19, no está recomendada para producción por no haber sido suficientemente probada [06:40]. La práctica habitual de definir un rango de versiones con pragma puede exponer el contrato a compiladores inestables.
¿Cuáles son los tres pilares de seguridad en contratos inteligentes?
La seguridad se sostiene sobre tres prácticas fundamentales [07:05]:
- Usar herramientas de análisis estático como Slither para detectar vulnerabilidades de forma automatizada.
- Estudiar ataques conocidos como reentrancy y denegación de servicio, y aplicar los patrones que los previenen.
- Compartir el código con otros desarrolladores y, en casos sensibles como escenarios de DeFi, contratar servicios de auditoría profesional que ofrezcan un análisis detallado.
No confiar únicamente en la propia revisión marca la diferencia entre un contrato robusto y uno vulnerable. Si trabajas con contratos inteligentes, ¿qué prácticas de seguridad aplicas en tus proyectos? Comparte tu experiencia.
