Access control vulnerability

개념

액세스 제어 또는 권한 부여(Authorization)는 작업을 수행하거나 리소스에 액세스 할 수 있는 제약 조건을 적용하는 것이다. 자격이 있는 사용자만 특정 작업을 수행할 수 있도록 하는 것이다. 웹 애플리케이션에서는 인증(Authentication)과 세션 관리(Session management)에 의존하여 액세스 제어를 한다.

인증(Authentication)은 사용자를 식별하고 요청자가 실제로 그 사람인지를 확인하는 작업을 한다. 세션 관리(Session management)는 HTTP 요청을 보낸 자가 이전에 인증한 동일한 유저인지 식별하는 작업을 한다.

손상된 액세스 제어는 치명적인 보안 취약점이다. 액세스 제어를 설계하고 관리하는 일은 비즈니스, 조직, 그리고 법적 제약을 기술 구현에 적용해야 하는 복잡하고 동적인 문제이다. 액세스 제어 설계에 대한 결정은 기술이 아닌 사람이 내려야하며, 이로 인해 오류 가능성이 높다.

엑세스 제어 보안 모델(Access Control Security Model)
- Programmatic Access Control
  - 사용자 권한에 대한 정보를 DB 또는 이와 유사한 곳에 저장
  - 액세스 제어는 이 데이터를 참조하여 프로그래밍 방식으로 적용
  - 이 모델은 역할, 그룹, 개별 사용자, 프로세스의 컬렉션 또는 워크 플로가 포함될 수 있으며, 매우 세분화될 수 있다.
- Discretionary access control (DAC)
  - 사용자 또는 그룹에 따라 리소스, 기능에 대한 액세스가 제한된다.
  - 리소스 또는 기능의 소유자는 사용자에게 액세스 권한을 할당하거나 위임할 수 있다.
  - 이 모델은 개별 리소스 또는 기능, 사용자에 대해 정의된 액세스 권한으로 매우 세분화되어 있다. 따라서 모델을 설계하고 관리하기가 매우 복잡해질 수 있다.
- Mandatory access control (MAC)
  - 주체에 의한 일부 개체 (파일 또는 기타 리소스)에 대한 액세스가 제한되는 중앙 제어 액세스 제어 시스템
  - DAC와 달리 리소스의 사용자와 소유자는 리소스에 대한 액세스 권한을 위임하거나 수정할 수 없다.
  - 군사 시스템 등 중앙에서 관리하는 시스템과 관련이 있다.
- Role-based access control (RBAC)
  - 액세스 권한이 할당되어 있는 역할을 정의한다. 사용자는 단일 또는 여러 역할에 할당된다.
  - 다른 제어 모델보다 향상된 관리 기능을 제공하며, 적절하게 설계된 경우 복잡한 어플리케이션에서 관리 가능한 액세스 제어를 제공할 수 있다.
  - 예를 들어 직원이 조직을 떠나면 직원의 역할을 일반 유저로 변경하는 등의 관리가 가능하다.
  - 모델을 지나치게 복잡하고 관리하기 어렵게 만들만큼 많지는 않아야 효과적으로 이용할 수 있다.

세부 카테고리

사용자 관점에서 액세스 제어는 다음 범주로 나눌 수 있다.

Vertical access controls
- 수직적 액세스 제어는 다른 유형의 사용자가 사용할 수 없는 민감한 기능에 대한 액세스를 제한한다.
- 관리자와 사용자 등
Horizontal access controls
- 수평적 액세스 제어는 특별한 사용자만 리소스에 접근할 수 있도록 제한한다.
- 서로 다른 사용자가 동일한 유형의 리소스 하위 집합에 액세스 한다.
- 사용자가 각자 자신의 계정에만 접근할 수 있는 등
Context-dependent access controls
- 애플리케이션의 상태 또는 사용자와의 상호 작용에 따라 기능 및 리소스에 대한 액세스를 제한한다.
- 사용자가 잘못된 순서로 작업을 수행하는 것을 방지한다.
- 결제 후 장바구니 내용을 수정하지 못하도록 하는 등

종류

수직적 권한 상승

사용자가 액세스가 허용되지 않은 기능에 대한 액세스 권한을 얻을 있다면 수직적 권한 상승이다. 관리자가 아닌 사용자가 관리자 페이지에 대한 액세스 권한을 얻는 등의 경우가 있다.

Unprotected functionality (보호되지 않은 기능)

가장 기본적인 수직 권한 상승은 애플리케이션이 민감한 기능에 대한 보호를 적용하지 않은 경우 발생한다. 예를 들어 관리자 페이지에 대한 참조가 사이트에는 없지만 직접 URL을 입력해 접속하면 접속 가능한 경우가 있다.

경우에 따라 이러한 위치가 robots.txt 파일 등에 공개될 수도 있다. URL이 어디에도 공개되지 않더라도 공격자는 워드리스트를 이용하여 무차별 대입을 할 수 있다.

