스마트 계약 보안: 민첩한 SDLC 접근 방식 PlatoBlockchain 데이터 인텔리전스. 수직 검색. 일체 포함.

스마트 계약 보안: 민첩한 SDLC 접근 방식 

읽기 시간: 10

블록체인은 분산형 및 변조 방지 원장으로 인용됩니다. 하지만 이 변조 방지 원장은 해킹과 악용에 취약합니다. 블록체인의 가장 큰 장점 중 하나인 탈중앙화는 단점 중 하나이기도 합니다. 

음, 괜찮습니다. 그런데 SDLC는 어떻습니까? 

우리가 논의하려는 소프트웨어 라이프사이클 접근 방식은 스마트 계약의 보안 취약성을 여러 단계로 분류하는 것을 기반으로 합니다. 

첫 번째 섹션에서는 스마트 계약의 보안 문제를 설명했습니다. 다음 섹션에서는 솔루션을 XNUMX단계로 나누어 논의합니다. 보안 설계, 보안 구현, 배포 전 테스트, 마지막은 모니터링 및 분석입니다. 

스마트 계약의 보안 문제 분석 

스마트 계약은 다양한 해킹과 악용에 취약합니다. 실제 법적 계약과 동의어인 이러한 계약은 기본 블록체인의 조건에 따라 독립적으로 실행됩니다. 

하지만 이러한 기본 블록체인도 스마트 계약의 잠재적인 보안 위협에 책임이 있을 수 있다고 생각하셨나요? 아래에서는 이에 대한 블록체인의 몇 가지 특성을 제시합니다.

분산: 블록체인 기반 프로토콜의 장점 중 하나로 꼽힙니다. 그러나 공격자들은 이러한 긍정적인 특징을 부정적인 특징으로 바꾸는 방법을 고안했습니다. 

악의적인 행위자는 가짜 신원을 만들어 스마트 계약을 개발하고 배포할 수 있습니다. 때로는 공개 주소(또는) 공개 키만 공개 블록체인에서 사용할 수 있기 때문에 취약한 계약을 식별하기가 어려워집니다. 

오픈 소스 코드: 놀라실 수도 있지만 일반적으로 대부분의 스마트 계약 코드는 어느 정도 오픈 소스입니다. 

EVM(Ethereum Virtual Machine)의 경우 바이트코드는 항상 공개됩니다. 그리고 일부 Solidity 디컴파일러는 스마트 계약 주소와 Solidity 코드를 얻는 데 도움이 될 수 있습니다. 소스 코드가 노출되면 공격자에게 이 기능이 유리해집니다. 

진화되지 않은 블록체인 플랫폼: 개발자에게는 개발 플랫폼에 익숙해지는 것이 기본 요구 사항입니다. 아직 개발되지 않았거나 새로운 블록체인 플랫폼이 많기 때문에 개발자는 블록체인 운영에 대한 심층적인 지식을 개발할 수 없습니다. 

이러한 불일치는 동기화 부족으로 인해 스마트 계약에 영향을 미칩니다. 블록체인 플랫폼의 결함은 지속적인 발전으로 인해 눈에 띄지 않는 채로 남아 있습니다. 

알 수 없는 거래: 첫 번째 요점에서는 익명의 신원에 대해 논의했습니다. 마찬가지로 블록체인의 거래도 공개되지 않습니다. 거래 추적이 불가능해 불법 행위가 많이 발생하고 있다. 금융거래가 수반되기 때문에 보안 문제가 발생할 경우 막대한 금전적 손실이 발생할 수 있습니다. 

스마트 계약 보안 솔루션

이제 스마트 계약 보안을 진행하면서 스마트 계약을 보호하는 데 필요한 모든 단계를 진화와 비교할 수 있습니다. 전통적인 소프트웨어 개발과 마찬가지로 우리는 개발 수명주기를 따르는 경향이 있습니다. 마찬가지로 계약 개발 수명주기를 분류할 수 있습니다. 

스마트 계약 개발 수명주기는 보안 설계, 보안 구현, 배포 전 테스트, 모니터링 및 분석의 네 단계로 나눌 수 있습니다.

스마트 계약 수명주기 관점에서 보안 테마 개요
스마트 계약 수명주기 관점에서 본 보안 테마 개요

1. 보안 설계 

이 첫 번째 단계는 세 가지 주제를 요약합니다. 디자인 원칙, 디자인 패턴, 보안 모델링(위 그림 참조). 이러한 주제의 주요 초점은 계약 설계와 보안 위협을 피할 수 있는 방법에 있습니다. 

디자인 원칙

설계 원칙은 블록체인에서 안전한 스마트 계약을 설계하기 위한 기본 아이디어입니다. 계약에는 XNUMX가지 필수 설계 원칙이 있습니다. 실패에 대비하기, 신중하게 롤아웃하기, 계약을 단순하게 유지하기, 최신 상태 유지하기, 블록체인 속성에 대해 꼭 알아두기입니다. 

