tx.origin für Fabrik

Ich möchte eine Fabrik verwenden , damit die Leute einen standardisierten Vertrag erstellen können. Durch diese Kreation sollen Leute direkt Geld überweisen können, was mich bei der Ausführung auf das Problem des msg.senders geführt hat . Ich habe gelesen, dass tx.origin einige Sicherheitslücken hat, aber ich frage mich, ob dies auch nur für die Erstellung von Verträgen durch eine Fabrik gilt. Folgender Mustervertrag:

 pragma solidity ^0.4.0;

    contract Factory {

     address[] public contracts;

       function createContract () 
          payable 
          public 
       {
          Con newCon = (new Con).value(msg.value)();
          contracts.push(newCon);
       }

    }


    contract Con { 

     address owner;
     uint256 valueOwner
;

     function Con() 
        payable 
        public 
     { 
        owner = tx.origin;
        valueOwner = msg.value;
     } 

       function withdraw () 
          public
       {
          if(msg.sender == owner)
             msg.sender.transfer(valueOwner);
       }

    }

Ich sehe nicht ein, warum tx.origin hier schaden sollte oder übersehe ich einen Punkt?

Antworten (1)

Die Verwendung tx.originführt zu Problemen, wenn die Fabrik aus einem anderen Vertrag aufgerufen wird.

Brieftasche (A) ruft > Multisig-Vertrag (B) > auf, der Ihre Fabrik anruft (C) > Untervertrag (D).

In diesem Fall ist der tx.origin Wallet A. In den meisten Fällen erwarten Benutzer, dass der Besitzer tatsächlich der Multisig-B-Vertrag ist und nicht A.

Um dies zu verhindern, verwenden Sie einfach msg.sender in Factory C und übergeben Sie es an die neue Vertragsinstanz D, vorzugsweise in einem zweiten Methodenaufruf, damit Benutzer den Etherscan-Code-Validator ohne Konstruktorparameter problemlos verwenden können.

Dies scheint keine Sicherheitslücke zu sein, sondern eine Unannehmlichkeit für den Benutzer. Aber da Sie die Überprüfung über Etherscan erwähnen, könnte der Benutzer eine Überprüfung der Funktion createContract() der Factory und des Con-Konstruktorcodes durchführen, oder?
Es ist kein Sicherheitsmangel, es funktioniert wie vorgesehen. Die Haupteinschränkung bei der Gestaltung eines neuen „intelligenten Vertrags“ sollte Konsistenz sein. Ihre Benutzer haben keine Ahnung vom Unterschied zwischen tx.origin und msg.sender und werden es wahrscheinlich nie tun.
tx.origin für Fabrik
AntwortenHierDatenschutz-Bestimmungen1y, 0v