참고 문제: Portswigger-Unprotected admin functionality

경우에 따라 민감한 기능이 강력하게 보호되지 않지만 또한 덜 예측 가능한 URL을 이용해 숨겨진다. Security by obscurity(모호성에 의한 보안)이라고도 하며 이 또한 취약하다. 사용자는 여전히 다양한 방법으로 난독화된 URL을 발견할 수 있다. javascript 등 소스코드에서 해당 URL을 이용하면 사용자에게 노출될 수 있다.

if (isAdmin) {
  ...
  var adminPanelTag = document.createElement('a');
  adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');
  adminPanelTag.innerText = 'Admin panel';
  ...
}
</script>

위와 같은 상황에서 경로는 administrator-panel-yb556로 예측하기 어려워졌지만, 여전히 사용자가 알아내고 접근할 수 있다.

참고 문제: Portswigger-Unprotected admin functionality with unpredictable URL

Parameter-based access control methods (파라미터 기반 액세스 컨트롤)

일부 어플리케이션은 로그인 시 사용자의 액세스 권한 또는 역할을 결정한 다음, 이 정보를 숨겨진 필드, 쿠키, 또는 사전에 설정된 쿼리 문자열 파라미터와 같이 사용자가 제어할 수 있는 위치에 저장한다.

예를 들어 https://insecure-website.com/login/home.jsp?admin=true, https://insecure-website.com/login/home.jsp?role=1 와 같은 형태를 이용한다.

이러한 방식은 단순히 값을 수정하여 권한을 변경할 수 있으므로 안전하지 않다.

참고 문제: Portswigger-User role controlled by request parameter

Broken access control resulting from platform misconfiguration (플랫폼 설정 오류로 인한 액세스 컨트롤 깨짐)

일부 애플리케이션은 사용 역할에 따라 특정 URL이나 HTTP 메소드에 대한 액세스를 제한하여 플랫폼 계층에서 액세스 제어를 시행한다. 예를 들어 DENY: POST, /admin/deleteUser, managers 와 같은 규칙으로 managers 그룹의 사용자가 URL /admin/deleteUser에 접근하는 것을 막는다. 이러한 상황을 우회하는 여러가지 방법이 있다.

일부 애플리케이션 프레임워크는 X-Origin-URL과 X-Rewrite-URL과 같은 비표준 HTTP 헤더를 이용해 URL을 재정의한다. URL을 통한 접근을 제한하기 위해 엄격한 프론트 엔드(여기서는 앞단에 있는 서버를 의미하는 듯)를 이용하더라도 이러한 헤더를 이용하면 우회할 수 있다.

POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...

위와 같이 X-Original-URL 헤더를 이용하여 URL을 재정의하면 우회할 수 있다.

참고 문제: Portswigger-URL-based access control can be circumvented

HTTP TRACE 메소드를 통해 리버스 프록시가 끼워넣는 헤더를 볼 수도 있다. 리버스 프록시는 예를 들어 요청 IP 등을 설정하곤 한다. 이 IP를 내부 로컬 IP 또는 특정 허용 리스트에 속하는 IP로 변경한다면 인증을 우회할 수 있다.

참고 문제: Portswigger-Authentication bypass via information disclosure

URL과 HTTP 메소드에 대하여 액세스 제한을 구현하기도 한다. 특정 권한이 있는 유저만 특정 HTTP 메소드를 사용할 수 있도록 한다. 하지만 일부 웹 사이트는 작업을 수행할 때 대체 HTTP 요청 메소드를 허용한다. 공격자가 제한된 메소드를 대체할 수 있는, 대체 메소드를 이용하여 제한된 URL에 접근할 수 있는 경우 플랫폼 계층에서 구현된 액세스 제어를 우회할 수 있다.

참고 문제: Portswigger-Method-based access control can be circumvented

수평적 권한 상승

사용자가 해당 유형의 자신의 리소스 대신 다른 사용자에게 속한 리소스에 액세스 할 수 있을 때 발생한다. 예를 들어 직원이 자신의 고용 및 급여 기록에만 액세스 할 수 있어야하지만 실제로 다른 직원의 기록에도 액세스할 수 있다면 이는 수평적 권한 상승이다.

수평적 권한 상승 공격은 수직적 권한 상승과 유사한 유형의 익스플로잇을 이용할 수 있다. 예를 들어 사용자가 일반적으로 https://insecure-website.com/myaccount?id=123와 같은 URL을 이용해 자신의 계정에 접근할 수 있을 때, 공격자가 id 파라미터를 다른 값으로 수정하면 다른 사용자의 계정에 접근할 수 있다.

참고 문제: Portswigger-User ID controlled by request parameter

