Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

12 Días
10 Hrs
54 Min
15 Seg

Identificación del usuario: problema con tx.origin

3/15
Recursos

Ya viste algunas buenas prácticas al desarrollar contratos inteligentes. Ahora, es frecuente la necesidad de validar los permisos del usuario y para esto se utiliza la dirección de la billetera que emitió la transacción. Hay que tener algunas precauciones al realizar esta identificación.

Cómo realizar la identificación del usuario en smart contracts

Solidity permite la captura de la dirección del contrato que hizo la transacción y posteriormente se utiliza este dato para identificar al usuario.

Utilizamos msg.sender para obtener el dato, pero el lenguaje también cuenta con la variable global tx.origin que dependiendo la circunstancia devuelve la misma información.

  • msg.sender = Emisor del mensaje
  • tx.origin = Origen de la transacción

A simple vista, pueden parecer exactamente iguales ambas variables, ya que a la hora de hacer una transferencia de cuenta a cuenta van a devolver el mismo valor. ¿Pero qué pasa si quién realiza la transacción es otro contrato inteligente? Aquí es donde los valores de msg.sender y tx.origin van a diferir.

Esta vulnerabilidad de seguridad puede explotarse realizando transacciones al contrato, desde otro contrato. Al cambiar el valor de tx.origin, el atacante puede acceder a partes de la lógica del contrato que no le corresponde.

Diff sender and origin.jpg

En conclusión, se debe tener precaución cuando se utiliza tx.origin para identificar y validar al usuario que emite la transacción. En su lugar, es mejor usar msg.sender.


Contribución creada por Kevin Fiorentino (Platzi Contributor) con aportes de Mauro Legorburu y Adolfo Sebastián Jara Gavilanes.

Aportes 4

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Esto, más que un problema, es una precaución que debemos tener por una vulnerabilidad que tiene que ver con el “origen de una transacción”. Para esto, vamos a remarcar una de las variables que están disponibles en Solidity, relacionada con la transacción: tx.origin, la cual nos informa sobre el origen de una posible transacción.

  • tx.origin = origen de la transacción
  • msg.sender = emisor del mensaje

A siemple vista pueden parecer exactamente iguales, porque a la hora de hacer una transferencia de cuenta a cuenta van a devolver el mismo valor, pero qué pasa si, tenemos un usuario que es dueño de un contrato (a través de una cuenta, claramente) y le establece permisos de acceso, cuestión de que solamente esa cuenta pueda acceder al contrato; esta validación de permisos, si se hace con “tx.origin” puede dar un valor distinto al “msg.sender” si la llamada se hace a través de un contrato.

Por ejemplo, en vez de llamar a un contrato que está protegido desde una cuenta, imaginemos el camino en que el dueño del contrato, interactúa con un contrato intermediario, es decir, así como tenemos los problemas de phishing en la red de internet donde un usuario “cae en una trampa”, en este caso, nosotros sin saberlo podemos interactuar o realizar una transacción con un contrato que tiene código malicioso, y este contrato puede realizar una llamada al contrato que está protegido, entonces qué pasa… a la hora de realizar esta segunda transacción, cuando reciba la transacción el contrato protegido, va a recibir valores distintos para el “origen de la transacción” y el “envío del mensaje”. El “envío del mensaje” va a indicar que la dirección es la del contrato intermediario, pero el “origen de la transacción” sigue siendo la cuenta original.

Por lo tanto, si el chequeo del permiso lo hacemos contra “tx.origin” lo que vamos a tener es la cuenta del usuario, y por ende, nos va a dar la “sensación” de que está accediendo el usuario, y que tiene permisos para hacerlo, cuando en realidad quien está accediendo es un contrato intermediario.

En definitiva, el uso de “tx.origin” para el chequeo de permisos y de roles puede ser un problema.

En pocas palabras, no utilizar tx.origin para validar permisos en un contrato.

Diferencias
tx.origin = el origen del mensaje
msg.sender = emisor del mensaje