이제 안전한 스마트 계약을 생성하는 데 어떻게 도움이 될지 생각할 수 있습니다. 

위의 원칙 중 하나를 선택해 보겠습니다. 예를 들어 "실패에 대비하세요"는 패치 체계가 없어도 계약이 버그에 대응할 수 있어야 함을 의미합니다. 그리고 공격이 발생하면 추가 손실을 방지하기 위해 계약을 일시 중지할 수 있어야 합니다. 

디자인 패턴

소프트웨어 디자인에서 디자인 패턴은 문제를 해결하기 위해 재사용할 수 있는 솔루션입니다. 

Ethereum의 예를 들면 XNUMX가지 보안 패턴이 있습니다. 확인-효과-상호작용, 비상정지, 뮤텍스, 과속방지턱, 속도 제한, 밸런스 제한.  

이러한 보안 패턴을 사용하여 재진입 취약성을 Mutex 패턴으로 처리할 수 있는 것처럼 블록체인의 보안 문제를 해결할 수 있습니다. 

동시에 비상 중지 패턴은 취약성의 영향을 받는 경우 계약 실행을 종료하는 데 도움이 될 수 있습니다. 

보안 모델링

Solidity를 사용하여 계약을 생성하므로 개발된 코드와 계약에 필요한 코드 간에 차이가 있을 수 있습니다. 이 언어는 튜링 완전성을 만족하지만 오류가 발생하기 쉽습니다. 

위 그림은 이 하위 단계가 두 단계를 포함한다는 것을 보여줍니다. 보안 설계 및 구현. 

보안 모델링은 비즈니스 로직과 직접적인 관련이 있습니다. 사양은 비즈니스에서 파생되므로 논리는 오류 없는 의미론으로 분류될 수 있습니다. 이는 나중에 취약점을 완화하기 위해 수행되는 공식 검증 프로세스 중에 도움이 됩니다. 

2. 보안 구현

이 섹션에서는 세 가지 주제 중 두 가지를 다룰 것입니다. 보안

개발 및 보안 템플릿은 이미 마지막 단계에서 보안 모델링을 다루었습니다.

보안 개발

이 섹션에서는 계약 구현 프로세스 중에 취약점을 피할 수 있는 방법을 살펴보겠습니다. 

Ethereum 플랫폼에는 보안 EIP(Ethereum Improvement Proposal)가 있습니다. 이는 Ethereum 플랫폼의 보안 문제를 해결하기 위한 권장 사항입니다. 이더리움 플랫폼. 따라서 이러한 EIP는 스마트 계약을 안전하게 구현하는 데 주목할 만합니다. 

보안 템플릿

템플릿은 새 문서의 원본 역할을 합니다. 운영 매개변수가 포함된 스마트 계약 템플릿은 법적 계약을 실행 가능한 코드에 연결합니다. 

스마트 계약 보안과 관련하여 보안 패턴, 보안 라이브러리 등 업그레이드된 보안 매개변수를 사용하여 표준 계약 템플릿을 추출할 수 있습니다. 이렇게 하면 수동 코딩 시 오류가 발생할 가능성이 줄어듭니다. 

3. 배포 전 테스트

다시 말하지만, 이 단계의 요구 사항은 스마트 계약의 장점 중 하나인 "불변성"에서 발생합니다. 

스마트 계약이 생성되면 변경할 수 있는 방법이 없습니다. 따라서 배포 전에 스마트 계약의 보안을 보장하기 위해 충분한 테스트를 수행하는 것이 필수입니다.

이 단계에서는 스마트 계약을 배포하기 전에 따라야 할 세 가지 보안 매개변수를 다룹니다. 엄격한 공식 검증, 코드 분석 도구 및 보안 감사. 

엄격한 공식 검증

형식 검증은 수학적 추론과 수학적 증명을 활용하여 시스템의 원하는 속성을 검증하는 잘 정의된 프로세스입니다. 

계약 프로그램이 짧고 시간 제한이 있기 때문에 스마트 계약에 대한 공식적인 검증을 수행할 수 있습니다. 스마트 계약을 엄격하게 공식화하고 검증하는 방법에는 여러 가지가 있습니다. 일부는 계약 코드를 기반으로 하고 다른 일부는 Ethereum 가상 머신(EVM)의 의미를 기반으로 합니다. 

코드 분석 도구

코드 분석은 프로그램을 실행하지 않고 수행됩니다. 이를 위해 우리는 SAST(Static Application Security Testing) 도구라는 몇 가지 도구를 사용합니다. 이러한 도구는 소스 코드의 보안 결함을 발견하는 데 도움이 됩니다. 

