현대의 웹 서비스는 기능의 모듈화와 프론트엔드/백엔드의 분리로 인해 API 중심 아키텍처를 채택하는 경우가 일반화되고 있습니다. API는 클라이언트와 서버 간의 데이터 교환을 효율적으로 처리할 수 있게 해주는 중요한 구성 요소지만, 동시에 보안 측면에서는 공격자에게 노출된 인터페이스이기도 합니다.
특히 인증 이후에 수행되는 API 호출에서는 단순한 인증 절차만으로는 보안이 충분하지 않으며, 요청 대상이 실제로 요청자에게 권한이 있는 리소스인지를 판단하는 세부 권한 검증 로직이 필수적입니다. 하지만 실무에서는 이러한 검증이 누락되거나 일관되지 않게 적용되는 경우가 많고, 이는 곧 심각한 보안 취약점으로 이어질 수 있습니다.
이번 글에서는 API 설계에서 자주 발생하는 OWASP API Top 10의 API 권한 검증 관련 취약점인 Broken Object Level Authorization과 Broken Function Level Authorization의 구조적 문제를 설명하고, 이로 인해 발생 가능한 보안 위협을 소개해드리겠습니다.
■ API 권한 검증 취약점이란 무엇인가
API는 클라이언트가 특정 데이터를 요청하거나 서버 측 로직을 실행할 수 있도록 인터페이스를 제공합니다. 이때 사용자가 요청한 리소스나 기능이 그 사용자에게 허용된 범위 내에 있는지를 확인하는 것이 바로 권한 검증입니다.
예를 들어, 한 사용자가 자신의 주문 내역을 조회하는 API를 호출한다고 가정해봅시다.
|
GET /api/orders/1001 |
✔️Broken Object Level Authorization(BOLA)란
서버는 요청한 주문 ID 1001이 현재 로그인한 사용자에게 속한 리소스인지 검증해야 합니다. 검증이 누락된다면, 공격자는 단순히 ID 값을 증가시키는 것만으로 다른 사용자의 정보를 열람할 수 있습니다. 이는 Broken Object Level Authorization 문제에 해당하며, 줄여서 BOLA라고도 부릅니다.
✔️Broken Function Level Authorization(BFLA)란
또한, 관리자 전용 기능이 포함된 API(예: /api/admin/deleteUser)가 존재할 경우, 일반 사용자가 해당 API를 호출할 수 없도록 역할(Role) 기반 접근 제어가 서버에서 반드시 이루어져야 합니다. 이를 간과하면 Broken Function Level Authorization으로 이어질 수 있습니다.
■ 발생 가능한 BOLA 공격 시나리오
다음은 Broken Object Level Authorization, BOLA가 발생할 수 있는 코드 흐름의 예시입니다.
|
@app.route(‘/api/users/<int:user_id>’) def get_user_info(user_id): user = db.get_user_by_id(user_id) return jsonify(user) |
위 코드에서는 요청 URI에서 전달된 user_id 값에 대해 별도의 검증 없이 DB에서 사용자를 조회하고 결과를 반환하고 있습니다. 만약 로그인한 사용자와 user_id가 일치하지 않더라도 응답이 반환된다면, 공격자는 단순한 URL 조작으로 타인의 정보를 탈취할 수 있습니다.
또한, 다음과 같은 관리 기능이 있다고 가정해보겠습니다.
|
@app.route(‘/api/admin/reset-password’, methods=[‘POST’]) def reset_password(): target_user = request.json[‘user_id’] db.reset_password(target_user) return ‘Success’ |
위 코드에서 reset-password 기능은 관리자만 수행해야 하는 작업이지만, 별도의 역할 검증 없이 API를 호출할 수 있다면, 일반 사용자가 누구의 비밀번호든 재설정할 수 있는 보안 취약점이 됩니다. 이는 실무에서 자주 발생하는 구조적 결함입니다.
■ API 권한 검증 취약점을 해결하는 방법
권한 검증 문제를 방지하기 위해서는 다음과 같은 조치를 포함해야 합니다.
☑️ 리소스 소유자 검증
서버는 항상 요청된 리소스가 현재 사용자에게 속하는지 확인해야 하며, 단순히 URI의 ID 값만 신뢰해서는 안 됩니다.
☑️ 기능 단위 접근 제한
관리자 기능, 시스템 설정 API 등은 반드시 서버 측에서 역할 기반 권한 검사를 수행해야 합니다.
☑️ 화이트리스트 기반 필드 제어
isAdmin, role, user_id와 같은 민감 필드가 클라이언트로부터 조작될 수 없도록 서버에서 허용 필드를 명시적으로 제한해야 합니다.
■ API 보안 취약점 점검은 Sparrow DAST와 함께하세요
API는 현대 애플리케이션의 핵심 구성 요소이자, 동시에 외부에 가장 많이 노출된 보안 경로입니다. 특히 인증 이후의 인가 검증이 누락되면, 공격자는 단순한 요청 조작만으로도 타인의 데이터를 열람하거나 시스템 기능을 무단으로 호출할 수 있습니다.
이번 글에서는 OWASP API Security Top 10 2023에서 지적한 권한 검증 문제를 중심으로, 발생 원인과 구조적인 위험성을 살펴보았습니다. 이를 예방하기 위해서는 API 수준의 세분화된 권한 검증이 필요하며, 이를 전수 검사하거나 테스트 코드로 모두 커버하기에는 현실적으로 한계가 존재합니다.
따라서, 이러한 구조적 취약점을 점검하려면 자동화된 API 점검 체계를 도입하는 것이 효과적입니다. 스패로우는 이러한 점검 체계를 갖출 수 있도록 웹 애플리케이션 취약점 분석 도구, Sparrow DAST를 제공하고 있습니다. Sparrow DAST를 활용하면 다양한 사용자 권한을 시뮬레이션하고, 리소스 요청 결과를 비교 분석함으로써, 수동 점검으로는 발견하기 어려운 문제를 선제적으로 탐지할 수 있습니다. 또한, 수동 검토와 자동화된 점검을 함께 활용하여, 운영 중인 API에 존재할 수 있는 구조적 취약점을 선제적으로 식별하고, 체계적인 보안 체계를 구축할 수 있습니다.
개인정보 침해신고센터: (국번없이)118 (privacy.kisa.or.kr)