Crea una cuenta o inicia sesi贸n

隆Contin煤a aprendiendo sin ning煤n costo! 脷nete y comienza a potenciar tu carrera

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?

o inicia sesi贸n.

Esto, m谩s que un problema, es una precauci贸n que debemos tener por una vulnerabilidad que tiene que ver con el 鈥渙rigen 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 鈥渢x.origin鈥 puede dar un valor distinto al 鈥渕sg.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 鈥渃ae 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 鈥渙rigen de la transacci贸n鈥 y el 鈥渆nv铆o del mensaje鈥. El 鈥渆nv铆o del mensaje鈥 va a indicar que la direcci贸n es la del contrato intermediario, pero el 鈥渙rigen de la transacci贸n鈥 sigue siendo la cuenta original.

Por lo tanto, si el chequeo del permiso lo hacemos contra 鈥渢x.origin鈥 lo que vamos a tener es la cuenta del usuario, y por ende, nos va a dar la 鈥渟ensaci贸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 鈥渢x.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