재창조 공격이란 무엇입니까?

핵심 사항 :

• 재창조 공격은 스마트 계약의 취약성을 공격하여 초기 통화가 완료되기 전에 기능을 반복적으로 호출하거나 자금을 배출하거나 다른 악의적 인 조치를 유발합니다.
• 핵심 취약점은 상태 업데이트가 완료되기 전에 재입국을 방지하기 위해 적절한 점검이 부족한 상태입니다.
• 예방에는 CEI (Checks-Effects-Interaction) 패턴을 사용하여 모든 외부 통화가 완료된 후에 만 ​​계약 상태를 수정하는 것이 포함됩니다.
• 재창조 취약점을 이해하는 것은 안전하고 안정적인 스마트 계약을 개발하는 데 중요합니다.

재창조 공격이란 무엇입니까?

재창조 공격은 이더 리움과 같은 블록 체인 플랫폼에서 스마트 계약을 대상으로하는 악용 유형입니다. 초기 통화가 완전히 실행되기 전에 악성 계약이 대상 계약 내에서 함수를 반복적으로 호출 할 수있는 취약점을 활용합니다. 이를 통해 공격자는 계약의 상태를 조작하고 자금을 배수하거나 다른 원치 않는 행동을 유발할 수 있습니다. 핵심 문제는 스마트 계약 내에서 외부 통화의 비동기 특성에서 비롯됩니다.

재창조 공격은 어떻게 작동합니까?

withdraw 기능과의 현명한 계약을 상상해보십시오. 사용자는이 기능을 호출하여 자금을 인출합니다. 계약이 재창조를 제대로 처리하지 않으면 계약이 withdraw 기능을 반영하기 위해 내부 상태를 업데이트하기 전에 악성 계약이 인출 기능 실행 내에서 withdraw 기능을 다시 호출 할 수 있습니다. 이것은 계약이 고갈 될 때까지 공격자가 반복적으로 자금을 인출하는 루프를 만듭니다.

취약점 : 상태 업데이트 부족

재 신석 취약점의 근본 원인은 스마트 계약 내에서 운영 순서에 있습니다. 이상적으로, 계약은 먼저 철수가 허용되는지 확인한 다음 인출을 수행 한 다음 마지막으로 내부 상태를 업데이트해야합니다. 그러나 철수가 완전히 처리되기 전에 상태 업데이트가 발생하면 악의적 인 행위자는이 격차를 악용하여 기능을 반복적으로 호출 할 수 있습니다.

Checks-Effects-Interactions (CEI) 패턴

재창조 공격을 방지하는 가장 효과적인 방법은 CEI (Checks-Effects-Interaction) 패턴을 따르는 것입니다. 이 패턴은 운영 순서를 지시합니다.

• 점검 : 함수의 모든 조건이 충족되었는지 확인하십시오. 여기에는 충분한 균형, 승인 등이 포함됩니다.
• 효과 : 계약의 내부 상태를 수정하십시오. 여기에는 잔액 업데이트, 토큰 전송 등이 포함됩니다.
• 상호 작용 : 자금 발송 또는 다른 계약과의 상호 작용을 포함하여 외부 전화를합니다.

상태가 업데이트 된 후 외부 통화를 배치함으로써 공격자는 최초 통화가 완료되기 전에 함수를 다시 입력하고 상태를 조작 할 수 없습니다.

실제 예 : 재창조 방지

단순화 된 withdraw 기능을 고려해 봅시다.

취약한 코드 :

 function withdraw(uint amount) public { require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; send(msg.sender, amount); //External call before state update. }

보안 코드 (CEI 사용) :

 function withdraw(uint amount) public { require(balances[msg.sender] >= amount); uint amountToSend = amount; //Store amount locally balances[msg.sender] -= amountToSend; //State update before external call send(msg.sender, amountToSend); }

보안 버전은 외부 send 통화를하기 전에 잔액을 업데이트하여 재입국을 방지합니다. 이것은 단순화 된 예입니다. 실제로보다 강력한 기술이 필요할 수 있습니다.

다른 완화 전략

CEI 패턴 외에 다른 전략은 재창조 위험을 완화하는 데 도움이 될 수 있습니다. 여기에는 다음이 포함됩니다.

• Reentrancy Guard 사용 : 함수가 호출 될 때 true로 설정된 부울 변수를 사용하여 완료된 후에 만 ​​재설정됩니다. 가드가 진실한 동안 다시 입력하려는 시도는 차단됩니다.
• 라이브러리 및 외부 통화를 신중하게 사용 : 외부 통화를 최소화하고 계약 내에서 사용되는 외부 라이브러리를 철저히 감사합니다.

자주 묻는 질문 (FAQ)

Q : 모든 스마트 계약이 재창조 공격에 취약합니까?

A : 아니요. 기능 논리에서 취약점을 가진 스마트 계약 만, 특히 CEI 패턴을 따르거나 다른 적절한 보호 장치를 사용하지 않는 사람들은 민감합니다.

Q : 스마트 계약에서 재창조 취약점을 어떻게 감지 할 수 있습니까?

A : 재창조 취약점을 감지하는 데 숙련 된 전문가의 공식 검증 도구, 수동 코드 검토 및 보안 감사가 필수적입니다. 정적 분석 도구는 잠재적 인 문제를 식별하는 데 도움이 될 수 있습니다.

Q : 성공적인 재창조 공격의 결과는 무엇입니까?

A : 성공적인 재창조 공격은 자금 손실, 계약 상태 조작 및 스마트 계약의 의도 된 기능 중단으로 이어질 수 있습니다. 공격자는 통제권을 얻고 모든 자산의 계약을 배출 할 수 있습니다.

Q : 재창조 공격을 자동으로 방지하는 도구가 있습니까?

A : 완전한 예방을 보장하는 단일 도구는 없지만 일부 도구는 잠재적 인 취약점을 감지하기위한 정적 분석을 제공합니다. 그러나 수동 코드 검토 및 보안 감사는 포괄적 인 보호를 위해서는 여전히 중요합니다. CEI 패턴과 같은 확립 된 모범 사례에 따라 가장 중요합니다.

Q : 재창조 공격은 얼마나 흔합니까?

A : 재창조 공격은 다른 취약성만큼 널리 퍼지지는 않았지만 역사적으로 재정적 손실이 발생했습니다. 그들은 스마트 계약 개발에서 강력한 보안 관행의 중요성을 강조합니다. 2016 년 DAO 해킹은 이러한 유형의 공격의 치명적인 영향의 대표적인 예입니다.

Q : 배포 후 재창조 취약점을 수정할 수 있습니까?

A : 배치 후 재창조 취약점을 수정하는 것은 어려우며 종종 새로운 계약 배포가 필요합니다. 계약의 심각성과 성격에 따라 신중하게 계획된 업그레이드가 가능할 수 있습니다. 그러나이를 위해서는 수정이 새로운 취약점을 도입하지 않도록 광범위한 테스트가 필요합니다.