일반적인 스마트 계약 취약점

스마트 계약 보안을 향상시키기 위해 개발자는 재창조 가드를 구현하고 Safemath Libraries를 사용하고 엄격한 액세스 제어를 시행하며 폴백 기능의 복잡한 논리를 피해야합니다.

2025/07/12 01:21

재창조 공격

스마트 계약에서 가장 악명 높은 취약점 중 하나는 재창조 공격 으로 2016 년 DAO 해킹으로 유명해졌습니다.이 취약점은 악성 계약이 초기 기능 실행이 완료되기 전에 원래 계약으로 다시 전화를 걸면 발생합니다. 결과적으로 적절한 점검없이 외부 통화를 처리하는 기능을 악용 할 수 있습니다.

재창조 공격을 방지하기 위해 개발자는 알려지지 않았거나 신뢰할 수없는 계약에 대한 외부 호출을 피해야합니다. 일반적인 완화 기술은 Checks-Effects-interactions 패턴을 사용하는 것입니다. 여기에는 외부 통화를하기 전에 계약 상태를 업데이트하는 것이 포함됩니다. 또한 Mutex 잠금 장치를 사용하여 Reentrancy Guard를 구현하면 재귀 통화를 차단하는 데 도움이 될 수 있습니다.

또 다른 방법은 OpenZeppelin의 ReentrancyGuard와 같은 잘 알려진 라이브러리를 사용하는 것입니다.이 라이브러리는 실행 중에 기능 재입국을 제한 할 수없는 수정자를 제공합니다. 개발자는 또한 이러한 공격으로 인한 잠재적 손상을 줄이기 위해 단일 전화로 전송할 수있는 에테르 또는 토큰의 양을 제한하는 것을 고려해야합니다.

정수 오버플로 및 언더 플로우

0.8.0 이전에 견고성 버전으로 작성된 스마트 계약은 정수 오버플로 및 언더 플로 에 취약합니다. 산술 연산이 UINT256과 같은 주어진 데이터 유형에 대한 최소 허용 값보다 최대 값을 초과하는 값을 초과 할 때 발생합니다.

예를 들어, 유형 UINT256의 변수가 값 0을 보유하고 감소하면 최대 값 (2^256-1)으로 유도되어 잘못된 잔액 또는 무단 액세스로 이어집니다. 이를 완화하기 위해 개발자는 OpenZeppelin이 제공하는 Safemath 라이브러리를 사용하여 산술 작업에 대한 명시 적 검사를 수행해야합니다.

Solidity 0.8.0으로 시작하여 이러한 검사는 기본적으로 활성화되며 산술 작업은 확인되지 않은 {...} 블록을 사용하여 명확하게 확인하지 않는 한 오류 또는 언더 플로에 오류가 발생합니다. 그러나이 내장 보호를 받더라도 성능 최적화를 위해 안전 점검을 비활성화 할 때 개발자는 신중해야합니다.

또한 모든 입력을 검증하고 특히 사용자가 제공 한 값 또는 토큰 전송과 관련된 동적 계산을 처리 할 때 수학 작업이 올바르게 제한되는지 확인하는 것이 중요합니다.

선두 주행 공격

이더 리움과 같은 공개 블록 체인에서는 거래가 채굴되기 전에 볼 수 있으므로 선두 주행 공격 의 문을 열어줍니다. 공격자는 보류중인 거래를 관찰하고 더 높은 가스 수수료로 자체적으로 제출하여 먼저 실행하여 결과를 조작 할 수 있습니다.

이 취약점은 일반적으로 분산 거래소 (DEX) 및 거래 주문이 중요한 기타 응용 프로그램에 영향을 미칩니다. 예를 들어, 사용자가 특정 가격으로 거래를 제출하면 공격자는 해당 거래를 앞두고 더 나은 요금을 얻고 효과적으로 가치를 훔칠 수 있습니다.

선두 주행을 방어하기 위해 개발자는 커밋 리베일 체계와 같은 메커니즘을 구현할 수 있습니다. 이 접근법에서 사용자는 먼저 해시 버전의 거래 (커밋 단계)를 제출하고 나중에 전체 세부 사항 (공개 단계)을 공개하여 공격자가 너무 늦을 때까지 정확한 조치를 알지 못하게합니다.

또는 계약 내에서 임의성 또는 시간 기반 조건을 사용하면 거래 결과를 예측하는 것이 더 어려워 질 수 있습니다. 그러나 진정한 임의성 온 체인은 도전적이므로 개발자는 종종 민감한 정보를 모호하게하기 위해 오프 체인 오라클 또는 암호화 약속에 의존합니다.

부적절한 액세스 제어

액세스 제어는 안전한 스마트 계약 개발의 중요한 측면입니다. 부적절한 액세스 제어는 권한있는 기능의 무단 실행으로 이어질 수 있으며, 공격자는 계약 상태를 변경하거나 자금을 배수하거나 계약 기능을 비활성화 할 수 있습니다.

전형적인 실수는 민감한 기능을 부를 수있는 사람을 제한하는 것이 아닙니다. 예를 들어, 계약 소유자 가만 호출 해야하는 함수는 전용 소유자 와 같은 수정자가 부족하여 누구나이를 호출 할 수 있습니다. 또 다른 문제는 사용 후 권한이 하드 코딩되거나 제대로 취소되지 않은 경우에 발생합니다.

