Cómo usar Slither para encontrar errores en contratos inteligentes

Cómo usar Slither

El objetivo de este tutorial es mostrar cómo usar Slither para encontrar errores automáticamente en contratos inteligentes.

• Instalación
• Uso de la línea de comandos
• Introducción al análisis estático: Breve introducción al análisis estático
• API: Descripción de la API de Python

Instalación

Slither requiere Python >= 3.6. Se puede instalar a través de pip o usando Docker.

Slither a través de pip:

pip3 install --user slither-analyzer

Slither a través de Docker:

docker pull trailofbits/eth-security-toolbox
docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox

El último comando ejecuta eth-security-toolbox en un contenedor de Docker que tiene acceso a su directorio actual. Puede cambiar los archivos desde su host y ejecutar las herramientas en los archivos desde Docker.

Dentro de Docker, ejecute:

solc-select 0.5.11
cd /home/trufflecon/

Ejecutar un script

Para ejecutar un script de Python con Python 3:

python3 script.py

Línea de comandos

Línea de comandos frente a scripts definidos por el usuario. Slither viene con un conjunto de detectores predefinidos que encuentran muchos errores comunes. Llamar a Slither desde la línea de comandos ejecutará todos los detectores, sin necesidad de conocimientos detallados de análisis estático:

slither project_paths

Además de los detectores, Slither tiene capacidades de revisión de código a través de sus impresoras (printers) (opens in a new tab) y herramientas (opens in a new tab).

Use crytic.io (opens in a new tab) para obtener acceso a detectores privados y a la integración con GitHub.

Análisis estático

Las capacidades y el diseño del marco de análisis estático de Slither se han descrito en publicaciones de blog (1 (opens in a new tab), 2 (opens in a new tab)) y en un artículo académico (opens in a new tab).

