디파이 프런트엔드 침해, 접속만 한 경우와 서명한 경우의 차이

디파이 프런트엔드 침해는 웹 화면이나 브라우저로 전달된 스크립트가 변조된 사고이며, 원인은 DNS, 배포 계정, 콘텐츠 전송망(CDN), 의존 패키지, 분석 태그 등 여러 갈래입니다. 사이트를 열었다는 사실만으로 자산이 옮겨 가지는 않습니다. 지갑 연결, 서명 요청 승인, 거래 전송, 시드 입력 여부를 차례로 확인하고, 악성 빌드가 제공된 정확한 호스트 이름·페이지·시간·캐시 범위와 맞춰 사람마다 노출 여부를 판정해야 합니다.

프런트엔드는 파일 하나가 아니라 전달 경로입니다

사용자가 보는 디파이 화면은 저장소 소스, CI 빌드, 호스팅 저장 공간, CDN, DNS, 태그 관리자, 외부 패키지를 거쳐 완성됩니다. 화면이 변조됐다는 말만으로는 어느 계정이 침해됐는지 알 수 없습니다. 팀은 처음 오염된 지점, 악성 산출물 해시, 영향을 받은 호스트 이름과 경로, 제공 시작·종료 시각을 공개해야 합니다.

같은 도메인이라도 스왑 페이지만 악성 스크립트를 불러왔고 문서나 상태 페이지는 무관할 수 있습니다. 반대로 공통 레이아웃이나 분석 태그가 오염되면 여러 경로가 영향을 받을 수 있습니다. ‘웹사이트 전체’라는 표현 대신 어떤 응답과 스크립트가 사용자 브라우저에 도착했는지를 기준으로 범위를 적습니다.

프런트엔드 사고의 단위는 브랜드가 아니라, 브라우저에 전달된 코드와 그 코드가 요청한 행동입니다.

JOBCOIN 해설

그림으로 보기키 보관과 거래 서명

1. 01
   프런트엔드는 파일 하나가 아니라 전달 경로입니다

   사용자가 보는 디파이 화면은 저장소 소스, CI 빌드, 호스팅 저장 공간, CDN, DNS, 태그 관리자, 외부 패키지를 거쳐 완성됩니다.

2. 02
   접속만 한 경우와 서명한 경우를 구분합니다

   페이지에 접속한 것만으로 일반적인 온체인 전송이 승인되지는 않습니다.

3. 03
   Ledger 사건은 제3자 패키지 경로를 보여 줍니다

   Ledger의 Connect Kit 사고 보고서에 따르면 악성 패키지 1.1.5·1.1.6·1.1.7이 게시됐고, 이를 동적으로 불러온 탈중앙화 앱 화면에 자산 탈취(drain) 화면이 끼워 넣어졌습니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

접속만 한 경우와 서명한 경우를 구분합니다

페이지에 접속한 것만으로 일반적인 온체인 전송이 승인되지는 않습니다. 다만 악성 다운로드, 브라우저 취약점, 입력 정보 수집이 공지됐다면 따로 조사해야 합니다. 지갑 연결은 공개 주소와 네트워크 정보를 사이트에 보여 줄 수 있지만 자산을 옮길 권한 그 자체는 아닙니다.

서명은 내용에 따라 결과가 달라집니다. 로그인용 메시지, 토큰 승인, permit·Permit2, NFT setApprovalForAll, 스왑 거래, 네이티브 자산 전송을 구분합니다. 하드웨어 지갑에서 확인한 목적지와 금액도 기록합니다. 시드 문구나 개인키를 입력했다면 승인 하나의 문제가 아니라 주소 통제권 문제로 다룹니다.

Ledger 사건은 제3자 패키지 경로를 보여 줍니다

Ledger의 Connect Kit 사고 보고서에 따르면 악성 패키지 1.1.5·1.1.6·1.1.7이 게시됐고, 이를 동적으로 불러온 탈중앙화 앱 화면에 자산 탈취(drain) 화면이 끼워 넣어졌습니다. Ledger는 악성 파일에 접근할 수 있던 시간이 약 5시간이었지만 실제 탈취가 가능했던 시간은 2시간 미만으로 추정했고, CDN 캐시 때문에 제거 뒤에도 일부 남아 있었을 가능성을 밝혔습니다.

이때 영향을 가르는 질문은 ‘Ledger를 쓰는가’가 아니라 ‘영향 받은 버전을 동적으로 불러온 탈중앙화 앱을 그 시간에 열고 악성 요청에 서명했는가’입니다. 하드웨어 기기와 Ledger Live는 영향을 받지 않았다고 보고됐습니다. 제품 이름을 사고 범위로 쓰면 무관한 이용자까지 똑같은 대응을 하게 됩니다.

