조회 API 인증 허점, 내 서비스 점검 3가지

조회 기능 하나로 2만5천 명 정보가 샜다

신한은행에서 고객 약 2만5000명의 정보가 외부로 빠져나간 사실이 10월 1일 공개됐다. 유출된 항목은 이름과 전화번호, 연소득, 대출 산출한도 같은 신용 관련 정보였고, 주민등록번호 66건과 연계정보(CI) 97건도 포함됐다. 은행은 "외부에서 인증 절차를 우회하는 비정상적인 방식으로 일부 서비스에 접근"했다고 설명했다.

이 사고가 고객 조회나 상담 서비스를 운영하는 쪽에 주는 신호는 분명하다. 공격의 입구가 거창한 해킹이 아니라 평범한 조회 기능이었다는 점이다.

알려진 경위, 뚫린 곳은 '조회의 문턱'

Photo by FlyD on Unsplash

금융감독원은 9월 30일부터 긴급 현장점검에 들어갔고, 금융위원회·한국인터넷진흥원과 함께 대응 회의를 열었다. 다만 정확한 침투 방식은 아직 조사 중이라 단정하기는 이르다. 은행과 언론 설명을 종합하면, 로그인 기반의 뱅킹 거래를 직접 뚫은 해킹은 아닌 것으로 전해진다. 대출 관련 조회 시스템이 표적이 됐고, 아이디·비밀번호를 자동으로 대량 대입하는 크리덴셜 스터핑 가능성이 거론됐다.

주목할 표현은 '인증 우회'다. 사용자가 정상적으로 거쳐야 할 신원 확인을 건너뛰었거나, 한 번 받은 권한으로 원래 볼 수 없는 데이터까지 조회했다는 뜻으로 읽힌다. 조회형 서비스에서 가장 흔한 약점이 바로 이 지점이다. 화면에는 내 정보만 보이지만, 그 뒤의 API는 식별값만 바꾸면 남의 정보도 내주도록 설계된 경우가 적지 않다.

조회형 API에서 먼저 볼 세 가지

운영 중인 고객 조회 기능이나 AI 상담 서비스가 있다면 점검은 다음 순서가 효율적이다.

인증부터 본다. 토큰이나 세션이 '로그인했는가'만 확인하고 끝나는지, 아니면 '이 사용자가 이 데이터에 접근할 권한이 있는가'까지 확인하는지가 갈린다. 요청에 담긴 고객번호를 그대로 믿지 말고 서버가 가진 세션 주체와 대조해야 한다. 이 대조가 없으면 식별값 하나만 바꿔도 남의 기록이 열린다.

다음은 호출 제한이다. 정상 사용자는 1초에 수십 번씩 같은 조회를 반복하지 않는다. 크리덴셜 스터핑이나 대량 수집은 짧은 시간에 같은 창구를 반복해서 두드리는 특성이 있다. IP·계정·API 키 단위로 분당 호출 한도를 두고 임계치를 넘으면 차단하거나 추가 인증을 요구하도록 하면, 자동화 공격의 비용이 크게 올라간다.

마지막은 로그다. 이번 사고에서 은행이 외부 IP를 차단하고 서비스를 중단할 수 있었던 것도 비정상 접근을 식별할 기록이 있었기 때문이다. 누가 어떤 데이터를 얼마나 조회했는지 남겨야 사후 추적이 되고, 평소와 다른 패턴을 실시간으로 잡아낼 수 있다. 로그가 없으면 유출 규모조차 추정하기 어렵다.

지금 바로 돌려볼 점검표

• 조회 API가 요청에 담긴 식별값을 세션 주체와 대조하는가, 아니면 그대로 신뢰하는가
• 주민번호·연소득 같은 민감정보를 내려주는 엔드포인트에 별도 권한 검사가 있는가
• IP·계정·키 단위 호출 한도와 임계치 차단이 설정돼 있는가
• 짧은 시간의 반복 로그인 실패나 반복 조회를 탐지해 경보하는 체계가 있는가
• 조회 로그에 '누가·언제·무엇을'이 남고, 일정 기간 보관되는가
• AI 상담봇이 내부 조회 API를 호출한다면, 봇에도 사용자 권한 범위가 그대로 적용되는가
• 사고가 나면 특정 IP·키를 즉시 차단하고 피해 범위를 안내할 수 있는가

규모가 큰 금융사도 조회의 문턱에서 뚫렸다. 내 서비스가 '로그인만 되면 다 보여주는' 구조는 아닌지, 위 항목부터 확인해 보는 편이 안전하다. 정확한 침투 방식이 더 밝혀지면 점검 항목도 보완해야 한다.

출처

1. 신한銀, 2만5천명 정보 유출… 금감원 긴급 현장조사