재창조 공격이란 무엇입니까? 이 취약성을 방지하는 방법은 무엇입니까?

재생 공격은 스마트 계약 결함을 이용하여 상태 해결 전에 반복 된 기능 호출을 허용하여 무단 조치로 이어집니다. 점검 효과 상호 작용 패턴으로 방지하십시오.

2025/04/12 00:35

재창조 공격은 스마트 계약, 특히 이더 리움 블록 체인에서 발생할 수있는 보안 취약성의 한 유형입니다. 이 공격은 계약의 논리에서 결함을 악용하여 공격자가 최초 통화가 완전히 해결되기 전에 반복적으로 함수를 호출 할 수있게합니다. 이로 인해 무단 철수 또는 기타 악의적 인 행동이 발생할 수 있습니다. 이 기사에서는 재창조 공격의 역학을 탐구하고 실제 사례를 검토하며 스마트 계약에서 이러한 취약성을 방지하는 방법에 대한 자세한 지침을 제공합니다.

재창조 공격 이해

재창조 공격은 스마트 계약이 자체 상태 변경을 해결하기 전에 외부 계약을 호출 할 때 발생합니다. 이를 통해 외부 계약이 원래 계약에 다시 들어가서 상태를 조작 할 수있는 기회의 창을 만들 수 있습니다. 이 공격에는 일반적으로 피해자 계약이 잔액을 업데이트하기 전에 withdraw() 과 같은 기능을 반복적으로 호출하여 피해자 계약의 자금을 배출하는 악성 계약이 포함됩니다.