DNS 사고와 배포물 사고는 증거가 다릅니다

DNS 탈취라면 네임서버·레코드·TLS 인증서와 리졸버 캐시가 핵심입니다. 배포 계정이나 호스팅 저장 공간이 침해됐다면 산출물 해시, 배포 감사 로그, 접근 토큰이 중요합니다. 의존 패키지 오염은 잠금 파일·패키지 버전·실행 시 로더를 보고, 태그 관리자 사고는 컨테이너 버전과 게시 로그를 확인합니다.

Balancer의 DNS 피해 보상 논의는 공식 도메인의 프런트엔드를 통해 생긴 피해 거래를 검증했습니다. 이후 운영 기록에서는 도메인 업체를 옮겼다고 밝혔습니다. 이 사례를 모든 프런트엔드 사고의 원인으로 일반화하지 않고, DNS 계층의 증거로만 씁니다. 원인이 다르다면 그에 맞는 로그가 필요합니다.

• 영향 받은 호스트 이름과 경로를 기록합니다
• 악성 산출물과 스크립트의 해시를 확보합니다
• 배포·CDN·태그 관리자 로그를 시간순으로 맞춥니다
• 사용자별 서명과 거래를 분류합니다
• 캐시 종료 시각과 안전한 빌드의 검증값을 공개합니다

악성 요청의 결과를 거래 단위로 해석합니다

지갑 활동 기록에서 사고 시간대의 해시를 찾고, 탐색기에서 체인, 받는 주소, 호출 함수, 토큰, 금액을 확인합니다. 승인이라면 사용처와 허용량, permit이라면 서명한 도메인·논스·마감 시각, 스왑이라면 실제 수령인과 최소 수령량을 봅니다. 승인만 하고 아직 쓰이지 않은 권한과 이미 빠져나간 자산은 대응이 다릅니다.

팀이 피해 주소 목록을 공개하더라도 내 주소가 없다는 이유만으로 안전하다고 단정하지 않습니다. 탐지 규칙, 지원 체인, 수집 종료 블록에 따라 빠질 수 있습니다. 반대로 어떤 주소가 사이트를 방문했다는 분석만으로 악성 서명을 단정하지도 않습니다. 최종 판정은 지갑 기록과 체인 거래를 함께 놓고 내립니다.

안전한 배포는 재현할 수 있는 증거로 확인합니다

복구 뒤에는 깨끗한 커밋, CI 실행, 산출물 해시, CDN 캐시 삭제 완료, 서비스 워커 버전을 이어서 공개합니다. 사용자는 열린 탭을 닫고 믿을 수 있는 채널에서 복구 공지를 확인한 뒤 새 세션으로 접속합니다. 단순 새로고침으로는 메모리 캐시나 서비스 워커가 옛 스크립트를 계속 내줄 수 있어 충분하지 않을 수 있습니다.

콘텐츠 보안 정책(CSP)과 하위 리소스 무결성(Subresource Integrity)은 허용되지 않은 스크립트나 변조된 고정 리소스를 막는 데 도움이 되지만, 모든 동적 코드와 정상 권한 계정의 악성 배포까지 막지는 못합니다. 배포 다중 승인, 수명이 짧은 자격 증명, 의존 패키지 버전 고정, 독립 모니터링을 함께 운영합니다. 보호 장치의 이름보다 사건 뒤 실제로 막아 낸 증거를 봅니다.

피해 접수에는 최소 증거와 개인정보의 경계가 필요합니다

접수 양식에는 주소, 체인, 거래 해시, 방문한 호스트 이름과 시간, 서명 당시 화면을 받되 시드나 개인키를 요구해서는 안 됩니다. 브라우저 방문 기록이나 HAR 파일에는 토큰과 개인정보가 들어 있을 수 있으므로 필요한 항목만 남기고 가린 뒤 제출합니다. 공식 접수 번호와 접수 기한을 확인합니다.

보상 발표에는 적격 거래 판정 기준, 환산 시각, 수수료, 중복 지급 방지책, 이의 제기 창구가 담겨야 합니다. 보상 약속과 기술 복구를 한 문장으로 끝내지 않습니다. 이용자는 증거를 보존하면서 남은 권한부터 보호하고, 기술팀은 원인 계층과 사용자 영향 계층을 별도 표로 갱신합니다.

자주 묻는 질문