[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-4-sicherheitsprimitive-zugangskontrolle-reentrancy":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d7000000-0000-0000-0000-000000000104","a0000000-0000-0000-0000-000000000072","Deep EVM #4: Sicherheitsprimitive — msg.sender, Zugangskontrolle und Reentrancy","deep-evm-4-sicherheitsprimitive-zugangskontrolle-reentrancy","Wie das Ausfuehrungsmodell der EVM Sicherheitsluecken schafft und wie man sie verhindert: msg.sender vs tx.origin, Reentrancy-Angriffe, delegatecall-Risiken und Zugangskontrollmuster.","## Smart-Contract-Sicherheit beginnt beim Ausfuehrungsmodell\n\nSmart-Contract-Sicherheit bedeutet nicht, Pruefungen ueber funktionierenden Code zu legen — es geht darum zu verstehen, wie das Ausfuehrungsmodell der EVM Angriffsflaechen schafft. Jeder externe Aufruf ist ein potenzieller Wiedereinstiegspunkt. Jeder Delegatecall ist ein Storage-Hijacking-Vektor.\n\n## msg.sender vs tx.origin\n\nDer grundlegendste Sicherheitsfehler in Smart Contracts: die Verwechslung von msg.sender und tx.origin.\n\n- **msg.sender** — der unmittelbare Aufrufer. Kann ein EOA (Externally Owned Account) oder ein anderer Contract sein.\n- **tx.origin** — der urspruengliche Absender der Transaktion. Immer ein EOA.\n\n```solidity\n\u002F\u002F FALSCH: Jeder Contract kann das ausloesen, wenn er im Namen des Benutzers aufruft\nfunction withdraw() external {\n    require(tx.origin == owner, \"Not owner\");\n    payable(owner).transfer(address(this).balance);\n}\n\n\u002F\u002F RICHTIG: Nur der direkte Aufrufer wird geprueft\nfunction withdraw() external {\n    require(msg.sender == owner, \"Not owner\");\n    payable(owner).transfer(address(this).balance);\n}\n```\n\nVerwenden Sie **niemals** tx.origin fuer die Authentifizierung. Ein boesartiger Contract kann den Benutzer dazu bringen, eine Funktion aufzurufen, die dann Ihren Contract mit dem tx.origin des Benutzers aufruft.\n\n## Reentrancy-Angriffe\n\nReentrancy ist der beruechtigtste Angriff in der Smart-Contract-Geschichte. Der DAO-Hack von 2016, bei dem 60 Millionen Dollar gestohlen wurden, nutzte genau diese Schwachstelle.\n\nDas Grundmuster:\n\n```solidity\n\u002F\u002F Verwundbarer Contract\ncontract Vulnerable {\n    mapping(address => uint256) public balances;\n    \n    function withdraw() external {\n        uint256 bal = balances[msg.sender];\n        \u002F\u002F GEFAHR: Externer Aufruf VOR Zustandsaenderung\n        (bool success, ) = msg.sender.call{value: bal}(\"\");\n        require(success);\n        \u002F\u002F Diese Zeile wird erst nach dem externen Aufruf erreicht\n        balances[msg.sender] = 0;\n    }\n}\n\n\u002F\u002F Angreifer-Contract\ncontract Attacker {\n    Vulnerable target;\n    \n    receive() external payable {\n        \u002F\u002F Wird aufgerufen, wenn target.withdraw() ETH sendet\n        if (address(target).balance > 0) {\n            target.withdraw(); \u002F\u002F Reentrancy!\n        }\n    }\n}\n```\n\n### Abwehr: Checks-Effects-Interactions\n\nDas goldene Muster fuer sichere Smart Contracts:\n\n1. **Checks** — Alle Bedingungen pruefen\n2. **Effects** — Zustand aendern\n3. **Interactions** — Externe Aufrufe durchfuehren\n\n```solidity\nfunction withdraw() external {\n    uint256 bal = balances[msg.sender]; \u002F\u002F Check\n    require(bal > 0, \"No balance\");\n    balances[msg.sender] = 0;           \u002F\u002F Effect (VORHER!)\n    (bool success, ) = msg.sender.call{value: bal}(\"\"); \u002F\u002F Interaction\n    require(success);\n}\n```\n\n### Reentrancy-Guards\n\nFuer zusaetzliche Sicherheit verwenden Sie einen Reentrancy-Guard:\n\n```solidity\nboolean private locked;\n\nmodifier noReentrancy() {\n    require(!locked, \"Reentrancy\");\n    locked = true;\n    _;\n    locked = false;\n}\n```\n\nMit EIP-1153 (Transient Storage) kann das Lock effizienter implementiert werden: TSTORE\u002FTLOAD statt SSTORE\u002FSLOAD, was 4.800 Gas pro Aufruf spart.\n\n## delegatecall-Risiken\n\nDELEGATECALL fuehrt den Code eines anderen Contracts im Speicherkontext des aufrufenden Contracts aus. Dies ist die Grundlage fuer Proxy-Muster, birgt aber erhebliche Risiken:\n\n- Der aufgerufene Code kann den Storage des aufrufenden Contracts beliebig aendern\n- Storage-Slot-Kollisionen zwischen Proxy und Implementierung koennen Daten korrumpieren\n- Wenn die Implementierung eine selfdestruct-Funktion hat, kann der Proxy zerstoert werden\n\n```solidity\n\u002F\u002F Gefaehrlich: Ungeprufter delegatecall\nfunction execute(address target, bytes calldata data) external {\n    (bool success, ) = target.delegatecall(data);\n    require(success);\n}\n```\n\n## Zugangskontrollmuster\n\nFuer produktionsreife Smart Contracts verwenden Sie OpenZeppelins AccessControl:\n\n```solidity\nimport \"@openzeppelin\u002Fcontracts\u002Faccess\u002FAccessControl.sol\";\n\ncontract MyContract is AccessControl {\n    bytes32 public constant ADMIN_ROLE = keccak256(\"ADMIN_ROLE\");\n    bytes32 public constant OPERATOR_ROLE = keccak256(\"OPERATOR_ROLE\");\n    \n    constructor() {\n        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);\n    }\n    \n    function adminFunction() external onlyRole(ADMIN_ROLE) {\n        \u002F\u002F Nur Admins\n    }\n}\n```\n\n## Fazit\n\nSmart-Contract-Sicherheit erfordert ein tiefes Verstaendnis des EVM-Ausfuehrungsmodells. msg.sender vs tx.origin, Reentrancy-Schutz, sichere delegatecall-Nutzung und rollenbasierte Zugangskontrolle sind die Grundpfeiler. Jeder externe Aufruf ist eine potenzielle Gefahr — behandeln Sie ihn entsprechend.","\u003Ch2 id=\"smart-contract-sicherheit-beginnt-beim-ausfuehrungsmodell\">Smart-Contract-Sicherheit beginnt beim Ausfuehrungsmodell\u003C\u002Fh2>\n\u003Cp>Smart-Contract-Sicherheit bedeutet nicht, Pruefungen ueber funktionierenden Code zu legen — es geht darum zu verstehen, wie das Ausfuehrungsmodell der EVM Angriffsflaechen schafft. Jeder externe Aufruf ist ein potenzieller Wiedereinstiegspunkt. Jeder Delegatecall ist ein Storage-Hijacking-Vektor.\u003C\u002Fp>\n\u003Ch2 id=\"msg-sender-vs-tx-origin\">msg.sender vs tx.origin\u003C\u002Fh2>\n\u003Cp>Der grundlegendste Sicherheitsfehler in Smart Contracts: die Verwechslung von msg.sender und tx.origin.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>msg.sender\u003C\u002Fstrong> — der unmittelbare Aufrufer. Kann ein EOA (Externally Owned Account) oder ein anderer Contract sein.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>tx.origin\u003C\u002Fstrong> — der urspruengliche Absender der Transaktion. Immer ein EOA.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F FALSCH: Jeder Contract kann das ausloesen, wenn er im Namen des Benutzers aufruft\nfunction withdraw() external {\n    require(tx.origin == owner, \"Not owner\");\n    payable(owner).transfer(address(this).balance);\n}\n\n\u002F\u002F RICHTIG: Nur der direkte Aufrufer wird geprueft\nfunction withdraw() external {\n    require(msg.sender == owner, \"Not owner\");\n    payable(owner).transfer(address(this).balance);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Verwenden Sie \u003Cstrong>niemals\u003C\u002Fstrong> tx.origin fuer die Authentifizierung. Ein boesartiger Contract kann den Benutzer dazu bringen, eine Funktion aufzurufen, die dann Ihren Contract mit dem tx.origin des Benutzers aufruft.\u003C\u002Fp>\n\u003Ch2 id=\"reentrancy-angriffe\">Reentrancy-Angriffe\u003C\u002Fh2>\n\u003Cp>Reentrancy ist der beruechtigtste Angriff in der Smart-Contract-Geschichte. Der DAO-Hack von 2016, bei dem 60 Millionen Dollar gestohlen wurden, nutzte genau diese Schwachstelle.\u003C\u002Fp>\n\u003Cp>Das Grundmuster:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Verwundbarer Contract\ncontract Vulnerable {\n    mapping(address => uint256) public balances;\n    \n    function withdraw() external {\n        uint256 bal = balances[msg.sender];\n        \u002F\u002F GEFAHR: Externer Aufruf VOR Zustandsaenderung\n        (bool success, ) = msg.sender.call{value: bal}(\"\");\n        require(success);\n        \u002F\u002F Diese Zeile wird erst nach dem externen Aufruf erreicht\n        balances[msg.sender] = 0;\n    }\n}\n\n\u002F\u002F Angreifer-Contract\ncontract Attacker {\n    Vulnerable target;\n    \n    receive() external payable {\n        \u002F\u002F Wird aufgerufen, wenn target.withdraw() ETH sendet\n        if (address(target).balance > 0) {\n            target.withdraw(); \u002F\u002F Reentrancy!\n        }\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Abwehr: Checks-Effects-Interactions\u003C\u002Fh3>\n\u003Cp>Das goldene Muster fuer sichere Smart Contracts:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Checks\u003C\u002Fstrong> — Alle Bedingungen pruefen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Effects\u003C\u002Fstrong> — Zustand aendern\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Interactions\u003C\u002Fstrong> — Externe Aufrufe durchfuehren\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function withdraw() external {\n    uint256 bal = balances[msg.sender]; \u002F\u002F Check\n    require(bal > 0, \"No balance\");\n    balances[msg.sender] = 0;           \u002F\u002F Effect (VORHER!)\n    (bool success, ) = msg.sender.call{value: bal}(\"\"); \u002F\u002F Interaction\n    require(success);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Reentrancy-Guards\u003C\u002Fh3>\n\u003Cp>Fuer zusaetzliche Sicherheit verwenden Sie einen Reentrancy-Guard:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">boolean private locked;\n\nmodifier noReentrancy() {\n    require(!locked, \"Reentrancy\");\n    locked = true;\n    _;\n    locked = false;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Mit EIP-1153 (Transient Storage) kann das Lock effizienter implementiert werden: TSTORE\u002FTLOAD statt SSTORE\u002FSLOAD, was 4.800 Gas pro Aufruf spart.\u003C\u002Fp>\n\u003Ch2 id=\"delegatecall-risiken\">delegatecall-Risiken\u003C\u002Fh2>\n\u003Cp>DELEGATECALL fuehrt den Code eines anderen Contracts im Speicherkontext des aufrufenden Contracts aus. Dies ist die Grundlage fuer Proxy-Muster, birgt aber erhebliche Risiken:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Der aufgerufene Code kann den Storage des aufrufenden Contracts beliebig aendern\u003C\u002Fli>\n\u003Cli>Storage-Slot-Kollisionen zwischen Proxy und Implementierung koennen Daten korrumpieren\u003C\u002Fli>\n\u003Cli>Wenn die Implementierung eine selfdestruct-Funktion hat, kann der Proxy zerstoert werden\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Gefaehrlich: Ungeprufter delegatecall\nfunction execute(address target, bytes calldata data) external {\n    (bool success, ) = target.delegatecall(data);\n    require(success);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"zugangskontrollmuster\">Zugangskontrollmuster\u003C\u002Fh2>\n\u003Cp>Fuer produktionsreife Smart Contracts verwenden Sie OpenZeppelins AccessControl:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">import \"@openzeppelin\u002Fcontracts\u002Faccess\u002FAccessControl.sol\";\n\ncontract MyContract is AccessControl {\n    bytes32 public constant ADMIN_ROLE = keccak256(\"ADMIN_ROLE\");\n    bytes32 public constant OPERATOR_ROLE = keccak256(\"OPERATOR_ROLE\");\n    \n    constructor() {\n        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);\n    }\n    \n    function adminFunction() external onlyRole(ADMIN_ROLE) {\n        \u002F\u002F Nur Admins\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"fazit\">Fazit\u003C\u002Fh2>\n\u003Cp>Smart-Contract-Sicherheit erfordert ein tiefes Verstaendnis des EVM-Ausfuehrungsmodells. msg.sender vs tx.origin, Reentrancy-Schutz, sichere delegatecall-Nutzung und rollenbasierte Zugangskontrolle sind die Grundpfeiler. Jeder externe Aufruf ist eine potenzielle Gefahr — behandeln Sie ihn entsprechend.\u003C\u002Fp>\n","de","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:29.921753Z","EVM-Sicherheits-Deep-Dive: msg.sender vs tx.origin, Reentrancy-Angriffe und Abwehr, delegatecall-Risiken und Zugangskontrollmuster fuer Smart Contracts.","EVM Sicherheit Reentrancy",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000013","Security","security",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","Blockchain",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0000000-0000-0000-0000-000000000680","Warum Bali 2026 zum Impact-Tech-Hub Südostasiens wird","warum-bali-2026-impact-tech-hub-suedostasiens","Bali rangiert auf Platz 16 unter den Startup-Ökosystemen Südostasiens. Mit einer wachsenden Konzentration von Web3-Entwicklern, AI-Nachhaltigkeits-Startups und Eco-Travel-Tech-Unternehmen formt die Insel ihre Nische als Impact-Tech-Hauptstadt der Region.","Ingenieurwesen","2026-03-28T10:44:49.720230Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0000000-0000-0000-0000-000000000679","ASEAN-Datenschutz-Flickenteppich: Compliance-Checkliste für Entwickler","asean-datenschutz-flickenteppich-compliance-checkliste-entwickler","Sieben ASEAN-Länder verfügen mittlerweile über umfassende Datenschutzgesetze mit unterschiedlichen Einwilligungsmodellen, Lokalisierungsanforderungen und Sanktionsstrukturen. Eine praktische Compliance-Checkliste für Entwickler.","2026-03-28T10:44:49.715484Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0000000-0000-0000-0000-000000000678","Indonesias 29-Milliarden-Dollar-Digitaltransformation: Chancen für Softwareunternehmen","indonesias-29-milliarden-dollar-digitaltransformation-chancen-softwareunternehmen","Indonesias IT-Dienstleistungsmarkt wird voraussichtlich 2026 29,03 Milliarden Dollar erreichen, gegenüber 24,37 Milliarden im Jahr 2025. Cloud-Infrastruktur, AI, E-Commerce und Rechenzentren treiben das schnellste Wachstum in Südostasien.","2026-03-28T10:44:49.697275Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":18,"linkedin":18,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]