Access control이란
Access control(접근 제어) 또는 authorization(권한부여)는 누가(또는 무엇을)시도한 작업을 수행하거나 요청한 리소스에 접근할 수 있는지에 대한 제약 조건을 적용하는 것이다. web application의 context에서 접근 제어는 인증 및 세션 관리에 따라 달라진다.
- Authentication은 사용자를 식별하고 말하는 사람인지 확인한다.
- Session management는 동일한 사용자가 보낸 subsequent HTTP 요청을 식별한다.
- Access control은 사용자가 수행하려는 작업을 수행할 수 있는지 여부를 결정한다.
손상된 접근 제어는 일반적으로 접하게 되는 중요한 보안 취약점이다. 접근 제어의 설계 및 관리는 기술 구현에 business, 조직 및 볍적 제약을 적용하는 복잡하고 동적인 문제이다. 접근 제어 설계 결정은 기술이 아닌 사람이 내려야 하며 오류 가능성이 높다.
사용자 관점에서 접근 제어는 다음 범주로 나눌 수 있다.
- Vertical access controls
- Horizontal access controls
- Context-dependent access controls
Vertical access controls
Vertical access controls는 다른 유형의 사용자가 사용할 수 없는 중요한 기능에 대한 접근을 제한하는 메커니즘이다.
Vertical access controls를 통해 다양한 유형의 사용자가 다양한 application 기능에 접근할 수 있다. 예를 들어 관리자는 사용자의 계정을 수정하거나 삭제할 수 있지만 일반 사용자는 이러한 작업에 접근할 수 없다. Vertical access controls는 업무 분리 와 최소 권한과 같은 business 정책을 시행하도록 설계된 보안 모델의 세분화된 구현일 수 있다.
Horizontal access controls
Horizontal access controls는 해당 리소스에 대한 접근이 특별히 허용된 사용자에게 리소스에 대한 접근을 제한하는 메커니즘이다.
Horizontal access controls를 사용하면 서로 다른 사용자가 동일한 유형의 리소스의 subset에 접근할 수 있도록 하는 것이다.
Context-dependent access controls
Context-dependent access controls는 application의 상태 또는 application과 사용자의 상호작용을 기반으로 기능 및 리소스에 대한 접근을 제한하다.
Context-dependent access controls는 사용자가 잘못된 순서로 작업을 수행하는 것을 방지한다. 예를 들어, 웹사이트는 사용자가 결제한 후 장바구니의 내용을 수정하지 못하도록 한다.
Broken access controls 예
Broken access controls은 사용자가 실제로 일부 리소스에 접근하거나 접근할 수 없는 일부 작업을 수행할 수 있을 때 존재한다.
Vertical privilege escalation
사용자가 접근이 허용되지 않은 기능에 접근할 수 있는 경우 이것은 vertical privilege escalation이다. 예를 들어 관리자가 아닌 사용자가 실제로 사용자 계정을 삭제할 수 있는 관리자 페이지에 대한 접근 권한을 얻을 수 있다면 이는 vertical privilege escalation이다.
Unprotected funtionality
가장 기본적인 vertical privilege escalation은 application이 민감한 기능에 대한 보호를 시행하지 않는 경우에 발생한다. 예를 들어 관리 기능은 관리자의 시작 페이지에서 연결되지만 사용자의 시작 페이지에서는 연결되지 않는다. 하지만 사용자는 관련 관리 URL을 직접 탐색하여 관리 기능에 접근할 수 있다.
예를 들어 웹사이트는 다음 URL에서 중요한 기능을 호스팅 할 수 있다.
https://insecure-wevsite.com/admin이것은 실제로 사용자 인터페이스의 기능에 대한 링크가 있는 관리 사용자뿐만 아니라 모든 사용자가 접근할 수 있다. 경우에 따라 관리 URL이 robots.txt파일과 같은 다른 위치에 공개될 수 있다.
https://insecure-website.com/robots.txtURL이 어디에도 공개되지 않더라도 공격자는 단어 목록을 사용하여 중요한 기능의 위치를 brute-force할 수 있다.
어떤 경우에는 민감한 기능이 강력하게 보호되지 않고, 예측하기 어려운 URL로 숨겨지는 경우가 있다. 이를 “보안의 모호함(security by obscurity)”라고 한다. 그러나 단순히 민감한 기능을 숨기는 것만으로는 효과적인 접근 제어를 제공할 수 없다. 사용자들은 여전히 다양한 방법으로 난독화된 URL을 발견할 수 있기 때문이다.
예를 들어 다음 URL에서 관리 기능을 호스팅하는 application을 생각해 본다.
https://insecure-website.com/administratorpanel-yb556이는 공격자가 직접 추측할 수 없다. 그러나 applicaiton은 여전히 사용자에게 URL을 유출할 수 있다. 예를 들어 URL은 사용자의 역할에 따라 사용자 인터페이스를 구성하는 javascript에서 공개될 수 있다.
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>이 스크립트는 관리자인 경우 사용자 UI에 대한 링크를 추가한다. 그러나 URL이 포함된 스크립트는 역할에 관계없이 모든 사용자에게 표시된다.
Parameter-based access control methods
일부 application은 로그인 시 사용자의 접근 권한 또는 역할을 결정한 다음 이 정보를 숨겨진 필드, 쿠키 또는 미리 설정된 쿼리 문자열 parameter와 같은 사용자가 제어할 수 있는 위치에 저장한다. application은 제출된 값을 기반으로 후속 접근 제어 결정을 내린다. 예를 들면:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1이 접근 방식은 사용자가 단순히 값을 수정하고 관리 기능과 같이 권한이 없는 기능에 대한 접근 권한을 얻을 수 있기 때문에 근본적으로 안전하지 않다.
Broken access control resulting from platform misconfiguration
일부 application은 사용자 역할에 따라 특정 URL 및 HTTP 메서드에 대한 접근을 제한하여 플랫폼 계층에서 접근 제어를 시행한다. 예를 들어 application은 다음 규칙을 구성할 수 있다.
DENY: POST, /admin/deleteUser, managers이 규칙은 관리자 그룹의 사용자에게 /admin/deleteUser URL의 POST 메서드 접근을 거부한다. 이 상황에서는 다양한 문제가 발생할 수 있고, 이로 인해 접근 제어 우회가 발생할 수 있다.
일부 application 프레임워크는 X-Original-URL 및 X-Rewrite-URL와 같은 원래 요청의 URL을 재정의하는 데 사용할 수 있는 다양한 비표준 HTTP 헤더를 지원한다. 웹 사이트에서 엄격한 프론트 엔드 제어를 사용하여 URL을 기반으로 접근을 제한하지만 application에서 URL이 요청 헤더를 통해 재정의되도록 허용하는 경우 다음과 같은 요청을 사용하여 접근 제어를 우회할 수 있다.
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...요청된 사용된 HTTP 메서드와 관련하여 대체 공격이 발생할 수 있다. 위의 프론트 엔드 제어는 URL 및 HTTP 메서드를 기반으로 접근을 제한한다. 일부 웹 사이트는 작업을 수행할 때 대체 HTTP 요청 방법을 허용한다. 공격자가 GET (또는 다른) 메서드를 사용하여 제한된 URL에서 작업을 수행할 수 있는 경우 플랫폼 계층에서 구현되는 접근 제어를 우회할 수 있다.
Broken access control resulting from URL-matching discrepancies
들어오는 요청을 라우팅할 때 웹사이트는 경로가 엔드포인트와 경로가 얼마나 엄격하게 일치해야 하는지에 따라 다르다. 예를 들어 웹 사이트는 대소문자를 일관성 없이 사용하는 것에 내성이 있으므로, /ADMIN/DELETEUSER로 보낸 요청도 여전히 동일한 /admin/deleteUser 엔드 포인트에 매핑될 수 있다. 이 자체로는 문제가 되지 않지만, 접근 제어 메커니즘이 내성이 낮을 경우 이를 두 개의 서로 다른 엔드포인트로 처리하여 적절하게 제한하지 못할 수 있다.
Spring 프레임워크를 사용하는 개발자들이 useSuffixPatternMatch 옵션을 활성화한 경우에도 비슷한 차이가 발생할 수 있다. 이 옵션은 임의의 파일 확장자가 있는 경로를 파일 확장자가 없는 동일한 엔드 포인트에 매핑할 수 있게 해준다. 즉, /admin/deleteUser.anyting 로 보낸 요청도 /admin/deleteUser 패턴과 일치하게 된다. Spring 5.3 이전에는 이 옵션이 기본적으로 활성화되어 있다.
다른 시스템에서는 /admin/deleteUser와 /admin/deleteUser/ 이 서로 다른 엔드포인트로 처리되는 경우가 있다. 이 경우 경로에 끝에 슬래시를 추가하기만 하면 접근 제어를 우회할 수 있다.
Horizontal privilege escalation
Horizontal privilege escalation은 사용자가 해당 유형의 자체 리소스 대신 다른 사용자에게 속한 리소스에 대한 접근 권한을 얻을 수 있을 때 발생한다. 예를 들어 직원이 자신의 고용 및 급여 기록에만 접근할 수 있어야 하지만 실제로는 다른 직원의 기록에도 접근할 수 있는 경우 이는 Horizontal privilege escalation 이다.
Horizontal privilege escalation attack은 Vertical privilege escalation과 유사한 유형의 익스플로잇을 사용할 수 있다. 예를 들어 사용자는 일반적으로 다음과 같은 URL을 사용하여 자신의 계정 페이지에 접근할 수 있다.
https://insecure-websilte.com/myaccount?id=123이제 공격자가 id 파라미터 값을 다른 사용자의 값으로 수정하면 공격자는 관련 데이터 및 기능이 있는 다른 사용자의 계정 페이지에 대한 접근 권한을 얻을 수 있다.
일부 application에서는 exploit가능한 파라미터 값을 예측할 수 없다. 예를 들어 application은 증가하는 숫자 대신 GUID(Globally Unique Identifier)를 사용하여 사용자를 식별할 수 있다. 여기서 공격자는 다른 사용자의 식별자를 추측하거나 예측하지 못한다. 그로나 다른 사용자에게 속한 GUID는 사용자 메시지 또는 리뷰와 같이 사용자가 참조되는 application의 다른 위치에서 공개될 수 있다.
경우에 따라 application은 사용자가 리소스에 접근할 수 없는 때를 감지하고 로그인 페이지로 리디렉션을 반환한다. 그러나 리디렉션을 포함하는 응답에는 여전히 대상 사용자에 속한 일부 민감한 데이터가 포함될 수 있으므로 공격은 성공한다.
Horizontal to vertical privilege escalation
종종 horizontal privilege escalation 공격은 더 많은 권한을 가진 사용자를 손상시켜 vertical privilege escalation으로 전환될 수 있다. 예를 들어 horizontal privilege escalation을 통해 공격자는 다른 사용자의 암호를 재설장하거나 캡처할 수 있다. 공격자가 관리 사용자를 대상으로 계정을 손상시키면 관리 접근 권한을 얻을 수 있으므로 vertical privilege escalation을 수행할 수 있다.
예를 들어 공격자는 horizontal privilege escalation에 대해 이미 설명한 파라미터 변조 기술을 사용하여 다른 사용자의 계정 페이지에 대한 접근 권한을 얻을 수 있다.
https://insecure-website.com/myaccount?id=456대상 사용자가 application 관리자인 경우 공격자는 관리 계정 페이지에 대한 접근 권한을 얻는다. 이 페이지는 관리자의 암호를 공개하거나 변경 방법을 제공하거나 권한이 있는 기능에 대한 직접 접근을 제공할 수 있다.
