BNB 체인은 Web3 세계에서 가장 인기 있는 블록체인 중 하나이며, 합리적인 수수료, 빠른 거래, 풍부한 프로젝트 생태계로 많은 사용자를 끌어 모으고 있습니다. 모든 블록체인과 마찬가지로 BNB 체인의 개발자는 개발 과정에서 먼저 보안 문제를 고려해야 합니다. 자금 손실로 인해 프로토콜과 플랫폼에 대한 사용자의 신뢰가 약화되고 보안 위반 및 해커 공격은 개발자가 직면하는 가장 큰 위험 중 하나이기 때문입니다.
이 기사에서는 개발자가 BNB 체인에서 위험을 줄이고 보다 안전한 스마트 계약을 개발할 수 있도록 10가지 실용적인 보안 팁을 제공합니다.
01
/ 정의 /
재생 공격 및 재생 공격이라고도 알려진 재생 공격은 블록체인 환경에서 일반적인 공격 유형입니다. 네트워크 보안에서는 재연공격"”은 유효한 데이터 전송이 악의적 또는 사기적으로 반복되거나 지연되는 일종의 사이버 공격입니다.
Web3 및 스마트 계약의 맥락에서 이는 공격자가 원래 사용자의 허가 없이 스마트 계약에서 트랜잭션이나 작업을 반복할 수 있음을 의미하는 경우가 많습니다. 이로 인해 이중 지출 등 다양한 형태의 사기가 발생할 수 있습니다.
이러한 공격은 공격자가 동일한 서명을 재사용하여 스마트 계약의 모든 자금이나 기타 자산에 무단 액세스할 수 있도록 허용하므로 사용자와 개발자에게 심각한 결과를 초래합니다.
재생 공격을 방지하려면 개발자는 스마트 계약 코드를 신중하게 설계 및 구현하고 서명 확인은 물론 업계 최고의 보안 표준을 따라야 합니다.
02
／ 사례 분석 ／
다음 코드 조각은 BNB 체인의 토큰 전송 구현 프로세스를 나타냅니다. 해당 코드는 재생 공격에 취약하므로 공격자가 동일한 서명을 재사용할 수 있습니다.
이 기능에는 nonce 또는 재생 보호 기능이 없기 때문에 공격자가 서명된 전송을 여러 번 재생할 수 있습니다. 공격자는 서명된 트랜잭션을 가로채서 동일한 계약이나 다른 계약으로 다시 보낼 수 있으며 계약은 여전히 유효한 것으로 간주하므로 공격자는 이 취약점을 악용하여 자산을 훔칠 수 있습니다.
03
／ 개선방법 ／
서명에 nonce를 추가하거나 매핑 변수를 사용하여 서명을 기록합니다. 그 중 구체적인 솔루션은 프로젝트 설계에 따라 달라집니다.
01
/ 정의 /
재진입 공격은 초기 호출이 완료되기 전에 악의적인 계약이 취약한 계약을 반복적으로 호출할 때 발생합니다. 즉, 공격자는 취약한 계약을 속여 하나의 거래를 완료하고 다음 거래로 자유롭게 이동할 수 있다고 생각하지만 실제로는 여전히 공격자의 악성 코드를 실행하고 있습니다.
이로 인해 공격자가 예상치 못한 방식으로 계약 상태를 조작하고 잠재적으로 승인되지 않은 자금을 얻을 수 있게 됩니다.
02
／ 사례 분석 ／
아래 코드 조각에서 사용자는 출금 출금 기능을 호출하고 출금하려는 금액을 지정하여 자신의 계좌에서 자금을 출금할 수 있습니다. 그러나 철회 함수는 함수에 대한 재귀 호출을 방지하지 않으므로 재진입 공격에 취약합니다.
공격자는 실제로 자신의 계정에서 잔액이 차감되기 전에 출금 기능을 여러 번 호출하는 악의적인 계약을 생성하여 취약점을 악용할 수 있습니다. msg.sender.call 함수는 악성 계약에 자금을 전송하며 공격자는 잔액이 0으로 줄어들기 전에 악의적 계약의 receive() 함수를 통해 반복적으로 자금을 인출하여 피해자 계약의 모든 자금을 빼냅니다.
03
／ 개선방법 ／
상태 업데이트는 외부 호출 전에 이루어집니다.
이 패턴을 Check-Effects-Interact 패턴이라고 하며 스마트 계약에서 재진입 공격을 방지하는 데 사용되는 디자인 패턴입니다. 이 패턴은 먼저 전제 조건을 확인한 다음 외부 호출을 하기 전에 상태를 업데이트하여 외부 호출에서 다른 계약에 대한 상태 변경을 분리합니다. 이렇게 하면 외부 호출이 계약을 다시 호출하려고 시도하는 콜백을 트리거하지만 상태가 이미 업데이트된 경우 의도하지 않은 다른 효과를 방지할 수 있습니다.
이 패턴을 따르면 개발자는 계약을 더욱 안전하게 보호하고 재진입 공격에 대한 취약성을 줄일 수 있습니다.
또 다른 가능한 수정 방법은 OpenZeppelin의 ReentrancyGuard와 마찬가지로 수정자를 활용하여 동일한 함수에 대한 여러 호출을 제한하는 것입니다.
01
/ 정의 /
오라클은 스마트 계약이 블록체인 외부에서 정보를 검색하도록 돕습니다. 일반적으로 분산형 거래소(DEX) 자산의 가격은 DEX의 마지막 성공적인 거래에서 오라클 머신이 추출한 가격에 따라 결정됩니다.
그러나 문제는 가격이 누구나 쉽게 조작할 수 있어 스마트 컨트랙트에 문제가 발생한다는 점이다. 플래시론을 통해 가격 오라클을 조작하는 사례를 종종 볼 수 있는데, 플래시론을 사용하면 동일한 블록 내에서 대출금을 상환하기만 하면 담보 없이 막대한 금액을 빌릴 수 있기 때문입니다. 이를 통해 공격자는 허위 청산, 과도한 대출 또는 불공정 거래를 통해 이익을 얻기 위해 가격에 쉽게 영향을 미치거나 심지어 조작할 수도 있습니다.
02
／ 사례 분석 ／
다음은 오라클 조작에 취약한 코드 조각입니다.
이 계약을 통해 사용자는 라우팅 계약을 사용하여 토큰 A를 토큰 B로 교환할 수 있지만 가격을 계산하기 위해 토큰 A와 토큰 B의 준비금을 확보하기 위해 외부 오라클(Uniswap 쌍 계약)에 의존합니다. 공격자는 Uniswap 쌍 컨트랙트의 보유량과 getAmountOut 함수를 조작할 수 있었고, 결국 스왑이 불합리한 가격으로 실행되도록 만들었습니다.
03
／ 개선방법 ／
이러한 공격을 방지하려면 개발자는 중앙화 및 분산형 교환을 위해 온체인 볼륨 가중 평균 가격(VWAP) 또는 시간 가중 평균 가격(TWAP)을 캡처하는 분산형 오라클 네트워크를 사용해야 합니다. 이러한 방식으로 데이터는 다양한 소스에서 광범위한 시간에 걸쳐 수집되므로 코드가 공격 및 조작에 덜 취약해집니다. 잠재적인 취약점을 방지하려면 개발자가 스마트 계약에서 오라클을 조작하기 위한 공격 벡터를 제거할 수 있는 것이 중요합니다.
01
/ 정의 /
기능의 가시성을 적절하게 설정하면 스마트 계약의 보안과 무결성이 보장됩니다. 잘못된 기능 가시성 설정을 사용하면 의도하지 않은 사용자가 계약 상태를 조작할 수 있어 자금 도난이나 계약 기능 제어와 같은 심각한 문제가 발생할 수 있습니다.
기능의 가시성을 비공개 또는 내부로 설정하면 개발자가 특정 기능에 대한 액세스를 제한하고 승인된 당사자만 이러한 기능을 호출할 수 있도록 할 수 있습니다. 프라이빗 함수는 계약 자체에서만 호출할 수 있지만 내부 함수는 현재 계약을 상속하여 호출할 수도 있습니다. 이를 통해 개발자는 기능에 대한 액세스 제어를 유지하면서 더욱 강력하고 복잡한 계약을 만들 수 있습니다.
02
／ 사례 분석 ／
setAdmin() 함수를 사용하면 누구나 모든 주소를 계약 관리자로 설정할 수 있습니다. 주소 관리를 위해 계약 내에서 부여된 권한에 따라 개발자가 계약 자체에 대한 통제권을 잃거나 자금을 잃을 수도 있습니다.
일부 계약 기능은 내부적으로 해당 기능의 가시성을 내부로 설정하여 특정 사용자를 관리자로 설정하도록 허용할 수 있습니다.
03
／ 개선방법 ／
액세스 한정자는 계약의 특정 기능이나 변수에 액세스할 수 있는 사람을 지정하는 중요한 보안 기능입니다. 이러한 수정자를 사용하면 특정 기능이나 변수의 가시성을 특정 역할이나 주소로 제한하고 악의적인 행위자가 무단 액세스를 얻거나 계약 상태를 조작하는 것을 방지할 수 있습니다.
예를 들어 계약에는 계약 소유자만 호출할 수 있는 기능이 있거나 특정 주소 집합에서만 액세스할 수 있는 변수가 있을 수 있습니다.
가시성 수정자를 external로 변경하고 액세스 수정자를 onlyOwner로 설정하면 setAdmin 기능에 대한 액세스를 계약 소유자의 주소로 제한할 수 있습니다. 이렇게 하면 악의적인 외부 당사자가 특정 권한 있는 기능을 제어하는 것을 방지할 수 있습니다.
가시성 및 제한 수정자를 적절하게 사용하면 계약 관리가 더 쉬워지고 재진입 공격(공격자가 계약 상태를 조작하기 위해 함수를 반복적으로 호출하는 경우) 또는 실행 공격(공격자가 보류 중인 트랜잭션을 모니터링하고 조작하는 경우)과 같은 일반적인 공격을 줄일 수 있습니다. 합법적인 거래가 실행되기 전의 계약 상태).
이러한 기능을 적절하게 사용함으로써 개발자는 계약 보안과 안정성을 강화하고 무단 액세스 위험을 줄이며 코드의 전반적인 품질과 유지 관리성을 향상시킬 수 있습니다.
01
/ 정의 /
향후 계약 업그레이드 여부를 결정할 때는 처음부터 계약 설계를 신중하게 고려할 필요가 있다. 계약 업그레이드 가능성은 스마트 계약이 블록체인에 배포된 후 수정되거나 업데이트될 수 있는 속성을 나타냅니다. 업그레이드 가능성은 많은 이점(예: 버그 수정, 효율성 향상, 새 기능 추가 등)을 제공할 수 있지만 일부 위험도 따릅니다. 계약 업그레이드로 인해 새로운 취약점이 발생하거나 계약 복잡성이 증가하거나 의도하지 않은 결과가 발생할 수 있습니다.
계약 업그레이드 가능성은 프록시 관리자가 커뮤니티 합의 없이 계약을 업그레이드할 수 있기 때문에 신뢰 문제도 발생시킵니다. 개발자는 업그레이드 가능성의 장점과 단점을 신중하게 평가하고 프로젝트에 업그레이드 가능한 계약을 도입하는 것이 정말로 필요한지 여부를 결정해야 합니다. 어떤 경우에는 나중에 수정하는 능력에 의존하는 것보다 처음부터 불변성을 갖도록 계약을 설계하는 것이 더 안전합니다.
02
／ 개선방법 ／
계약 업그레이드 가능성과 관련하여 따라야 할 몇 가지 중요한 관행이 있습니다. 무엇보다도 프록시 라이브러리를 수정하지 마십시오. 프록시 계약 라이브러리는 특히 스토리지 관리 및 업그레이드 메커니즘 측면에서 매우 복잡합니다. 작은 실수라도 프록시 및 논리 계약의 작동에 큰 영향을 미칠 수 있습니다. 실제로 감사 중에 발견된 프록시 관련 심각도 오류 중 다수는 프록시 라이브러리에 대한 부적절한 수정으로 인해 발생했습니다.
계약 업그레이드 가능성의 또 다른 핵심 사례는 기본 계약에 스토리지 간격을 포함시키는 것입니다. 논리 계약은 새로운 논리 구현을 배포할 때 도입될 수 있는 새로운 변수를 설명하기 위해 계약 코드에 스토리지 공백을 포함해야 합니다. 새로운 상태 변수를 추가한 후에는 간격의 크기를 업데이트하는 것이 더 중요해집니다. 이렇게 하면 향후 업그레이드가 문제 없이 원활하게 실행될 수 있습니다.
마지막으로, selfdestruct()를 사용하거나 신뢰할 수 없는 계약에 대해 Delegatecall()/call()을 수행하는 것은 피해야 합니다. 공격자는 이러한 기능을 악용하여 논리 구현을 파괴하거나 사용자 지정 논리를 실행할 수 있습니다. 이를 방지하려면 사용자 입력을 검증하는 것이 중요합니다! 신뢰할 수 없는 계약에 대해 계약이 Delegatecall()/call()을 수행하는 것을 허용하지 마십시오. 또한 여러 계약에 걸쳐 저장소 레이아웃을 관리하는 것이 어렵기 때문에 논리 계약에서는 Delegatecall()을 사용하지 않는 것이 좋습니다. 이러한 관행을 따르면 개발자는 계약 업그레이드 시 버그와 위험을 최소화할 수 있습니다.
01
/ 정의 /
Front-Running은 항상 완고하고 해결하기 쉽지 않은 문제였습니다.사용자는 거래를 제출하고 블록체인에서 확인하는 사이의 지연을 활용하여 이익을 얻을 수 있습니다. 이 지연은 mempool로 인해 발생합니다.
멤풀은 네트워크에 브로드캐스트된 확인되지 않은 거래를 위한 임시 저장 영역입니다. 네트워크의 모든 노드는 누구나 보류 중인 트랜잭션을 볼 수 있고 잠재적으로 이를 가로채서 이익을 얻을 수 있는 멤풀을 유지 관리합니다. 멤풀은 또한 채굴자들이 거래를 재정렬하여 수익을 극대화할 수 있는 기회를 제공하여 채굴자(또는 최대) 추출 가능 가치(MEV)라고 알려진 것을 생성합니다.
02
／ 사례 분석 ／
다음은 선행 실행이 발생하기 쉬운 경매 입찰 기능의 예입니다.
이 기능을 통해 사용자는 경매에 입찰할 수 있지만 선행 공격에 취약할 수 있습니다. 악의적인 사용자가 블록체인을 모니터링하고 다른 사용자가 높은 입찰가를 제출한 것을 확인하면 악의적인 사용자가 신속하게 더 높은 입찰가를 제출하고 우선순위를 부여받아 결국 경매에서 승리할 수 있다고 가정해 보겠습니다.
다음 버전에서는 사용자가 알 수 없는 입찰 가격을 제출하고 이러한 입찰은 매핑에 저장됩니다. 입찰 금액은 입찰 기간이 끝날 때까지 암호화됩니다.
03
／ 개선방법 ／
입찰 기간이 끝나면 사용자는 원래 입찰 금액과 비밀 값을 제출하여 입찰을 공개할 수 있습니다. 계약은 입찰 금액과 비밀 해시가 저장된 비밀 입찰과 일치하는지 확인하여 경매 기간이 끝나기 전에 입찰이 제출되었는지 확인합니다. 해당 입찰가가 현재 최대 입찰가보다 높으면 새로운 최대 입찰가가 됩니다. 이 기능은 경매 기간이 끝날 때까지 입찰 금액을 마스킹하여 선행 공격을 완화합니다.
Front-running과 MEV는 블록체인 커뮤니티의 주요 관심사가 되었으며, 이러한 문제를 해결하기 위해 거래, 공정 주문 서비스(FSS) 등 다양한 솔루션이 제안되었습니다. 트랜잭션은 블록체인에서 트랜잭션이 실행될 때까지 다른 사용자에게 트랜잭션 세부 정보를 숨김으로써 선행 실행을 방지하는 데 도움이 될 수 있습니다. 반면, FSS는 안전한 오프체인 거래 주문을 통해 선행 거래와 MEV의 영향을 줄일 수 있습니다.
긴급 보안 사고를 처리하려면 명확하고 포괄적인 대응 계획을 마련하는 것이 중요합니다. 계획은 정기적으로 검토, 업데이트 및 효율성 테스트를 거쳐야 합니다. 긴급 보안 사고에는 시간이 가장 중요합니다. 따라서 계획은 사전에 맞춤화되어야 하며 식별, 통제 및 지속 방출과 같은 세부적인 운영 단계를 포함해야 합니다.
계획은 효과적으로 마련되어야 하며 모든 이해관계자에게 정보를 제공해야 합니다. 동시에 데이터 손실을 방지하기 위해서는 정기적인 데이터 백업도 중요합니다. 계획에는 데이터와 시스템을 이전 상태로 복원하기 위한 복구 프로세스가 간략하게 설명되어 있습니다. 팀원은 모두가 자신의 역할과 책임을 이해할 수 있도록 프로그램에 대한 체계적인 교육을 받아야 합니다.
잘 준비된 대응 계획은 문제를 해결하지 못할 수도 있지만 사고의 영향을 최소화하고 사용자 및 이해관계자와의 신뢰를 유지할 수 있습니다.
정기적인 코드 감사는 애플리케이션 보안을 유지하는 데 중요합니다. 스마트 계약 보안을 전문으로 하는 전문 감사자와 협력하는 것은 개발 과정에서 중요한 단계입니다. 감사자는 코드의 취약점을 확인하고 전반적인 보안 개선을 위한 권장 사항을 제공합니다.
확인된 문제의 우선순위를 정하고 해결하며 감사자와의 개방적인 커뮤니케이션을 유지하는 것은 보안을 개선하는 데 매우 중요합니다.
이 외에도 감사관과의 의사소통도 중요합니다. 감사자는 발견한 문제와 취약점을 자세히 설명하고, 취약점을 해결하는 방법에 대한 지침과 실질적인 도움을 제공할 수 있습니다. 전문감사기관/직원과의 협력을 통해 보안을 한 단계 더 높이겠습니다.
BNB 체인 개발자의 경우 정기적인 감사를 수행하는 것은 포괄적인 보안 전략의 필수적인 부분입니다. 코드의 취약점을 사전에 식별하고 해결하면 보안 침해 위험이 최소화됩니다.
포상금 프로그램을 사용하는 것은 화이트 해커 커뮤니티가 프로젝트 코드의 보안 취약점을 보고하도록 장려하는 효과적인 방법입니다. 토큰이나 기타 보상과 같은 인센티브를 제공함으로써 모든 프로젝트는 숙련된 사람들이 코드를 검토하고 발견한 잠재적인 문제를 보고하도록 장려할 수 있습니다.
명확하고 투명한 버그 포상금 프로그램을 갖는 것이 중요합니다. 계획에는 보상을 받을 수 있는 것으로 확인된 취약점 유형, 이러한 취약점의 가치를 평가하는 방법 등이 포함되어야 합니다. 동시에 신뢰할 수 있는 제3자를 버그 포상금 프로그램에 포함시키는 것은 프로그램의 원활한 실행과 보상의 공정한 분배를 보장하는 데 도움이 될 수 있습니다.
동시에 다양한 현상금 사냥꾼 그룹을 보유하는 것도 중요합니다. 화이트 햇 해커마다 전문 분야가 다르며 다른 사람들이 놓칠 수 있는 문제를 찾는 데 집중할 수 있습니다.
마지막으로, 취약점이 보고되면 이를 해결하기 위한 신속하고 효율적인 조치를 취해야 합니다. 현상금 프로그램은 취약점을 식별하는 데 효과적인 도구일 수 있지만 문제를 실제로 의미 있게 해결하는 것은 개발 팀의 몫입니다.
Web3 사용자를 위한 보안 교육은 보안 생태계 구축에 있어서 중요한 단계입니다. 고객을 안전하게 보호하면 플랫폼을 안전하게 유지하는 데 도움이 됩니다. 사용자는 자신의 계정과 민감한 정보를 보호하기 위한 모범 사례에 대해 교육을 받아야 합니다.
가장 중요한 부분 중 하나는 피싱 사기를 피하는 방법을 배우는 것입니다.
피싱 사기꾼은 합법적인 웹사이트나 서비스인 것처럼 가장하여 사용자를 속여 사용자가 개인 키나 비밀번호를 공개하도록 합니다. CertiK는 사용자에게 정보를 받을 때 모든 메일, 소스 등에 사용되는 웹사이트 URL을 항상 다시 확인하고, 신뢰할 수 없는 웹사이트에는 개인 키나 비밀번호를 입력하지 말 것을 권고합니다.
또 다른 중요한 부분은 안전하고 강력한 비밀번호를 갖는 것입니다. CertiK는 이에 따라 사용자에게 각 계정에 고유하고 복잡한 비밀번호를 사용하고 다른 서비스에서 비밀번호를 재사용하지 않도록 권고합니다. 또한 비밀번호 관리자나 기타 보안 저장 메커니즘을 사용하여 비밀번호를 안전하게 저장하세요.
마지막으로 개인 키를 보호하는 것이 매우 중요합니다. 개인키는 사용자의 비밀번호와 동일하며 타인이 언제든지 접근할 수 없도록 보장되어야 합니다. 사용자는 자신의 개인 키를 누구와도 공유하지 말고 안전한 곳에 보관해야 합니다.
요약하다
BNB 체인에서 스마트 계약 및 dApp을 구축하는 개발자는 사용자의 자금과 자산을 안전하게 보호하기 위해 포괄적인 보안 접근 방식을 취해야 합니다. 보안 침해를 처리할 때는 사후 대응보다는 사전 예방적으로 대처하고, 침해가 발생할 때, 심지어 발생하기 전에 계획을 세우고, 모든 관련 사용자 및 이해관계자에게 적절한 보안 교육을 제공하는 것이 훨씬 더 중요합니다. 위의 모든 조치를 결합함으로써 프로젝트가 보안 위반 및 해킹 공격의 위험을 크게 줄이는 데 도움이 될 수 있습니다.