El análisis estático existe en diferentes variantes. Es muy probable que se dé cuenta de que compiladores como clang (opens in a new tab) y gcc (opens in a new tab) dependen de estas técnicas de investigación, pero también sustentan a (Infer (opens in a new tab), CodeClimate (opens in a new tab), FindBugs (opens in a new tab) y herramientas basadas en métodos formales como Frama-C (opens in a new tab) y Polyspace (opens in a new tab).

No revisaremos exhaustivamente las técnicas de análisis estático ni a los investigadores aquí. En su lugar, nos centraremos en lo que se necesita para comprender cómo funciona Slither para que pueda usarlo de manera más efectiva para encontrar errores y comprender el código.

• Representación del código
• Análisis de código
• Representación intermedia

Representación del código

A diferencia de un análisis dinámico, que razona sobre una única ruta de ejecución, el análisis estático razona sobre todas las rutas a la vez. Para hacerlo, se basa en una representación de código diferente. Las dos más comunes son el árbol de sintaxis abstracta (AST) y el grafo de flujo de control (CFG).

Árboles de sintaxis abstracta (AST)

Los AST se utilizan cada vez que el compilador analiza el código. Es probablemente la estructura más básica sobre la cual se puede realizar un análisis estático.

En pocas palabras, un AST es un árbol estructurado donde, por lo general, cada hoja contiene una variable o una constante y los nodos internos son operandos u operaciones de flujo de control. Considere el siguiente código:

function safeAdd(uint a, uint b) pure internal returns(uint){
    if(a + b <= a){
        revert();
    }
    return a + b;
}

El AST correspondiente se muestra en:

Slither usa el AST exportado por solc.

Aunque es fácil de construir, el AST es una estructura anidada. A veces, esto no es lo más sencillo de analizar. Por ejemplo, para identificar las operaciones utilizadas por la expresión a + b <= a, primero debe analizar <= y luego +. Un enfoque común es utilizar el llamado patrón de visitante (visitor pattern), que navega por el árbol de forma recursiva. Slither contiene un visitante genérico en ExpressionVisitor (opens in a new tab).

El siguiente código usa ExpressionVisitor para detectar si la expresión contiene una suma:

from slither.visitors.expression.expression import ExpressionVisitor
from slither.core.expressions.binary_operation import BinaryOperationType

class HasAddition(ExpressionVisitor):

    def result(self):
        return self._result

    def _post_binary_operation(self, expression):
        if expression.type == BinaryOperationType.ADDITION:
            self._result = True

visitor = HasAddition(expression) # expression es la expresión a probar
print(f'The expression {expression} has a addition: {visitor.result()}')

Grafo de flujo de control (CFG)

La segunda representación de código más común es el grafo de flujo de control (CFG). Como su nombre indica, es una representación basada en grafos que expone todas las rutas de ejecución. Cada nodo contiene una o varias instrucciones. Las aristas en el grafo representan las operaciones de flujo de control (if/then/else, bucles, etc.). El CFG de nuestro ejemplo anterior es:

El CFG es la representación sobre la cual se construyen la mayoría de los análisis.

Existen muchas otras representaciones de código. Cada representación tiene ventajas y desventajas según el análisis que desee realizar.

Análisis

El tipo de análisis más simple que puede realizar con Slither son los análisis sintácticos.

Análisis de sintaxis

Slither puede navegar a través de los diferentes componentes del código y su representación para encontrar inconsistencias y fallas utilizando un enfoque similar a la coincidencia de patrones.

Por ejemplo, los siguientes detectores buscan problemas relacionados con la sintaxis:

• Ocultamiento de variables de estado (shadowing) (opens in a new tab): itera sobre todas las variables de estado y comprueba si alguna oculta una variable de un contrato heredado (state.py#L51-L62 (opens in a new tab))

• Interfaz ERC-20 incorrecta (opens in a new tab): busca firmas de funciones ERC-20 incorrectas (incorrect_erc20_interface.py#L34-L55 (opens in a new tab))

Análisis semántico

A diferencia del análisis de sintaxis, un análisis semántico profundizará y analizará el "significado" del código. Esta familia incluye algunos tipos amplios de análisis. Conducen a resultados más potentes y útiles, pero también son más complejos de escribir.

Los análisis semánticos se utilizan para las detecciones de vulnerabilidades más avanzadas.

Análisis de dependencia de datos

Se dice que una variable variable_a depende de los datos de variable_b si hay una ruta por la cual el valor de variable_a está influenciado por variable_b.

En el siguiente código, variable_a depende de variable_b:

// ...
variable_a = variable_b + 1;

Slither viene con capacidades integradas de dependencia de datos (opens in a new tab), gracias a su representación intermedia (que se analiza en una sección posterior).

Un ejemplo del uso de la dependencia de datos se puede encontrar en el detector de igualdad estricta peligrosa (opens in a new tab). Aquí Slither buscará una comparación de igualdad estricta con un valor peligroso (incorrect_strict_equality.py#L86-L87 (opens in a new tab)), e informará al usuario que debe usar >= o <= en lugar de ==, para evitar que un atacante atrape el contrato. Entre otros, el detector considerará como peligroso el valor de retorno de una llamada a balanceOf(address) (incorrect_strict_equality.py#L63-L64 (opens in a new tab)), y utilizará el motor de dependencia de datos para rastrear su uso.

Cálculo de punto fijo

Si su análisis navega a través del CFG y sigue las aristas, es probable que vea nodos ya visitados. Por ejemplo, si se presenta un bucle como se muestra a continuación:

for(uint i; i < range; ++){
    variable_a += 1
}

Su análisis necesitará saber cuándo detenerse. Hay dos estrategias principales aquí: (1) iterar en cada nodo un número finito de veces, (2) calcular el llamado punto fijo (fixpoint). Un punto fijo básicamente significa que analizar este nodo no proporciona ninguna información significativa.

Un ejemplo del uso de punto fijo se puede encontrar en los detectores de reentrada: Slither explora los nodos y busca llamadas externas, escrituras y lecturas en el almacenamiento. Una vez que ha alcanzado un punto fijo (reentrancy.py#L125-L131 (opens in a new tab)), detiene la exploración y analiza los resultados para ver si hay una reentrada presente, a través de diferentes patrones de reentrada (reentrancy_benign.py (opens in a new tab), reentrancy_read_before_write.py (opens in a new tab), reentrancy_eth.py (opens in a new tab)).

Escribir análisis utilizando un cálculo de punto fijo eficiente requiere una buena comprensión de cómo el análisis propaga su información.

Representación intermedia

Una representación intermedia (IR) es un lenguaje destinado a ser más susceptible al análisis estático que el original. Slither traduce Solidity a su propia IR: SlithIR (opens in a new tab).

Comprender SlithIR no es necesario si solo desea escribir comprobaciones básicas. Sin embargo, será útil si planea escribir análisis semánticos avanzados. Las impresoras de SlithIR (opens in a new tab) y SSA (opens in a new tab) le ayudarán a comprender cómo se traduce el código.

Conceptos básicos de la API

Slither tiene una API que le permite explorar los atributos básicos del contrato y sus funciones.

Para cargar una base de código:

from slither import Slither
slither = Slither('/path/to/project')

Explorar contratos y funciones

Un objeto Slither tiene:

• contracts (list(Contract): lista de contratos
• contracts_derived (list(Contract): lista de contratos que no son heredados por otro contrato (subconjunto de contratos)
• get_contract_from_name (str): Devuelve un contrato a partir de su nombre

Un objeto Contract tiene:

• name (str): Nombre del contrato
• functions (list(Function)): Lista de funciones
• modifiers (list(Modifier)): Lista de funciones
• all_functions_called (list(Function/Modifier)): Lista de todas las funciones internas accesibles por el contrato
• inheritance (list(Contract)): Lista de contratos heredados
• get_function_from_signature (str): Devuelve una función a partir de su firma
• get_modifier_from_signature (str): Devuelve un modificador a partir de su firma
• get_state_variable_from_name (str): Devuelve una variable de estado a partir de su nombre

Un objeto Function o Modifier tiene:

• name (str): Nombre de la función
• contract (contract): el contrato donde se declara la función
• nodes (list(Node)): Lista de los nodos que componen el CFG de la función/modificador
• entry_point (Node): Punto de entrada del CFG
• variables_read (list(Variable)): Lista de variables leídas
• variables_written (list(Variable)): Lista de variables escritas
• state_variables_read (list(StateVariable)): Lista de variables de estado leídas (subconjunto de variables leídas)
• state_variables_written (list(StateVariable)): Lista de variables de estado escritas (subconjunto de variables escritas)

Última actualización de la página: 15 de abril de 2026

J (opens in a new tab)

n (opens in a new tab)

h (opens in a new tab)

+4

Ver colaboradores