스마트 계약에서 일반적인 보안 위험을 피하는 방법은 무엇입니까?

스마트 계약 취약점 이해

1. 재진입 공격은 상태 변경이 완료되기 전에 외부 계약이 현재 계약을 다시 호출하는 이더리움 기반 스마트 계약에서 가장 많이 악용되는 약점 중 하나로 남아 있습니다.

2. 산술 연산이 uint256에서 지원하는 최대값 또는 최소값을 초과하면 정수 오버플로 및 언더플로 문제가 발생하여 예기치 않은 잔액 재설정이나 자금 중복이 발생합니다.

3. 수신자 계약에 폴백 기능이 없거나 예기치 않게 되돌리면 확인되지 않은 외부 호출로 인해 자동 실패가 발생하여 중요한 논리가 필수 검증을 우회할 수 있습니다.

4. 부적절한 액세스 제어를 통해 승인되지 않은 사용자가 소유자 전용 철회 또는 업그레이드 메커니즘과 같은 권한 있는 기능을 호출하여 자산을 도난 또는 조작에 노출시킬 수 있습니다.

5. 타임스탬프 의존성은 블록 타임스탬프가 채굴자에 의해 제어되고 15초 창 내에서 조작될 수 있으므로 비결정성을 도입하여 베스팅 일정과 같이 시간에 민감한 논리를 손상시킵니다.

코드 감사 모범 사례

1. Slither 및 MythX와 같은 정적 분석 도구는 위험한 대리자 호출 사용, 보호되지 않은 자체 파괴 지침 및 초기화되지 않은 스토리지 포인터를 포함한 일반적인 안티 패턴을 감지합니다.

2. Certora Prover와 같은 도구를 사용한 공식 검증은 지정된 불변성 준수를 수학적으로 증명하여 기능이 균형 보존 또는 액세스 제한을 위반하지 않도록 보장합니다.

3. 수동 피어 검토에는 모든 외부 호출 경로 추적, 모든 require() 문이 되돌릴 수 없는 작업 전에 입력 유효성과 상태 일관성을 모두 적용하는지 확인하는 작업이 포함되어야 합니다.

4. 가스 제한을 고려하려면 사용자 제공 어레이에 맞게 확장되는 루프에 대한 테스트가 필요하며 실행 중 과도한 가스 소비로 인한 서비스 거부를 방지해야 합니다.

5. 컴파일러 버전 고정은 Solidity 업데이트의 예기치 않은 동작을 방지합니다. 0.8.0 이전 버전으로 컴파일된 계약에는 명시적으로 구현되지 않는 한 내장 오버플로 검사가 부족합니다.

배포 및 업그레이드 보호 장치

1. 다중 서명 지갑은 소유권 이전 및 관리 조치를 관리하여 하드코딩된 소유자 주소와 관련된 단일 지점 실패 위험을 제거해야 합니다.

2. 프록시 패턴은 로직과 스토리지 계약을 신중하게 분리해야 합니다. 구현과 프록시 간의 부적절한 스토리지 슬롯 정렬로 인해 심각한 상태 손상이 발생할 수 있습니다.

3. 긴급 일시 중지 기능을 사용하면 이상 현상이 감지된 동안 핵심 작업을 일시적으로 중지할 수 있지만 일시 중지 트리거는 선행 실행으로부터 보호되어야 하며 다자간 합의가 필요합니다.

4. 불변 초기화는 배포 후 생성자 로직에 다시 진입하는 것을 방지하여 초기 공급 생성 또는 수수료 매개변수 설정과 같은 설정 루틴이 정확히 한 번 실행되도록 보장합니다.

5. Etherscan의 바이트코드 검증은 온체인 코드가 감사된 소스와 일치하는지 확인하여 손상된 툴체인 또는 CI 파이프라인을 통해 배포하는 동안 악의적인 대체를 차단합니다.

프런트엔드 상호작용 위험

1. EIP-712 유형 데이터 서명의 서명 유연성으로 인해 도메인 구분자 해시가 체인 ID 또는 버전 필드를 생략하는 경우 공격자가 승인을 위조할 수 있습니다.

2. 지갑 연결 하이재킹은 dApp이 MetaMask 또는 WalletConnect 핸드셰이크 중에 악성 스크립트를 주입하여 개인 키를 캡처하거나 트랜잭션 페이로드를 가로챌 때 발생합니다.

3. 불충분한 거래 미리보기로 인해 사용자는 무제한 토큰 허용으로 공격자가 제어하는 ​​계약에 영구적으로 액세스할 수 있는 "승인" 함정에 노출됩니다.

4. RPC 엔드포인트 조작을 통해 악성 사이트는 불량 노드를 통해 쿼리를 라우팅하고 위조된 잔액이나 조작된 이벤트 로그를 반환하여 사용자 결정을 오도할 수 있습니다.

5. 피싱 방지 도메인 바인딩을 위해서는 등록된 dApp 도메인에 대해 지갑에서 보낸 메시지를 엄격하게 검증하고 스푸핑된 출처의 서명을 거부해야 합니다.

자주 묻는 질문

Q: 프록시를 사용하지 않고 배포 후 스마트 계약을 업데이트할 수 있습니까? A: 아니요. 일단 배포되면 바이트코드는 Ethereum에서 변경할 수 없습니다. 모든 변경에는 새 계약을 배포하고 수동으로 또는 타사 조정을 통해 상태를 마이그레이션해야 합니다.

Q: 인증을 위해 Solidity의 tx.origin을 사용해도 안전합니까? A: 아니요. tx.origin은 트랜잭션 체인을 시작하는 원래 EOA 주소를 반환하며 악의적인 계약을 통해 스푸핑될 수 있으므로 액세스 제어가 안전하지 않습니다.

Q: 계약 실행 중에 가스가 부족해지면 어떻게 되나요? A: 전체 트랜잭션이 되돌려지고 모든 상태 변경 사항이 복원되지만 소비된 가스는 상실됩니다. 여기에는 실패한 보내기, 명령문 요구 및 명시적 되돌리기가 포함됩니다.

Q: 일부 계약에서는 스토리지 잔액을 추적하는 대신 address(this).balance를 사용하는 이유는 무엇입니까? A: address(this).balance 를 사용하면 스토리지 쓰기를 방지하고 가스 비용을 줄일 수 있지만 ERC-20 토큰이 아닌 ETH만 반영하며 복잡한 회계 논리를 나타낼 수 없습니다.