Desafío

Clase 14 de 15 • Curso de Introducción a Seguridad de Smart Contracts

Resumen

Solidity es un lenguaje de programación con más de 8 años de existencia creado para el desarrollo de contratos inteligentes en la Blockchain de Ethereum. A lo largo de este período, ha ido evolucionando y mejorando muchos, pero las vulnerabilidades de seguridad existen y siempre existirán.

El desarrollo de software Web3 implica ser más riguroso con la codificación de nuestros contratos y estar en constante aprendizaje y estudio de las vulnerabilidades que surjan.

En Solidity by Examples encontrarás docenas de contratos para analizar y mejorar tus habilidades como desarrollador profesional de contratos inteligentes.

En Web3 es todo OpenSource. Encontrarás los contratos de cualquier proyecto como los de Uniswap que fueron desarrollados por expertos y podrás apoyarte de ese conocimiento para mejorar tus habilidades.

Reto del curso

El desafío para ti, elige un contrato desarrollador por un tercero y analízalo, despliégalo en Remix, dedícale tiempo en entender qué hace y cómo lo hace para ampliar tu conocimiento en el lenguaje.

Contribución creada por: Kevin Fiorentino (Platzi Contributor).

José Manuel Piña Rodríguez

student•

Contrato sin desafio para usar como plantilla:

//SPDX-License-Identifier:  MIT
pragma solidity ^0.8.0;

contract Desafio {
    uint private pin;
    mapping(address => uint) balances;

    constructor(uint ownerPin) {
        pin = ownerPin;
    }

    function min(uint ownerPin, uint amount) public {
        require(pin == ownerPin, "El pin no es correcto");
        balances[msg.sender] += amount;
    }

    function depositar() public payable{
        balances[msg.sender] += msg.value;
    }

    function retirar() public {
        require(balances[msg.sender] > 0);
        msg.sender.call{value:balances[msg.sender]}("");
        balances[msg.sender = 0];
    }
}

Adolfo Sebastián Jara Gavilanes

student•

Muchas gracias

Leandro Vitale

student•

Como puedo saber que valor de gas colocar? Que sea razonable.

Sebastian Perez

teacher•

