Al desarrollar un contrato inteligente de Solidity, los desarrolladores deben configurar la visibilidad de las variables de estado para controlar quién puede obtenerlas o configurarlas.

Configurar explícitamente la visibilidad de las variables de estado hace que sea más fácil detectar suposiciones incorrectas sobre quién puede acceder a la variable.

Ejemplo 1: El siguiente código no logra configurar un nivel explícito de visibilidad para una variable.

bytes16 data = "data";

Cuando se utilizan versiones del compilador Solidity anteriores a la versión 0.5.0, los desarrolladores pueden definir un constructor creando una función con el mismo nombre que el contrato que lo contiene. Los constructores en general están reservados para funciones confidenciales y deben ejecutarse únicamente en el momento de la creación del contrato. Si el constructor tiene un error tipográfico, de modo que el nombre no coincide con el nombre del contrato, la funcionalidad confidencial del constructor queda expuesta.

Ejemplo 1: El siguiente código utiliza una versión del compilador Solidity anterior a la 0.5.0 e intenta declarar un constructor con un nombre que no coincide exactamente con el nombre del contrato. En este ejemplo, el caso del nombre del contrato y el nombre del constructor no coinciden (Missing frente a missing).

pragma solidity 0.4.20;

contract Missing {
    address private owner;
    function missing() public {
        owner = msg.sender;
    }
}

Al crear un contrato inteligente de Solidity, los desarrolladores pueden especificar la versión del compilador que se debe utilizar, para aclarar con qué versión se ha probado y evitar problemas al utilizar una versión diferente del compilador. Sin embargo, a lo largo de los años se han divulgado públicamente muchas vulnerabilidades relacionadas con el compilador y se han creado nuevas versiones revisadas del compilador para solucionar esos problemas.

Los desarrolladores pueden especificar un rango de versiones compatibles del compilador Solidity a utilizar al crear un contrato inteligente. Esto no se recomienda porque el contrato suele desarrollarse y probarse solo en una de las versiones posibles. Esto deja abierta la posibilidad de compilarlo utilizando una versión obsoleta del compilador que tenga vulnerabilidades de seguridad conocidas.

Ejemplo 1: La siguiente línea de código configura el pragma para que el contrato inteligente no se compile en versiones anteriores a la 0.4.5 y tampoco funcionará en compiladores de la versión 0.5.0 y posteriores.

pragma solidity ^0.4.5;

Cuando una conversión de carácter sin signo en entero se asigna a un carácter con signo, su valor no se podría distinguir de EOF.

Ejemplo 1: El código siguiente lee un carácter y lo compara con EOF.

char c;

while ( (c = getchar()) != '\n' && c != EOF ) {
  ...
}

En este caso, el valor devuelto de getchar() se convierte en un char y se compara con EOF (un int). Suponiendo que c sea un valor de 8 bits con signo y que EOF sea un valor de 32 bits con signo, entonces si getchar() devuelve un carácter representado por 0xFF, el valor de c producirá una extensión de signo para 0xFFFFFFFF en la comparación con EOF. Como EOF se define normalmente como -1 (0xFFFFFFFF), el bucle finalizará de forma errónea.

Es peligroso basarse en conversiones implícitas entre números con o sin signo porque el resultado puede tomar un valor inesperado e infringir hipótesis no seguras que se hacen en cualquier parte del programa.

Ejemplo 1: En este ejemplo, la variable amount puede albergar un valor negativo cuando se devuelve. Como la función se declara para devolver un entero sin signo, amount se convierte implícitamente a sin signo.

unsigned int readdata () {
	int amount = 0;
    ...
	if (result == ERROR)
		amount = -1;
	...
	return amount;
}

Si se cumple la condición de error del Example 1, el valor devuelto de readdata() será 4,294,967,295 en un sistema que utiliza enteros de 32 bits.

La conversión de valores con y sin signo puede provocar variedad de errores. Sin embargo, desde el punto de vista de la seguridad se asocia comúnmente con vulnerabilidades de desbordamiento de enteros y de búfer.

Es peligroso basarse en conversiones implícitas entre números con o sin signo porque el resultado puede tomar un valor inesperado e infringir hipótesis no seguras que se hacen en cualquier parte del programa.

Ejemplo 1: En este ejemplo, según el valor devuelto de accecssmainframe(), la variable amount puede albergar un valor negativo cuando se devuelve. Como la función se declara para devolver un valor sin signo, amount se convertirá implícitamente en un número sin signo.

unsigned int readdata () {
	int amount = 0;
    ...
    amount = accessmainframe();
    ...
	return amount;
}

Si el valor devuelto de accessmainframe() es -1, entonces el valor devuelto de readdata() será 4,294,967,295 en un sistema que utilice enteros de 32 bits.

La conversión de valores con y sin signo puede provocar variedad de errores. Sin embargo, desde el punto de vista de la seguridad se asocia comúnmente con vulnerabilidades de desbordamiento de enteros y de búfer.