일부 어플리케이션은 단순한 숫자나 예측 가능한 식별자 대신 GUID(Globally Unique Identifier)를 사용하여 예측하기 어렵게 한다. 그러나 다른 사용자의 GUID는 사용자 메시지나 리뷰와 같이 사용자를 참조하는 곳에서 노출될 수 있다. 이를 이용하여 위와 같이 파라미터를 수정하는 등의 우회를 시도할 수 있다.

참고 문제: Portswigger-User ID controlled by request parameter, with unpredictable user IDs

경우에 따라 어플리케이션은 사용자가 리소스에 액세스할 수 없음을 감지라고 로그인 페이지로 리다이렉트 한다. 하지만 이 리다이렉트 응답에도 타겟의 민감한 데이터가 포함될 수 있다. 리다이렉트 패킷에서 정보 유출이 일어나는 경우가 있다.

참고 문제: Portswigger-User ID controlled by request parameter with data leakage in redirect

수평적 권한 상승 → 수직적 권한 상승

수평적 권한 상승을 통해 수직적 권한 상승이 가능한 경우도 있다.

예를 들어 https://insecure-website.com/myaccount?id=123 와 같은 URL로 수평적 권한 상승이 가능, 다른 사용자 계정의 페이지에 액세스 할 수 있다. 그리고 이 페이지에서 사용자의 암호를 재설정하거나 캡처할 수 있다. 이 경우 공격자가 관리자 계정 페이지에 접근한다면, 비밀번호를 변경해 로그인하면 관리 액세스 권한을 얻을 수 있다.(수직적 권한 상승)

참고 문제: Portswigger-User ID controlled by request parameter with password disclosure

IDOR

IDOR은 애플리케이션이 사용자 제공 입력을 사용하여 개체에 직접 액세스하고, 입력을 수정하여 공격자가 무단으로 액세스할 수 있을 때 발생한다. 액세스 제어를 우회할 수 있는 많은 구현 실수의 한 예일 뿐이지만 OWASP 2007 Top 10에 등장해 대중화되었다.

자세한 설명은 idor 참고

Access control vulnerabilities in multi-step processes

어떠한 기능을 구현하기 위해 여러 단계에 걸쳐 작업을 수행하는 경우가 있다. 이 때 일부 단계에서만 엄격한 액세스 제어를 하고, 다른 단계에서는 적용되지 않는 경우가 있다.

예를 들어,

특정 사용자에 대한 세부 정보가 포함된 양식을 로드한다.
변경 사항을 제출한다.
변경 사항을 검토하고 확인한다.

위와 같이 3단계로 진행되는 작업 중 1, 2단계는 올바르게 액세스 컨트롤을 하지만, 3단계에서는 하지 않는 경우가 있다. 앞 단계를 완료한 경우에만 3단계에 도달할 것이라 가정하기 때문이다. 하지만 공격자는 처음 두 단계를 건너 뛰고, 필요한 매개 변수를 사용하여 3단계에 요청을 직접 제출하여 기능에 대한 무단 액세스 권한을 얻을 수 있다.

참고 문제: Portswigger-Multi-step process with no access control on one step

Referer-based access control

일부 웹사이트는 Referer 헤더를 액세스 제어에 이용한다. Referer 헤더는 일반적으로 요청이 시작된 페이지를 나타내기 위해 브라우저의 요청에 추가된다.

예를 들어, 프로그램이 관리 페이지의 메인 페이지인 /admin 에 대해서는 액세스 컨트롤을 강력하게 하지만, /admin/deleteUser 와 같은 하위 페이지에 대해서는 Referer 헤더만 검사하는 경우가 있다. Referer 헤더에 /admin URL이 포함되어 있으면 요청을 허용한다. 이 경우, Referer 헤더는 공격자에 의해 완전히 제어될 수 있으므로 하위 페이지에 대한 요청을 위조하여 무단 액세스를 얻을 수 있다.

참고 문제: Portswigger-Referer-based access control

Location-based access control

어떤 웹사이트는 사용자의 지리적 위치를 기반으로 리소스에 대한 액세스 제어를 한다. 예를 들어 미국 주 법률이나 비지니스 제한이 적용되는 은행 어플리케이션, 또는 미디어 서비스 등이 이를 이용한다.

이러한 액세스 제어는 프록시, VPN을 사용하거나 위치 정보 메커니즘을 조작하여 우회할 수 있다.

예방 방법

액세스 제어를 난독화에만 의존하지 않는다.
리소스를 공개적으로 액세스할 수 있는 경우가 아니라면 기본적으로 액세스를 거부한다.
가능한 경우 액세스 제어를 위해 single application-wide 메커니즘을 사용한다.
코드 수준에서는, 개발자가 각 리소스에 대해 허용되는 액세스를 선언해야 하며, 기본적으로 액세스를 거부해야 한다.
액세스 제어를 철저히 감시하고 테스트하여 설계한 대로 작동하는지 확인한다.

참고

tags:

Digital garden

Explorer

access control vulnerability