상위 5가지 스마트 계약 보안 취약점 및 이를 방지하는 방법

재진입 공격

1. 초기 실행이 완료되기 전에 외부 계약이 현재 계약을 다시 호출할 때 재진입 취약성이 발생합니다.

2. 이 결함으로 인해 공격자는 상태 변수가 업데이트되기 전에 출금 기능을 반복적으로 호출하여 자금을 빼낼 수 있습니다.

3. 2016년 악명 높은 DAO 해킹은 바로 이 패턴을 악용하여 6천만 달러 상당의 ETH가 손실되는 결과를 가져왔습니다.

4. 개발자는 검사-효과-상호작용 패턴을 적용하여 모든 상태 변경이 외부 호출 전에 발생하도록 하여 이러한 위험을 완화할 수 있습니다.

5. OpenZeppelin의 ReentrancyGuard 수정자를 사용하면 민감한 기능에 대한 재귀적 진입을 방지하는 잠금 메커니즘이 추가됩니다.

정수 오버플로 및 언더플로

1. Solidity 0.8.0 이전에는 산술 연산이 오버플로 또는 언더플로 시 자동으로 복귀되지 않았습니다.

2. 공격자는 값을 강제로 순환시켜 균형을 조작할 수 있습니다. 예를 들어 0에서 빼면 엄청난 양수를 생성할 수 있습니다.

3. 2018년에 BeautyChain 프로젝트는 언더플로우로 인해 무단 토큰 발행이 발생하는 심각한 악용을 겪었습니다.

4. Solidity 0.8.0+으로 업그레이드하면 내장 검사가 이제 자동 되돌리기를 트리거하므로 컴파일러 수준에서 이 문제가 해결됩니다.

5. 여전히 이전 버전을 사용하는 레거시 코드베이스의 경우 모든 산술 연산에 SafeMath 라이브러리를 명시적으로 가져와 사용해야 합니다.

확인되지 않은 외부 통화

1. 계약에서는 반환 값을 확인하거나 실패를 처리하지 않고 외부 호출이 성공할 것이라고 가정하는 경우가 많습니다.

2. 호출된 계약이 되돌리거나 자동으로 실패하는 경우 호출 계약은 상태에 대해 유효하지 않은 가정을 진행할 수 있습니다.

3. Parity Wallet 해킹에서는 라이브러리 계약에 대한 확인되지 않은 호출을 통해 악의적인 행위자가 지갑 소유권을 탈취할 수 있었습니다.

4. 항상 명시적인 성공 검증과 함께 require(call.success, '외부 호출 실패') 또는 하위 수준 호출을 사용하십시오.

5. 꼭 필요한 경우가 아니면 위임자 호출을 피하세요. 잘못 사용된 대리자 호출은 저장소 충돌 및 임의 코드 실행으로 이어질 수 있습니다.

공개 거래를 통한 선행 실행

1. 이더리움의 mempool은 보류 중인 트랜잭션을 블록에 포함하기 전에 모든 검증자와 검색자에게 공개합니다.

2. 공격자는 대규모 스왑이나 거버넌스 제안과 같은 수익성 있는 기회를 모니터링하고 더 높은 가스 요금으로 경쟁 거래를 제출합니다.

3. 2020년에 선두 봇은 변동성이 큰 시장 변화 중에 Uniswap v2 유동성 공급자로부터 1,200만 달러 이상을 추출했습니다.

4. 경매 입찰이나 거버넌스 투표와 같은 중요한 작업에 대한 커밋-공개 체계를 구현합니다.

5. Flashbots Protect와 같은 개인 거래 릴레이를 사용하거나 임계값 암호화를 통합하여 실행될 때까지 의도를 모호하게 합니다.

액세스 제어의 논리 오류

1. 잘못 구성된 수정자 또는 결함이 있는 역할 할당 논리로 인해 승인되지 않은 사용자에게 관리자 권한이 부여될 수 있습니다.

2. Cream Finance 사건에서는 소유자 이전 기능의 로직 버그로 인해 공격자가 자신을 새로운 소유자로 설정할 수 있었습니다.

3. 배포 후 하드코딩된 주소 또는 누락된 소유권 포기로 인해 지속적인 공격 표면이 생성됩니다.

4. Gnosis Safe와 같은 표준을 사용하여 권한 있는 기능에 대한 다중 서명 요구 사항을 시행합니다.

5. 모든 onlyOwner , onlyRole 및 사용자 정의 액세스 한정자에 대해 수동 감사를 수행하여 상속 경로를 확인하고 안전성을 재정의합니다.

자주 묻는 질문

Q: 공식 검증으로 모든 스마트 계약 취약점을 제거할 수 있습니까? A: 공식 검증은 모든 입력에 특정 속성이 적용된다는 것을 수학적으로 증명하지만 비즈니스 로직 결함, 경제적 공격 또는 외부 프로토콜과의 통합 문제를 다룰 수는 없습니다.

Q: 다른 프로젝트에서 감사된 코드를 재사용해도 안전합니까? A: 본질적으로는 그렇지 않습니다. 감사된 코드에도 새로운 환경에 배포할 때 상황별 가정, 오래된 종속성 또는 테스트되지 않은 엣지 케이스가 포함될 수 있습니다.

Q: 테스트넷은 메인넷 보안 조건을 완전히 복제합니까? A: 아니요. 테스트넷에는 실질적인 경제적 인센티브가 부족하고 채굴자의 행동이 다르며 수정된 클라이언트 버전을 실행하는 경우가 많습니다. 따라서 선두 실행 또는 그리핑 벡터를 탐지하는 데 불충분합니다.

Q: 오라클 조작은 스마트 계약 취약점과 어떤 관련이 있나요? A: Oracle 조작은 그 자체로 계약 수준의 버그는 아니지만 중앙 집중식 또는 낮은 적용 범위의 가격 피드에 의존하는 계약은 시스템적 위험을 상속합니다. 예를 들어 허위 데이터를 제공하는 손상된 단일 노드는 DeFi 프로토콜 전반에 걸쳐 청산을 유발할 수 있습니다.