“결제는 정상인데, 돈이 틀리는 최악의 사고”
결제·요금·포인트 API 변조
“결제 시스템은 멀쩡한데… 왜 돈이 안 맞을까요?”
정산팀에서 먼저 이상 징후를 발견했습니다. 매출 그래프는 분명히 올라가고 있는데, 실제 입금된 금액이 조금씩 부족했습니다.
처음에는
- 카드 수수료 문제인가?
- PG사 정산 지연인가?
- 내부 회계 오류인가?
모든 걸 점검했지만 서버 로그도, 결제 승인 기록도 ‘정상’이었습니다.
그런데 한 달이 지나자 그 “조금”이 수천만 원이 되어 있었습니다.
이것이 바로 결제·요금·포인트 API 변조 사고의 시작입니다.
왜 이 사고가 그렇게 위험할까?
결제 관련 사고는 많지만 이 유형이 특히 위험한 이유는 단 하나입니다.
서버는 끝까지 ‘정상 요청’이라고 믿는다는 점.
- 결제 승인 정상
- API 응답 정상
- 로그 이상 없음
그래서 탐지가 늦어집니다.
그리고 공격자는
- 한 번에 크게 훔치지 않습니다
- 소액을, 아주 오래, 조용히 가져갑니다
➡ 금전 피해 + 탐지 난이도 최고 그래서 TOP 2입니다.
실제로 발생한 API 변조 시나리오
해당 라이프스타일 앱은 포인트 결제와 인앱 결제를 함께 운영하고 있었습니다.
공격 흐름은 이랬습니다
- 네트워크 후킹
- 변조된 앱 환경에서 API 트래픽 가로채기
- API 파라미터 미세 조작
- 결제 금액, 포인트 차감 수치 조정
- 결제 승인 후 차감 왜곡
- PG 결제는 정상
- 실제 사용자 차감 금액만 다르게 처리
사용자 화면에는 “결제 완료”가 뜨고 서버에도 “정상 승인” 기록이 남습니다.
하지만 숫자만 살짝 바뀐 채 흘러갑니다.
보안의 핵심 문제는 무엇이었을까?
이 사고의 본질은 서버 보안이 아니라 클라이언트 신뢰 문제였습니다.
구체적인 문제점
- 변조 앱·후킹 환경에서도 API 호출 허용
- 클라이언트 전달 금액을 그대로 신뢰
- 정상 사용자와 조작 사용자의 행위 구분 불가
- 소액 반복 공격에 대한 탐지 기준 부재
즉, “정상 API 호출 = 정상 사용자”라는 착각이 가장 큰 보안 구멍이었습니다.
LIAPP은 어떻게 방어했는가
사고 이후, 이 서비스는 결제 구조를 뜯어고치기 전에 앱 실행 환경부터 다시 점검했습니다.
LIAPP – 변조·후킹 환경 차단
- 네트워크 후킹·프록시 사용 탐지
- 앱 무결성 검증 (리패키징·변조 차단)
- 메모리 조작·API 훅킹 시 실행 차단
- 자동화·스크립트 기반 호출 탐지
- 의심 유저 자동 차단
조작된 환경에서는 결제 API 자체를 호출하지 못하게 차단
‘조금씩 훔치는 공격’을 데이터로 잡아냄
계정이 있어도, 환경이 의심되면 돈은 못 움직이게
보안 적용 이후, 어떤 변화가 있었을까?
보안 적용 후
- 결제 금액 불일치 현상 완전 차단
- 포인트 악용 사례 급감
- 정산·감사 리스크 해소
- 외부 감사 대응 시간 단축
무엇보다 중요한 변화는 이것입니다.
“결제는 서버만 지키면 된다”는 생각이 완전히 바뀌었다는 점
이 사례가 주는 교훈
결제 사고의 시작은 항상 아주 작은 숫자입니다.
- 100원
- 200원
- 500원
하지만 방치하면 그 숫자는 회사의 신뢰와 서비스 존속을 위협합니다.
결제 보안의 핵심은 **금액이 아니라 ‘요청의 신뢰성’**입니다.
그리고 그 신뢰는
- 앱이 정상인지
- 환경이 안전한지
- 사람이 직접 사용하는지
를 함께 보지 않으면 지킬 수 없습니다.
결제 API는 서버가 아니라, 앱부터 지켜야 합니다.
#라이프스타일앱 #결제보안 #API변조 #포인트악용 #인앱결제 #금융사고 #모바일보안 #앱보안 #정산리스크 #감사대응 #보안사고사례 #후킹공격 #LIAPP #LISS #LIKEY
