tx.origin과 msg.sender의 차이점은 무엇이며 tx.origin을 피해야 하는 이유는 무엇입니까?

Ethereum 스마트 계약의 tx.origin 및 msg.sender 이해

1. tx.origin은 도중에 얼마나 많은 계약 호출이 발생했는지에 관계없이 거래를 시작한 원래 외부 계정을 나타냅니다. 이는 사용자가 계약 A와 상호작용하는 트랜잭션을 전송하고 계약 B를 호출하는 경우 계약 B의 tx.origin 값이 여전히 사용자의 지갑 주소를 가리킨다는 것을 의미합니다.

2. 반면 msg.sender는 외부 소유 계정(EOA)이든 다른 계약이든 현재 함수의 직접 호출자를 나타냅니다. 동일한 예에서 계약 A가 계약 B를 호출하면 계약 B 내의 msg.sender는 원래 사용자가 아닌 계약 A의 주소가 됩니다.

3. 액세스 제어 또는 철회 메커니즘과 같은 권한에 민감한 기능에서는 구별이 중요해집니다. 인증을 위해 로직이 tx.origin에 의존하는 경우 사용자가 간접적으로라도 호출한 악의적인 계약이 사용자의 권한을 가장할 수 있기 때문에 tx.origin에 의존하면 취약점이 발생할 수 있습니다.

4. 예를 들어, tx.origin이 소유자의 주소와 일치하는 경우에만 출금을 허용하는 스마트 계약을 생각해 보세요. 공격자는 소유자가 자신도 모르게 상호 작용하는 악의적인 계약을 만들 수 있습니다. 일단 트리거된 해당 계약은 피해자 계약의 철회 기능을 호출합니다. tx.origin은 소유자의 주소로 남아 있으므로 확인이 통과되어 적절한 소유권 확인에도 불구하고 도난이 가능합니다.

5. 이 동작은 보안 코딩의 최소 권한 원칙을 훼손합니다. 스마트 계약은 체인을 시작한 사람이 아니라 직접 호출한 사람을 기준으로 검증되어야 합니다. msg.sender를 사용하면 구성성이 향상되고 계약이 일상적으로 서로 상호 작용하는 분산 응용 프로그램의 예상 패턴과 일치합니다.

tx.origin 사용과 관련된 위험

1. tx.origin을 인증에 사용하면 피싱 공격이 쉬워집니다. 사용자는 더 깊은 콜 체인을 트리거하는 무해해 보이는 거래를 승인할 수 있으며, 이로 인해 공격자는 tx.origin을 잘못 신뢰하는 계약에서 자금을 빼낼 수 있습니다.

2. tx.origin의 존재는 잘못된 보안 감각을 만들어냅니다. 개발자는 최종 사용자의 유효성을 검사한다고 가정할 수 있지만 실제로는 중간 계약을 통해 시스템을 대리 공격에 노출시키고 있습니다.

3. tx.origin을 제한하거나 삭제하는 메커니즘이 내장되어 있지 않습니다. 직접적으로 스푸핑될 수는 없지만, 이더리움의 실행 환경에 내재된 위임 모델을 우회하기 때문에 그 특성상 접근 제어에 부적합합니다.

4. 업그레이드 가능한 계약과 복잡한 DeFi 프로토콜은 계층화된 상호 작용에 의존하는 경우가 많습니다. tx.origin이 핵심 로직에 내장되면 이러한 시스템은 합법적인 상호 계약 작업 중에 중단되어 예기치 않은 되돌리기 또는 권한 오류가 발생할 위험이 있습니다.

5. Consensys Best Practices와 같은 커뮤니티 표준 및 감사 프레임워크에서는 인증 목적으로 tx.origin을 사용하지 말 것을 명시적으로 권장합니다. 주요 프로토콜 감사에서는 이의 사용을 위험도가 높은 것으로 표시하여 초기 토큰 계약의 실제 악용에 기여했습니다.

안전한 계약 설계를 위한 모범 사례

1. 원래 트랜잭션 개시자를 참조해야 하는 매우 구체적이고 정당한 이유가 없는 한 계약 내에서 권한을 확인할 때 항상 msg.sender를 사용하십시오. 그런 경우에도 극도의 주의가 필요합니다.

2. msg.sender를 중심으로 설계되고 tx.origin에 의존하지 않고 세분화된 권한 관리를 지원하는 OpenZeppelin의 Ownable 또는 AccessControl과 같은 확립된 라이브러리를 사용하여 역할 기반 액세스 제어를 구현합니다.

3. 처음부터 사용자 지정 인증 논리를 작성하지 마세요. 분산 환경에서 신원 확인과 관련된 일반적인 함정을 방지하는 잘 테스트되고 커뮤니티가 검증한 패턴을 활용합니다.

4. 인증 흐름에 중점을 두고 철저한 보안 검토를 수행합니다. 정적 분석 도구와 공식 검증 방법은 tx.origin의 부적절한 사용을 감지하고 보다 안전한 대안을 제안할 수 있습니다.

5. EVM 실행 모델에 대해 개발팀을 교육합니다. 호출 스택이 전파되는 방식과 계약 호출 중 발신자 컨텍스트가 어떻게 이동하는지 이해하면 tx.origin 의미 체계에 대한 오해로 인한 설계 결함을 방지하는 데 도움이 됩니다.

자주 묻는 질문

tx.origin을 안전하게 사용할 수 있나요? 예. 하지만 분석이나 중요하지 않은 상태 추적을 위해 원래 개시자를 기록하는 등 매우 제한된 시나리오에서만 가능합니다. 그럼에도 불구하고 개발자는 액세스 결정이나 자금 이체에 영향을 미치지 않도록 해야 합니다.

msg.sender를 사용하면 모든 명의 도용 위험을 방지할 수 있나요? 단일 변수가 모든 위험을 제거하지는 않지만 msg.sender는 Ethereum의 의도된 보안 모델과 일치합니다. 가장으로부터 보호하려면 입력 유효성 검사, 재진입 보호, 보안 설계 패턴과 같은 추가 조치도 필요합니다.

계약이 tx.origin을 사용하고 다른 계약에 의해 호출되면 어떻게 되나요? tx.origin은 원래 사용자의 주소로 유지되므로 의도하지 않은 승인 결과가 발생할 수 있습니다. EOA와의 직접적인 상호 작용을 기대하는 계약은 원래 서명자가 유효하다는 이유만으로 악의적인 중개 계약에 대한 액세스를 실수로 허용할 수 있습니다.

tx.origin의 오용을 감지하는 도구가 있습니까? 예, Slither, MythX 및 Solhint와 같은 보안 스캐너는 인증 컨텍스트에서 tx.origin 사용을 표시합니다. 이러한 도구는 CI/CD 파이프라인에 통합되어 배포 전에 위험한 패턴을 식별하는 데 도움이 됩니다.