블로그 목록으로 돌아가기

GOTROOT / 모의해킹

API 인가, 어디서 새는가 — 두 계정으로 차분히 확인하는 BOLA·BFLA·토큰 우회 | GOTROOT

객체 수준 인가(BOLA/IDOR), 함수 수준 인가(BFLA), Mass Assignment, JWT·토큰 위조, 레이스 컨디션까지 — 자동 스캐너가 놓치는 API 인가 문제를 두 계정 차등 비교로 차분히 확인하는 방법을 실제 요청 예시와 함께 정리했습니다.

GOTROOT 리서치 팀 2026. 6. 5.

API는 화면 뒤에서 조용히 데이터를 나릅니다. 그래서 API에서 가장 치명적인 결함은 화려한 인젝션보다 인가(authorization)인 경우가 많습니다. “이 요청을 이 사람이 해도 되는가?”는 비즈니스 규칙이라, 자동 스캐너가 옳고 그름을 판단하기 어렵습니다. 가장 흔하면서 가장 자주 놓치는 이유죠. 이 글은 저희가 API를 점검할 때 인가 문제를 어떻게 찾는지, 실제 요청 예시와 함께 차분히 정리한 글입니다.

API 인가 우회 탐지 흐름 — 두 계정 준비, B 토큰으로 재전송, 응답 차등 비교, 인가 경계 판정
두 계정 차등 비교 — A의 요청을 B의 토큰으로 보내, 인가 경계가 실제로 강제되는지 확인합니다

핵심은 ‘두 계정 차등 비교’

인가 점검의 출발점은 단순합니다. 권한이 다른 두 계정(A·B)을 준비하고, A의 세션으로 B의 데이터·기능에 닿는지 비교해 보는 거죠. Burp의 Autorize 같은 도구는 A의 요청을 B의 토큰으로 자동 재전송해 그 차이를 한눈에 보여줍니다.

BOLA / IDOR — 객체 수준 인가

API 취약점 중 가장 흔한 유형입니다. 식별자만 바꿔 남의 객체에 접근되는지 봅니다.

# A의 토큰으로 B 소유의 주문(124)을 요청해 봅니다
GET /api/v1/orders/124 HTTP/1.1
Authorization: Bearer <A_TOKEN>

# 200 + 타인 데이터가 오면 BOLA입니다 (정상이라면 403/404)

“추측 불가능한” UUID도 다른 응답·로그·열거를 통해 흘러나오는 경우가 많아, 식별자의 무작위성만으로는 인가를 대신할 수 없습니다. 읽기뿐 아니라 수정·삭제(PUT/PATCH/DELETE)와 중첩 리소스(주문→결제→카드)까지 함께 봅니다.

BFLA · Mass Assignment

일반 사용자가 관리자 ‘기능’을 호출할 수 있는지(BFLA), 그리고 요청 바디에 권한 필드를 끼워 넣어 덮어쓸 수 있는지(Mass Assignment)를 확인합니다.

PATCH /api/v1/users/me HTTP/1.1
Authorization: Bearer <A_TOKEN>
Content-Type: application/json

{"nickname":"x","role":"admin","is_verified":true}
# role / is_verified 가 반영되면 Mass Assignment 입니다

토큰을 위조할 수 있는가

API 인가는 결국 토큰 검증에 기댑니다. JWT를 쓴다면 알고리즘 혼동(alg:none, RS256→HS256 key confusion), 만료·서명 미검증, kid를 통한 키 주입 등 “토큰을 위조해 권한을 올릴 수 있는가”를 봅니다. 그리고 상태가 중요한 엔드포인트(1회용 쿠폰·잔액 차감)는 동시 요청(레이스 컨디션)으로 제약이 풀리는지도 확인합니다.

한 걸음 더 — 토큰 라이브러리와 컴포넌트

인가 로직이 직접 짠 코드만의 문제는 아닙니다. JWT 검증 라이브러리, API 게이트웨이, 직렬화 컴포넌트처럼 ‘기대고 있는 부품’에 알려진 취약점이 있으면 그게 곧 우회로가 됩니다. 실제 표적 공격(APT)도 이런 지점을 노리기 때문에, 저희는 사용 중인 컴포넌트와 버전을 식별하고 알려진 결함(1-day)이 이 환경에서 실제로 악용되는지 통제된 범위에서 확인합니다. (관련: 0-day는 어떻게 발굴되는가)

점검할 때 저희가 보는 것들

  • 권한이 다른 2개 이상 계정으로 모든 엔드포인트 차등 비교

  • 읽기뿐 아니라 쓰기·삭제, 메서드 변조까지

  • 식별자: 숫자·UUID·중첩·GraphQL node 전부

  • 토큰: 만료·서명·알고리즘·scope 강제 여부

  • 상태 엔드포인트: 동시성(race) 테스트

현장 노트: 인가는 결국 “이 요청이 허용돼야 하는가?”라는 비즈니스 질문입니다. 그 답은 사람이 맥락을 봐야 알 수 있어서, 자동화가 아무리 좋아져도 사람의 확인이 한 겹 더 필요한 영역인 것 같습니다.

자주 묻는 질문

API만 따로 점검해야 하나요?

API는 위협 모델과 인가 구조가 웹 화면과 달라, 전용 시나리오와 다계정 셋업이 도움이 됩니다. 함께 보시는 걸 권해드립니다.

UUID를 쓰면 BOLA는 안전한가요?

아쉽지만 그렇지 않습니다. UUID도 다른 경로로 유출될 수 있어, 식별자의 무작위성은 인가의 대체재가 되지 못합니다.

마치며

API 인가 결함 하나가 대량 정보 유출로 이어지기도 합니다. 그래서 더더욱 차분히, 두 계정으로 경계를 하나씩 확인해 보는 게 중요한 것 같습니다. 우리 API의 실제 인가 경계를 함께 점검해 보고 싶으시면 API 모의해킹 상담으로 편하게 연락 주세요.