이를 해결하기 위해 개발자는 OpenZeppelin 자체 및 역할 라이브러리에있는 것과 같은 역할 기반 액세스 제어 패턴을 사용해야합니다. 중요한 매개 변수를 변경하는 기능에는 발신자의 신원 또는 역할을 확인하는 요구 사항 또는 수정자가 포함되어야합니다.

또한, 다중 서명 지갑은 관리 조치에 사용될 수 있으며, 고위험 작업을 수행하기 전에 여러 승인이 필요합니다. 의도하지 않은 액세스 경로가 존재하지 않도록 허가 된 기능의 정기 감사 및 테스트는 필수적입니다.

서비스 거부 (DOS) 취약점

현명한 계약은 악의적 인 행위자가 합법적 인 사용자가 계약과 상호 작용하는 것을 방지하는 서비스 거부 (DOS) 공격의 피해자가 될 수 있습니다. 이는 과도한 가스 소비를 강제하거나 실행 경로를 막는 등 다양한 수단을 통해 발생할 수 있습니다.

한 가지 예는 에테르를 보내기 위해 일련의 주소를 통해 루프하는 계약입니다. 수신자 중 한 명이 과도한 가스를 소비하는 폴백 함수가 있거나 되돌아 가면 전체 루프가 실패하여 자금이 고정 될 수 있습니다.

DOS 위험을 완화하기 위해 개발자는 동적 배열에 의존하는 루프를 피해야합니다. 대신, 오프 체인 솔루션 또는 풀오버 푸시 결제 모델을 구현할 수 있으며, 여기서 사용자는 자동으로 자금을 푸시하지 않고 인출을 시작합니다.

또한, 계약에는 관리자에 의한 수동 개입을 허용하거나 실패한 작업을 재 시도하는 것과 같은 고장의 경우 폴백 메커니즘이 포함되어야합니다. 기능 호출 내에서 가스 한계 및 시간 초과를 사용하면 무기한 차단을 방지 할 수 있습니다.

폴백 기능 취약점

폴백 기능은 에테르 전송 또는 인식되지 않은 기능 호출의 기본 핸들러 역할을합니다. 그러나 신중하게 설계되지 않으면 심각한 보안 결함을 도입 할 수 있습니다. 폴백 함수는 간단하게 유지해야하며 복잡한 논리 또는 상태 변경을 포함해서는 안됩니다.

주목할만한 위험은 폴백 함수에 루프가 포함되거나 다른 계약을 호출하여 가스 외 예외 또는 재창조 가능성을 높일 때입니다. 또한 계약이 폴백을 통해 에테르 수신에 의존하지만 발신자가 송신 () 또는 send ()를 사용하는 시나리오를 설명하지 않으면 제한된 가스가 전달되어 예기치 않게 실패 할 수 있습니다.

개발자는 폴백 기능이 최소한의 논리로 되돌리거나 처리하여 예기치 않은 에테르를 거부하도록해야합니다. 또한 Solidity 0.6.0에 도입 된 수신 () 및 Follback () 기능을 사용하여 지불 할 수없고 지불 할 수없는 폴백 동작을 분리하는 것이 좋습니다.

폴백 논리를 철저히 감사하고 사용자 지정 폴백으로 계약에서 에테르를 보내는 것과 같은 테스트 엣지 케이스는 혼란이나 악용을 피하기 위해 필수적입니다.

자주 묻는 질문

스마트 계약 취약점을 감지하기 위해 어떤 도구를 사용할 수 있습니까?

Slither, Mythx 및 Oyente와 같은 정적 분석 도구를 사용하여 일반적인 취약점을 식별 할 수 있습니다. OpenZeppelin Defender와 같은 플랫폼은 런타임 모니터링 및 디버깅 기능을 부드럽게 제공합니다. 자동화 된 도구를 수동 코드 리뷰와 항상 포괄적 인 커버리지를 위해 공식적인 검증을 결합하십시오.

스마트 계약에서 재창조를 어떻게 테스트 할 수 있습니까?

기능을 다시 입력하도록 설계된 악성 계약에 대한 외부 통화를 시뮬레이션하는 단위 테스트를 작성하십시오. HardHat 또는 Truffle 프레임 워크를 사용하여 모의 계약을 배포하고 상호 작용하십시오. Echidna와 같은 퍼징 도구를 활용하여 에지 케이스 테스트를 자동화 할 수도 있습니다.

견고성에 인라인 어셈블리를 사용하는 것이 안전합니까?

인라인 어셈블리는 EVM에 대한 낮은 수준의 제어를 부여하지만 많은 Solidity의 안전 기능을 우회합니다. 숙련 된 개발자 만 사용하고 철저히 검토해야합니다. 최적화 또는 특정 EVM 기능에 절대적으로 필요하지 않은 한 사용하지 마십시오.

배포 후 계약을 안전하게 업그레이드 할 수 있습니까?

예, 프록시 패턴을 사용하는 업그레이드 가능한 계약은 상태를 보존하는 동안 업데이트를 허용합니다. 그러나 그들은 복잡성과 새로운 공격 표면을 도입합니다. OpenZeppelin의 Transparent 또는 UUPS 프록시와 같은 확립 된 업그레이드 가능성 패턴을 사용하고 적절한 액세스 제어 및 철저한 테스트를 보장합니다.