이러한 도구로 수행되는 분석에는 다음 단계 중 하나 또는 전체가 포함될 수 있습니다.

은 (i) 자세한 분석을 위해 AST(추상 구문 트리)와 같은 중간 표현(IR)을 만듭니다. 

(II) 정적 제어 또는 날짜 흐름 분석 및 공식 검증 기술을 통해 얻은 충분한 정보로 IR을 보완합니다. 이러한 기술에는 기호 실행, 추상 해석 및 기호 모델 검사가 포함됩니다. 

그렇다면 스마트 계약에 대한 코드 분석을 수행하는 데 사용할 수 있는 도구는 무엇입니까? 

보안 분석을 수행하는 데 사용할 수 있는 도구는 많지만 Oyente가 가장 많이 사용됩니다. 

오옌테 EVM 스마트 계약에 대한 보안 분석을 수행하는 데 사용할 수 있습니다. 이는 "기호 실행"을 사용하여 네 가지 일반적인 버그를 발견합니다. 트랜잭션 순서 의존성, 타임스탬프 의존성, 잘못 처리된 예외 및 재진입. 

오옌테의 건축
오옌테의 건축

Oyente의 아키텍처는 바이트코드를 취하고 Ethereum 전역 상태를 입력으로 제공한다는 것을 보여줍니다. 

Oyente의 단점 중 하나는 보안 취약점만 감지한다는 것입니다. Oyente가 사용하는 기호 실행 기술은 가능한 모든 경로를 탐색하지 않습니다. 따라서 보안 및 수동 감사와 같은 다른 도구의 필요성이 대두됩니다. 

보안 감사

마지막 섹션을 떠난 부분부터 이 섹션을 시작하겠습니다. 수동 감사. 

하지만 먼저 보안 감사의 필요성을 이해해 보겠습니다. Ronin Network 해킹이든 Poly Network 해킹이든 감사되지 않은 코드는 해킹과 악용에 가장 취약합니다. 

그들은 막대한 금전적 손실을 초래합니다. 실제로 Web3 프로젝트를 감사받는 것뿐만 아니라 전문 전문가에게 감사를 받는 것도 보안 감사를 수행하는 감사자의 전문적인 능력에 달려 있기 때문에 중요합니다. 

다시 말하지만, 전문적인 전문가를 어디서 찾을 수 있나요? 신뢰할 수 있는 감사자를 찾으러 어디든 갈 필요가 없습니다. 딸깍 하는 소리 https://t.me/quillhash 그 중 한 명에게 연락해 보세요! 

이상적인 스마트 계약 감사는 수동 및 자동 코드 분석의 조합입니다. 이전 시점에서 논의한 것처럼 Oyente와 같은 도구를 사용하여 자동화된 코드 분석을 수행하더라도 계약에 확인되지 않은 취약점이 있을 가능성이 있습니다. 

따라서 이를 극복하기 위해 보안 감사자는 모든 코드 줄을 수동으로 분석하고 잠재적인 취약점에 대해 테스트할 수 있습니다. 

4. 모니터링 및 분석

처음에 논의했던 블록체인의 끊임없이 진화하는 원리를 기억하시나요? 

이 단계는 동일한 주제를 기반으로 합니다. 계약이 배포되고 실행되면 새로운 릴리스와 빈번한 업데이트로 인해 이전 단계에서 발견되지 않은 일부 취약점이 발생할 수 있으며 이로 인해 나중에 계약의 효율성이 떨어질 수 있습니다. 

우리는 수행할 수 있습니다. 버그 포상금, 보안 모니터링, 사후 분석을 통해 이러한 장벽을 극복할 수 있습니다. 

버그 바운티

계약과 관련된 배포 후 보안 문제를 고려하고 있으므로 Bug Bounties가 도움이 될 수 있습니다. 앞서 논의한 정형검증 기법은 정적분석 기법이다. 반면에 버그 바운티는 동적 분석 기술입니다. 

버그 바운티의 개념은 간단합니다. 해커는 버그를 발견하고 그 대가로 금전적인 보상을 받습니다. 윈윈(win-win) 상황인 것 같죠? 하지만 그렇지 않습니다!

여기서 중요한 점은 다음과 같습니다. 버그의 가치가 그레이 마켓의 현상금보다 높을 수 있으며 해커가 버그를 악용하거나 판매하여 높은 가격을 받을 가능성도 있습니다. 

때때로 프로젝트 소유자는 버그가 확인되지 않는 한 포상금 지불을 거부합니다. 해커들은 또한 버그가 공개된 후 지불의 불확실성에 대해 걱정합니다. 

이를 극복하기 위해 "Hydra"라고 알려진 버그 포상금 프레임워크가 제안되었습니다. 