Hola Leandro, es una gran pregunta ya que no existe un criterio definitivo ya que el gas price puede variar y una misma cantidad de gas puede ser mucho o poco dependiendo de este valor. Una forma podría ser setear el valor en una variable y que ese valor lo puedas ajustar en base al precio del gas de ese momento como para que sea suficiente para lo que desees ejecutar. Otra opción es hacerlo desde el código de Solidity observando la variable tx.gasprice y calculando el valor en el momento. Ahora, ¿Cuánto gas necesita? Bueno, eso puedes verlo en Remix cuando ejecutas una función o bien utilizar web3js (https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html#estimategas), de esta forma podrás saber cuánto gas demanda ejecutar una operación y luego calcular la variabilidad del gas price.

José Manuel Piña Rodríguez

student•

Desafio, implementando OpenZeppelin:

//SPDX-License-Identifier:  MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";

contract Desafio is Ownable {
    mapping(address => uint) balances;


    function min(uint amount) public onlyOwner {
        balances[msg.sender] += amount;
    }

    function depositar() public payable{
        balances[msg.sender] += msg.value;
    }

    function retirar() public  {
        require(balances[msg.sender] > 0);
        uint amount = balances[msg.sender];
        balances[msg.sender] = 0;
        (bool result, ) = msg.sender.call{value:amount,gas:600000}("");
        if(!result) revert();
    }
}

Walter López Calle

student•

Agregué una variable estado para suspender la ejecución de las funciones del contrato.

// SPDX-License-Identifier: MIT

pragma solidity >= 0.8.7;

contract Desafio{
    address private _ownerPin;
    bool private estado;
    mapping(address => uint) balances;

    constructor (){
        _ownerPin = msg.sender;
        estado=true;
    }

    function mint(address ownerPin, uint amount) public {
         require(_ownerPin == ownerPin, "No es el pin correcto");
         require (estado, "Estado no permite ejecutar la opcion");
         balances[msg.sender] += amount;
    }

    function depositar() public payable {
         require (estado, "Estado no permite ejecutar la opcion");
        balances[msg.sender] += msg.value;
    }

    function retirar() public {
        require (estado, "Estado no permite ejecutar la opcion");
        require (balances[msg.sender] > 0, "No tienes suficiente saldo");
        uint monto = balances[msg.sender];
        balances[msg.sender] = 0;
        (bool res, ) = msg.sender.call{value: monto, gas: 1000}("");
        if (!res) revert();
    }
    
    function cambiarEstado() public {
        require (_ownerPin == msg.sender, "No puede cambiar el estado");
        estado = !estado;
    }
}

guillermo sanchez

student•

Fernando Luis Sproviero

student•

Entiendo que es un ejemplo pero, ¿cuál sería el sentido de la función mint(amount)? En el mismo mapa de balances estaríamos mezclando montos minteados con montos reales de ETH de la función depositar().

Se puede dar este caso:

Deployar.
Ejecutar deposit con un valor de 10 eth.
Ejecutar mint con cualquier valor.
Ejecutar retirar no le va a funcionar y no podrá recuperar sus 10 eth.

También se puede dar este caso:

Deployar.
Bob ejecuta deposit con un valor de 1 eth.
Owner ejecutar mint con un valor de 1000000000000000000.
Owner ejecuta retirar y le va a robar 1 eth a Bob.

Sebastian Perez

teacher•

Hola Fernando, como bien dices es un ejercicio de ejemplo y no busca ser un caso "real" si no una práctica de los temas vistos, es por eso que se mezclan los tokens generados (o minteados con "mint") y los que se obtienen a través de la transferencia de ethers (los que se generan en "deposit"). Sin embargo, en el desafío los retiros y depósitos se hacen sobre msg.sender, por lo tanto un owner no podría robar los fondos de otro usuario.

Evaluados Team

student•

Tenes otro problema sin solucionar:

En el mint, al no ser payable, permitis incrementos de balance que al no haber recibido ether, generan balances que no estan calzados con los respectivos ether depositados.

Eso genera que haya mas balance total que ether total depositado y que el metodo de retiro se convierta en un juego de la silla, donde el ultimo en querer retirar no recibirá nada.

Miguel Martínez Gonzaléz

student•

Esta es mi respuesta al desafío. Algunas consideraciones que tuve:

Dejé la lógica del pin, esta puede ser cambiada por un tratamiento de owner o roles. En este caso cambie el pin a string para que sea más robusto y lo llevé a hash.
Unifiqué las funciones mint y depositar, ya que la función mint crea un falso depósito.
Arreglé el posible reentrancy attack que puede ocurrir en el retirar().
Agregué algunas buenas practicas de codificación con solidity y gas efficiency. Pueden consultar este documento donde resumo algunas de ellas.

//SPDX-License-Identifier:  MIT

pragma solidity >=0.8.0 <0.9.0;

error WrongPin();
error CeroBalance();
error FailCall(bytes response);

contract Challenge {
    bytes32 private immutable i_pin;
    mapping(address => uint) private s_balances;

    constructor(string memory ownerPin) {
        i_pin = keccak256(abi.encodePacked(ownerPin));
    }

    function deposit(string calldata ownerPin) external payable{
        if(i_pin != keccak256(abi.encodePacked(ownerPin))) revert WrongPin();
        s_balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        if(s_balances[msg.sender] <= 0) revert CeroBalance();
        s_balances[msg.sender] = 0;

        (bool success, bytes memory response) = msg.sender.call{value:s_balances[msg.sender]}("");
        if (!success) revert FailCall(response);        
    }
}

Martín Alexis Samán Arata

student•

Buen curso!

Kevin Fiorentino

student•

SPOILER Veo dos cosas en el Contrato antes de que el profesor de su solución: Que la variable privada almacena datos sensibles y fácilmente puede averiguarse ese valor. Y que el contrato es propenso a un Reetrancy Simple y robar todos los fondos.

Leandro Ariel Labiano Ramo

student•

Muy lindo el curso. Saludos.

Nicolás García Puerta

student•

Hola Sebastián. Tienes un error en la parte en la que recomiendas manejar un rango de versiones del compilador para el smart contract.

Contracts should be deployed with the same compiler version and flags that they have been tested the most with. Locking the pragma helps ensure that contracts do not accidentally get deployed using, for example, the latest compiler which may have higher risks of undiscovered bugs.

https://swcregistry.io/docs/SWC-103

Saludos

Desafío

Introducción

Importancia de la seguridad en el desarrollo de contratos

Buenas prácticas

Vulnerabilidades con variables globales

Identificación del usuario: problema con tx.origin

Dependencia con timestamp

Vulnerabilidades del almacenamiento

Overflow y underflow

Variables privadas

Problemas con llamadas externas

DelegateCall

Gas insuficiente en Solidity

Ataques con transferencias

Forzar envío de Ethers

Reentrancy simple

Reentrancy cruzado

Denegación de servicio

Denegación por reversión

Denegación por límite de gas

Despedida

Desafío

Continúa aprendiendo

Reto del curso