API5:2023 Broken Function Level Authorization
위협 요소/공격 경로 | 보안 취약점 | 영향 |
API 명세: 악용 용이함 | 확산성: 탐지 용이함 | 기술적 심각도: 특정 비지니스 |
악용하려면 공격자가 API end-points에 합법적인 API를 전송해야 하며, API end-points는 익명의 사용자 또는 권한이 없는 일반 사용자로써 액세스할 수 없습니다. 노출된 end-points는 쉽게 악용될 수 있습니다. | 기능이나 리소스에 대한 권한 검사는 일반적으로 구성이나 코드 수준을 통해 관리됩니다. 현대의 응용 프로그램은 많은 유형의 역할, 그룹 및 복잡한 사용자 계층(예: 하위 사용자 또는 둘 이상의 역할을 가진 사용자)을 포함할 수 있으므로 적절한 검사를 구현하는 것은 혼란스러운 작업이 될 수 있습니다. API는 더 구조화되어 있고 다른 기능에 액세스하는 것이 더 예측 가능하기 때문에 API에서 이러한 결함을 발견하는 것이 더 쉽습니다 | 이러한 결함은 공격자가 권한 없는 기능에 액세스할 수 있도록 합니다. 관리 기능은 이러한 유형의 공격의 핵심 대상이며 데이터 노출, 데이터 손실 또는 데이터 손상으로 이어질 수 있습니다. 궁극적으로 서비스 중단으로 이어질 수 있습니다. |
취약한 API
Broken function level authorization문제를 찾는 가장 좋은 방법은 사용자 계층, 애플리케이션의 다양한 역할 또는 그룹을 염두에 두고 다음 질문을 하면서 권한 부여 메커니즘을 심층적으로 분석하는 것입니다:
•
일반 사용자가 관리 end-points에 접근이 가능합니까?
•
사용자는 HTTP 방식(예: GET에서 DELETE로)을 변경하는 것만으로 접근할 수 없는 민감한 동작(예: 생성, 수정 또는 삭제)을 수행할 수 있습니까?
•
그룹 X의 사용자가 end-points URL과 매개변수(예: /api/v1/users/export_all)를 추측하는 것만으로 그룹 Y의 사용자에게만 노출되어야 하는 기능에 액세스할 수 있습니까?
API의 URL 경로만을 기준으로 일반 사용자와 관리자를 구분하지 마십시오.
개발자들은 /api/admins와 같은 특정 상대 경로 아래에서 대부분의 관리 end-points를 노출하도록 선택할 수 있지만, 일반 end-points와 함께 /api/users와 같은 다른 상대 경로 아래에서 이러한 관리 end-points를 찾는 것은 매우 일반적입니다.
공격 시나리오
Scenario #1
초대된 사용자만 가입할 수 있도록 허용한 애플리케이션의 등록 프로세스 중에 모바일 애플리케이션은 GET /api/invite/{invite_guid}로 API 호출을 트리거합니다. 응답에는 접속에 대한 세부 정보와 함께 사용자의 역할 및 사용자의 이메일을 포함한 JSON이 포함됩니다.
공격자가 요청을 복제하고 HTTP 메서드와 end-points를 POST/api/invites/new로 조작합니다. 해당 URL으로의 접근은 관리 콘솔을 사용하는 관리자만 액세스해야 합니다. end-points는 기능 수준 권한 검사를 구현하지 않습니다.
공격자가 이 문제를 이용하고 관리자 권한으로 새 초대를 보냅니다:
POST /api/invites/new
{
"email": "attacker@somehost.com",
"role":"admin"
}
JavaScript
복사
나중에 공격자는 악의적으로 조작된 초대를 사용하여 관리자 계정을 만들고 시스템에 대한 전체 액세스 권한을 얻습니다.
Scenario #2
API에는 관리자에게만 노출되어야 하는 end-points (GET /api /admin /v1 /users/all)가 포함되어 있습니다. 이 end-points는 애플리케이션의 모든 사용자의 세부 정보를 반환하고 기능 수준 권한 검사를 구현하지 않습니다. API 구조를 학습한 공격자는 교육된 추측을 한 후 이 end-points에 액세스하여 애플리케이션 사용자의 민감한 세부 정보를 노출합니다.
예방 방법
애플리케이션에는 모든 비즈니스 기능에서 호출되는 일관되고 분석하기 쉬운 인증 모듈이 있어야 합니다. 이러한 보호는 애플리케이션 코드 외부의 하나 이상의 구성 요소에 의해 제공되는 경우가 많습니다.
•
적용 메커니즘은 기본적으로 모든 액세스를 거부해야 하며, 모든 기능에 대한 액세스를 위해 특정 역할에 대한 명시적 승인을 요구합니다.
•
애플리케이션 및 그룹 계층의 비즈니스 논리를 염두에 두고 기능 수준 권한 부여 결함에 대한 API end-points를 검토합니다.
•
사용자의 그룹/역할에 따라 권한검사를 구현한 컨트롤러에서 모든 관리 컨트롤러가 상속되는지 확인합니다.
•
일반 컨트롤러 내부의 관리 기능이 사용자의 그룹과 역할에 따라 권한 검사를 구현하는지 확인합니다.
References
OWASP
•
"A7: Missing Function Level Access Control", OWASP Top 10 2013