Hydra는 NNVP(N-of-N-version 프로그래밍)라는 익스플로잇 갭 기술을 블록체인의 버그 포상금 시스템으로 활용합니다. 

헤드가 있는 Hydra 프레임워크
헤드가 있는 Hydra 프레임워크

보안 모니터링

보안 취약점을 발견하기 위해 정적 코드 분석을 사용할 수 있지만 이 방법은 스마트 계약을 배포하기 전에 사용됩니다. 

하지만 버그와 잠재적인 취약점을 실시간으로 찾아내려면 블록체인의 거래 데이터를 모니터링하고 분석해야 합니다. 

스마트 계약을 분석하여 발견된 이러한 취약점을 추적 취약점이라고 할 수 있습니다. 세 가지 유형의 계약이 이러한 추적 취약점의 핵심입니다. 

은 (i) 탐욕스러운 계약(살아남고 Ether를 무기한 잠그는 계약).

(II) 방탕 계약(임의의 사용자에게 부주의하게 자금을 유출하는 계약) 및,

(iii) 자살 계약(임의의 사용자가 죽일 수 있는 계약). 

ECF 개체를 모니터링하여 취약점을 식별하기 위해 ECF(Effectively Callback Free) 개체라는 개념도 제안되었습니다. 

이와 관련하여 온라인 알고리즘도 제시되었습니다. 알려지지 않은 취약점을 발견하는 데 도움이 되었습니다. 같은 제안에서는 메인넷에 배포하기 전에 테스트넷에서 스마트 계약을 실행하는 것이 제안되었습니다. 

모니터링 UI는 React.js를 활용한 블록체인 모니터링 플랫폼입니다. 이 플랫폼을 사용하여 거래를 수행하고, 자산을 확인하고, 블록체인 상태를 조회할 수 있습니다. 

스마트 계약의 안전한 모니터링을 위해 이 플랫폼에 의존할 수는 없지만 스마트 계약과 관련된 대부분의 거래 데이터를 찾을 수 있으므로 자산 전송을 추적하여 실시간으로 공격을 탐지할 수 있습니다. 

사후 분석

사후 분석은 블록체인 거래 데이터를 사용하여 일반인의 관점에서 블록체인에 대한 잠재적인 위협을 분석, 발견 또는 추적합니다. 

그래프 분석에 대해 논의하면 모든 거래 데이터(여기에는 스마트 계약의 내부 거래 포함)를 수집하는 접근 방식으로 설계되었습니다. 

이 데이터의 도움으로 그들은 세 가지 그래프를 준비했습니다. 

은 (i) 자금 흐름 그래프(MFG)

(II) 계약생성그래프(CCG)와,

(iii) 계약 호출 그래프(CIG)

위에서 언급한 그래프 분석을 바탕으로 서로 상호 작용하는 여러 계약 간의 보안 문제에 대한 솔루션 등 많은 새로운 결과가 제안되었습니다. 

그래프 분석 개요
그래프 분석 개요

폰지 사기는 많은 자금을 획득하고 기본 블록체인에 영향을 미칠 수 있는 고전적인 사기 사기 중 하나입니다. 이러한 사기에 맞서기 위해 이더리움에서 Ponzi 사기를 탐지하는 분류 메커니즘이 제안되었습니다. 

이 메커니즘은 데이터 마이닝과 기계 학습을 활용하여 Ponzi 계약을 탐지합니다. 이 프로세스는 스마트 계약의 소스 코드를 사용할 수 없는 경우에도 작동합니다. 

스마트 폰지 사기 탐지 프레임워크
스마트 폰지 사기 탐지 프레임워크

주요 테이크 아웃

그게 다야, 그래, 지금은 그게 다야!

지금까지 함께 해주신다면 감사하겠습니다. 더 이상 확장하지 않고 결론적으로 스마트 계약의 생태계는 분산되어 있으며 버그를 패치하기가 어렵다고만 말씀드리고 싶습니다. 

우리는 소프트웨어 수명주기 관점에서 스마트 계약의 보안을 분석하려고 노력했습니다. 

우리는 먼저 블록체인의 주요 기능에 대해 논의했습니다. 스마트 계약의 보안 문제. 우리는 스마트 계약을 위한 보안 솔루션을 3단계로 분류했습니다. 우리는 성장하는 WebXNUMX 생태계의 과제에 앞서 나갈 수 있도록 더 많은 게시물을 제공할 수 있기를 바랍니다. 

스마트 계약 보안을 위한 민첩한 SDLC 접근 방식에 대해 어떻게 생각하시나요? 아래 댓글에서 여러분의 생각을 공유해 주세요!

46 조회수

포스트 스마트 계약 보안: 민첩한 SDLC 접근 방식  첫 번째 등장 블로그.quillhash.

타임 스탬프 :

더보기 퀼해시