예를 들어, 사용자가 자금을 입금하고 인출 할 수있는 계약의 간단한 예를 고려하십시오.

 contract Vulnerable { mapping(address => uint) public balances; function deposit() public payable { balances[msg.sender] += msg.value; } function withdraw(uint amount) public { require(balances[msg.sender] >= amount, 'Insufficient balance'); (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed'); balances[msg.sender] -= amount; }

}

이 예에서 withdraw 기능은 먼저 사용자가 충분한 잔액을 가지고 있는지 확인한 다음 자금을 사용자에게 보내려고 시도하고 마지막으로 사용자의 잔액을 업데이트합니다. 취약점은 msg.sender.call 에 대한 외부 호출이 끝날 때까지 balances[msg.sender] 이 업데이트되지 않는다는 사실에 있습니다. msg.sender 악의적 인 계약 인 경우 잔액이 업데이트되기 전에 withdraw 기능을 다시 입력 할 수있어 잔액이 0으로 설정되기 전에 여러 인출이 가능합니다.

재창조 공격의 실제 사례

2016 년 DAO 해킹 에서 가장 악명 높은 재진 공격 중 하나가 발생했습니다. DAO (분산 된 자율 조직)는 사용자가 프로젝트에 투자 할 수있는 이더 리움 블록 체인의 현명한 계약이었습니다. 계약은 위에서 설명한 것과 유사한 취약성을 가졌으며, 이로 인해 공격자는 DAO에서 약 360 만 ETH를 배출 할 수있었습니다.

또 다른 예는 2017 년의 Parity Wallet Hack 입니다. Ethereum에서 인기있는 다중 서명 지갑 인 Parity Wallet은 재창조 취약점으로 인해 악용되었습니다. 공격자는 여러 지갑에서 자금을 배수 할 수있어 사용자에게 상당한 손실이 발생했습니다.

재창조 공격을 방지하는 방법

재창조 공격을 방지하려면 스마트 계약을 신중하게 설계하고 구현해야합니다. 이 취약점을 완화하기위한 몇 가지 전략은 다음과 같습니다.

Checks-Effects-Interactions 패턴을 사용하십시오

Checks-Effects-interactions 패턴은 안전한 스마트 계약을 작성하는 모범 사례입니다. 이 패턴은 외부 통화가 실행되기 전에 모든 상태 변경이 이루어 지도록합니다. withdraw 기능의 맥락에서 자금을 보내기 전에 사용자의 잔액을 업데이트하는 것을 의미합니다.

 contract Secure { mapping(address => uint) public balances; function deposit() public payable { balances[msg.sender] += msg.value; } function withdraw(uint amount) public { require(balances[msg.sender] >= amount, 'Insufficient balance'); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed'); }

}

외부 호출을하기 전에 잔액을 업데이트함으로써 계약은 재창조가 발생하기 전에 사용자의 잔액이 올바르게 설정되도록합니다.

인출 패턴을 사용하십시오

재창조 공격을 방지하는 또 다른 효과적인 방법은 인출 패턴을 사용하는 것입니다. 계약은 사용자에게 자금을 직접 보내는 대신 인출 금액을 저장하고 사용자가 나중에 자금을 뽑을 수 있도록합니다. 이 접근법은 인출 과정에서 외부 통화의 필요성을 제거합니다.

 contract WithdrawalPattern { mapping(address => uint) public balances; mapping(address => uint) public withdrawalPending; function deposit() public payable { balances[msg.sender] += msg.value; } function requestWithdrawal(uint amount) public { require(balances[msg.sender] >= amount, 'Insufficient balance'); balances[msg.sender] -= amount; withdrawalPending[msg.sender] += amount; } function withdraw() public { uint amount = withdrawalPending[msg.sender]; require(amount > 0, 'No pending withdrawal'); withdrawalPending[msg.sender] = 0; (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed'); }

}

이 예에서는 requestWithdrawal 기능이 사용자의 잔액을 업데이트하고 인출 금액을 withdrawalPending 때 저장합니다. withdraw 기능은 재창조의 위험없이 자금을 사용자에게 보냅니다.

Reentrancy Guards를 구현하십시오

Reentrancy Guards는 재창조 공격을 방지하는 또 다른 기술입니다. 이 경비원은 상태 변수를 사용하여 기능이 현재 실행 중인지 추적합니다. 함수가 다시 들어 오면 가드는 추가 실행을 방지합니다.

 contract ReentrancyGuard { bool private _notEntered; constructor() { _notEntered = true; } modifier nonReentrant() { require(_notEntered, 'ReentrancyGuard: reentrant call'); _notEntered = false; _; _notEntered = true; } function withdraw(uint amount) public nonReentrant { require(balances[msg.sender] >= amount, 'Insufficient balance'); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed'); }

}

nonReentrant 수정자는 여전히 실행중인 동안 withdraw 기능을 다시 입력 할 수 없도록합니다.

재창조 취약점 테스트 및 감사

예방 조치를 구현하는 것 외에도 재창조 취약점에 대한 스마트 계약을 철저히 테스트하고 감사하는 것이 중요합니다. 다음은 다음과 같은 단계입니다.

• 단위 테스트 : 재창조 공격을 시뮬레이션하는 단위 테스트를 작성하여 그러한 조건에서 계약이 올바르게 작동하도록합니다.
• 정적 분석 : Mythril 및 Slither 와 같은 도구를 사용하여 코드에서 잠재적 인 재창조 취약점을 자동으로 감지하십시오.
• 수동 감사 : 경험이 풍부한 스마트 계약 감사자가 잠재적 인 재창조 문제에 대한 코드를 검토했습니다. 수동 감사는 자동화 된 도구를 놓칠 수있는 복잡한 취약점을 발견 할 수 있습니다.

스마트 계약 개발을위한 모범 사례

재창조 공격의 위험을 더욱 줄이려면 다음 모범 사례를 고려하십시오.

• 계약을 간단하게 유지하십시오 : 복잡한 계약에는 취약점이 포함될 가능성이 높습니다. 계약을 최대한 간단하고 간단하게 유지하십시오.
• 기존 라이브러리 사용 : 공통 계약 패턴의 안전한 구현을 제공하는 OpenZeppelin 과 같은 잘 알려진 라이브러리 및 프레임 워크를 활용하십시오.
• 정기적 인 업데이트 : 최신 보안 모범 사례에 대한 정보를 유지하고 그에 따라 계약을 업데이트하십시오.

자주 묻는 질문

Q : 이더 리움 외에 다른 블록 체인 플랫폼에서 재창조 공격이 발생할 수 있습니까?

A : 재생 공격은 스마트 계약의 광범위한 사용으로 인해 Ethereum과 가장 일반적으로 관련이 있지만 Binance Smart Chain 및 Solana와 같은 스마트 계약을 지원하는 다른 블록 체인 플랫폼에서도 유사한 취약점이 발생할 수 있습니다. 재창조 공격 방지 원칙은 다른 플랫폼에서 동일하게 유지됩니다.

Q : 재창조 취약점을 감지하기 위해 특별히 설계된 도구가 있습니까?

A : 그렇습니다. 여러 도구는 스마트 계약에서 재창조 취약점을 감지하도록 설계되었습니다. Mythril and Slither 는 잠재적 인 재창조 문제를 식별 할 수있는 인기있는 정적 분석 도구입니다. 또한 Echidna는 자동화 된 테스트 케이스 생성을 통해 재창조 취약점을 테스트하는 데 사용할 수있는 속성 기반 테스트 도구입니다.

Q : 보안 전문가가 아닌 경우 스마트 계약이 재창조 공격에 대해 어떻게 보장되도록하려면 어떻게해야합니까?

A : 보안 전문가가 아닌 경우 전문가 스마트 계약 감사원을 참여하여 코드를 검토하는 것이 좋습니다. 또한 OpenZeppelin 과 같은 확립 된 라이브러리를 사용하고 Checks-Effects-Interactions 패턴과 같은 모범 사례를 사용하면 재창조 취약점의 위험이 크게 줄어들 수 있습니다. 스마트 계약 보안에 대한 지식을 정기적으로 업데이트하고 커뮤니티 토론에 참여하면 최신 보안 관행에 대한 정보를 유지하는 데 도움이 될 수 있습니다.