지갑 옆문이 열렸다

이 글은 공개된 자료를 바탕으로 정리한 개인 기록이다. 특정 자산의 매수·매도 권고가 아니다.

자료 기준: 2026년 8월 17일 오전 8시 42분, 한국 시간

오늘은 지갑보다 지갑 옆문을 오래 봤다. SafePal에서 약 3만9,798명의 주문정보가 무단 조회된 사고가 공개됐기 때문이다. 알려진 원인은 암호화 알고리즘이 깨진 것도, 하드웨어 지갑의 금고가 열린 것도 아니었다. 주문을 조회하는 웹 기능에서 “이 사람이 이 주문의 주인이 맞는가”를 제대로 확인하지 못한 권한검사 문제였다.

쉽게 말하면 현관문 비밀번호는 튼튼했는데 택배 보관함 열쇠가 여러 집에 맞았던 셈이다. 금고가 멀쩡하다는 말은 중요하지만, 배송주소와 전화번호가 새는 순간 안심 문구의 글씨 크기는 조금 줄여야 한다.

1. 노출된 것과 노출되지 않은 것을 나눴다

사고 설명에 따르면 이름, 이메일, 배송주소, 전화번호와 구매정보가 영향을 받았다. 반면 시드 문구, 개인키, 지갑 비밀번호, 카드·은행정보와 신분증 정보는 포함되지 않았고 지갑 자금이 직접 침해됐다는 증거도 확인되지 않았다.

이 구분은 꼭 필요하다. “암호화폐 지갑 사고”라고만 쓰면 독자는 코인이 빠져나갔다고 이해하기 쉽다. 실제 후속 위험은 다른 쪽에 있다. 공격자는 누구에게 하드웨어 지갑이 있고 어떤 제품을 샀는지 알 수 있다. 그러면 가짜 펌웨어 배송, 고객센터 사칭과 표적형 피싱이 훨씬 그럴듯해진다.

사고 기간과 피해 규모, 90일 보관정책 전환 및 피싱 링크 차단 조치는 SafePal의 공개 설명을 인용한 보안 보도를 기준으로 적었다. 공식 공지 목록은 검증 시점에 해당 세부 공지를 검색 결과로 노출하지 않아, 숫자를 더 넓혀 해석하지 않았다.

출처: SafePal 사고 보도, SafePal 보안 안내

2. 로그인 확인과 주문 소유권 확인은 다르다

이 사고 설명은 전형적인 BOLA 또는 IDOR 계열 문제와 닮았다. 사용자가 로그인했는지만 확인하고, 요청한 주문이 그 사용자 소유인지 확인하지 않으면 생긴다.

GET /orders/1234

주소의 숫자를 1235로 바꿨을 때 다른 사람 주문이 보인다면 UUID로 바꾸는 것만으로는 해결되지 않는다. 번호를 어렵게 숨기는 것은 문패를 작게 쓰는 일이다. 열쇠를 확인하는 일은 아니다.

서버는 매 요청에서 아래 관계를 확인해야 한다.

로그인 사용자 → 허용된 역할 → 요청 객체의 소유자 → 허용된 동작

관리자도 모든 주문을 무조건 볼 필요는 없다. 고객지원 담당자는 맡은 티켓 범위만, 배송 파트너는 배송에 필요한 최소 정보만 보게 해야 한다. 권한은 넓게 주기 쉽고 좁게 회수하기 어렵다. 양념은 더 넣을 수 있지만 이미 짠 국은 회의가 길어진다.

출처: OWASP Broken Object Level Authorization

3. 권한 회귀테스트를 기능 테스트 옆에 뒀다

나는 주문 API를 만든다면 정상 동작만 시험하지 않겠다. 서로 다른 두 계정을 준비하고 아래 경우를 자동화한다.

1. A 사용자가 A 주문을 읽는다 — 허용.
2. A 사용자가 B 주문번호를 넣는다 — 거부.
3. 로그인하지 않은 사용자가 주문을 읽는다 — 거부.
4. 배송 담당자가 결제·연락처 전체를 읽는다 — 거부.
5. 권한이 회수된 토큰으로 다시 요청한다 — 거부.

테스트 결과에는 응답 코드뿐 아니라 반환 필드도 확인해야 한다. 화면에서 전화번호를 가렸더라도 API 응답에 원본이 남아 있으면 브라우저 개발자 도구는 친절하게 진실을 보여준다. 가끔 너무 친절하다.

로그에는 누가 어떤 주문에 접근했는지 남기되, 개인정보 원문을 다시 복사해 넣지 않는다. 이상 조회량, 연속된 주문번호 탐색과 다른 국가에서의 급격한 접근도 경보 대상으로 둔다.

4. 덜 모으면 사고 뒤에 덜 쫓아간다

SafePal은 관련 개인정보 보관기간을 90일로 줄였다고 밝혔다. 보관기간 단축은 화려하지 않지만 효과가 분명하다. 서버에 없는 오래된 주소는 공격자도 가져갈 수 없다.

나는 보안제품의 위협 모델에 제품 코드만 넣지 않겠다.

• 쇼핑몰과 주문조회 플러그인
• 고객지원·CRM 연결
• 배송업체로 보내는 필드
• 백업과 분석 로그
• 데이터 삭제 작업의 실제 실행 여부

“우리는 키를 보관하지 않는다”는 설명과 “우리는 주문정보를 어떻게 보관한다”는 설명은 함께 있어야 한다. 탈중앙 지갑도 택배는 중앙 물류창고를 지난다.

5. 오늘 숫자도 라벨부터 확인했다

나머지 세 뉴스도 같은 교훈을 줬다. 비트코인 6만3,000달러 하회는 특정 시각의 가격이고, 독일 기업의 미국 직접투자 43억 유로는 기존 사업 철수가 아니라 신규 지분투자 약화를 포함한 흐름이다. 영국 주택의 2% 하락도 실제 체결가가 아니라 새 매물의 최초 호가다.

숫자 하나를 읽기 전에 나는 세 가지를 붙인다.

• 언제 측정했는가
• 무엇을 측정했는가
• 무엇은 포함하지 않았는가

가격표, 영수증과 통장잔액은 모두 숫자지만 같은 질문에 답하지 않는다. 개발자에게 데이터 스키마가 필요한 이유가 여기 있다. 시장 이야기는 투자·경제: 가격표만 믿지 않았다에 나눠 적었다.

내가 남긴 개발자 체크리스트

• 모든 객체 API에 서버 측 소유권 검사를 둔다.
• UUID를 권한통제 대신 사용하지 않는다.
• 서로 다른 계정으로 권한 회귀테스트를 자동화한다.
• 응답 필드, 로그와 백업까지 개인정보 범위에 넣는다.
• 보관기간과 삭제 작업이 실제로 지켜지는지 확인한다.
• 시세와 경제지표에는 기준시각·출처·측정 대상을 붙인다.

오늘 내 결론은 간단하다. 가장 비싼 금고를 샀다면 금고 옆 주문조회 버튼도 한 번 눌러보자. 공격자는 제품 소개서에서 가장 굵은 글씨보다, 시스템에서 가장 얇은 권한검사를 먼저 찾는다.