태국에서 효과적인 API 모의 침투 테스트

애플리케이션은 몇 년 전부터 더 이상 “웹사이트"가 아닙니다. 이제 API입니다. 마이크로서비스가 마이크로서비스를 호출하고, 한쪽 끝엔 모바일 클라이언트, 다른 끝엔 결제 인프라가 있습니다. 보안 논의는 아직 완전히 따라오지 못했습니다. 팀들은 노력의 80%가 프런트엔드에 들어가는 “웹 애플리케이션 침투 테스트"를 여전히 구매하고, 그 뒤의 API, 돈과 데이터가 실제로 움직이는 곳은 덜 테스트됩니다.

API가 스캐너를 빠져나가는 이유 #

자동 웹 스캐너는 페이지 모델을 전제로 만들어졌습니다. 링크를 크롤링하고, 폼을 찾고, 페이로드를 주입합니다. API는 페이지를 제공하지 않습니다. 라우트와 메서드와 스키마를 제공하고, 흥미로운 동작은 그 사이의 비즈니스 로직에 있습니다.

객체 수준 접근 결함을 생각해 봅시다. 사용자가 요청의 user_id=1024를 user_id=1025로 바꾸고 다른 사람의 기록을 읽습니다. 서명은 울지 않고, 악성 페이로드도 없습니다. 스캐너는 정상적인 요청으로 보고 지나칩니다. 이것이 BOLA(Broken Object Level Authorisation), OWASP API Security Top 10 1위 항목이며, 거의 모든 자동 도구에 보이지 않습니다.

이것이 사람이 주도하는 API 테스트의 핵심 논거입니다. 가장 피해가 큰 결함은 설계 결함이고, 설계 결함을 찾으려면 비즈니스 맥락을 이해하는 분석가가 필요합니다.

효과적인 API 테스트가 실제로 다루는 것 #

의미 있는 API 평가는 OpenAPI 명세에 스캐너를 돌리는 것 이상입니다:

인증과 권한: 토큰 처리, 스코프 검사, 모든 역할 경계에서의 객체 수준 접근.
비즈니스 로직: 사용자가 주문 가격을 음수로 만들거나, 결제 콜백을 재생하거나, 다음 엔드포인트를 직접 호출해 워크플로 단계를 건너뛸 수 있는가?
데이터 노출: 어떤 엔드포인트가 필드를 과잉 반환하고, 어떤 것이 클라이언트가 보내선 안 되는 필드를 받아들이는가?
속도 제한과 남용: 열거, 크레덴셜 스터핑, 약한 스로틀링을 악용한 계정 탈취 경로.
통합 경계: webhook, 서드파티 콜백, 메시지 큐. 신뢰가 가정되고 검증되지 않는 곳들.

그래서 최고의 프로젝트는 수동 공격 기법과 AI 보조 정찰 및 퍼징을 결합합니다. 자동화가 커버리지를 넓히고, 사람이 심각도와 맥락을 판단합니다.

연례가 아닌 지속 #

1년에 한 번의 API 테스트는 매주 배포되는 시스템의 특정 시점 스냅샷입니다. 보고서가 쓰여질 무렵엔 엔드포인트가 이미 바뀌었습니다. 현대적 접근은 API 보안 점검을 전달 파이프라인 안으로 넣습니다:

CI에서 정적 분석과 스키마 검증으로 좌측 이동.
릴리스마다 테스트: API 표면이 바뀔 때 집중 검토.
연간 심층 평가: 감사 추적과 파이프라인이 판단할 수 없는 비즈니스 로직을 위해 사람이 주도하는 전체 평가.

카드 데이터를 다루는 조직에게 PCI DSS 요구사항 6과 요구사항 11.4 모두 이 방향을 밀어주며, 태국 중앙은행 디지털 채널 보안 지침도 마찬가지입니다.

flowchart LR A[CI의 스키마·SAST] --> B[릴리스 게이트 API 검토] B --> C[사람이 주도하는 심층 평가] C --> D[조치 및 재테스트] D --> A style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

자동화 스캐너가 못 보는 것들 #

자동화가 무엇을 놓치는지 구체적으로 말할 가치가 있습니다. 그 빈틈은 무작위가 아니기 때문입니다. 정확히 돈이 흐르는 곳에 몰려 있습니다.

실전 속 BOLA. 스캐너는 자신이 발견한 엔드포인트와 이해한 파라미터만 시험합니다. 인보이스 API를 예로 들면: GET /invoices/8842는 호출자 본인의 인보이스를 돌려주므로 스캐너는 합격을 기록합니다. 그러나 GET /invoices/8843, 즉 남의 인보이스도 똑같이 쾌적하게 돌아올 수 있는데 어느 스캐너도 시도하지 않습니다. 8843이 남의 것이라는 걸 알려면 소유권이 귀사 비즈니스에서 무슨 의미인지 알아야 하기 때문입니다. 테넌트 경계를 넘는 모든 오브젝트 식별자가 잠재적 BOLA이며, 계정 간 오브젝트를 하나씩 열거해보는 분석가만 찾아냅니다.

비즈니스 로직 결함. 스캐너는 요청이 성공했는지 실패했는지를 시험합니다. 로직 결함은 성공해서는 안 되는데 성공하는 요청에 숩니다. 실제 engagement에서 나온 예들: 결제 캡처 이후에 적립 확인이 이루어져 쿠폰 코드를 두 번 쓸 수 있음; 재인증 없이 계정 간 예약을 옮길 수 있음; cancel 엔드포인트가 이행 상태를 확인하지 않아 발송된 유료 주문을 취소할 수 있음. 전부 HTTP 200을 돌려줍니다. 전부 에러 메시지 없는 재정 손실입니다.

서비스 간 신뢰 가정. 마이크로서비스 환경에서 한 서비스는 “호출자"가 제공하는 헤더, 토큰, 내부 엔드포인트를 습관적으로 신뢰합니다. 설계도상 호출자는 언제나 내부 서비스였으니까요. 그러다 어느 날 한 서비스가 침해되거나, 내부 엔드포인트 하나가 덜 신뢰되는 네트워크 구간에서 닿게 되면, 물려받은 신뢰 가정이 공격자의 사다리가 됩니다: 약한 에지 서비스에서 먼저 인증하고, 그 정체를 값나가는 API들이 있는 하류에 넘겨주는 겁니다. 이걸 찾으려면 설계자의 의도대로 아키텍처를 읽고, 공격자가 통과할 경로로 시험해봐야 합니다.

이 세 가지 중 어느 것도 스캐너 출력에는 나오지 않습니다. 전부 귀사 API가 실제로 만들어진 목적을 이해하느라 시간을 쓴 분석가의 보고서에 나옵니다.

공격자의 눈에 고객의 API가 어떻게 보이는지 궁금하신가요? 부담 없이 현황 점검을 요청하세요. LINE(@PureSecurity) 또는 이메일(hello@puresecurity.com)로 연락 주시면 됩니다.

저희 API & 애플리케이션 보안 점검은 수동 소스코드 분석과 문맥화된 모의 침투 테스트를 결합해 개발자가 바로 쓸 수 있는 수정 가이드를 제공합니다. 경계와 세그멘테이션의 더 넓은 검증이 필요하시면 Human-Led 모의 침투 테스트를 참조하세요.