🚪"출입금지" 팻말이 무색할 때: OWASP A5:2017 - 취약한 접근 통제(Broken Access Control)

안녕하세요! 👋 웹 보안의 경계를 지키는 여러분, 오늘은 2017년 OWASP Top 10에서 5위를 차지했지만, 2021년에는 무려 1위로 등극한 가장 치명적이고 흔한 취약점, A5: 취약한 접근 통제(Broken Access Control)에 대해 알아보겠습니다.

https://github.com/OWASP-Seoul/owasp/raw/master/OWASP%20Project/OWASP_Top_10-2017-ko.pdf

 

 

"넌 들어올 수 없어!"라고 외쳐야 할 시스템이 제 역할을 못 할 때 어떤 일이 벌어지는지, 그 원인과 해결책을 지금부터 샅샅이 파헤쳐 보겠습니다! 🔑

---

🤔 취약한 접근 통제란 무엇인가요?

접근 통제(Access Control)란, 인증된 사용자가 특정 기능이나 데이터에 접근할 권한이 있는지 확인하고 강제하는 정책입니다. 쉽게 말해 '누가 무엇을 할 수 있는가'를 통제하는 시스템의 경비원이죠. 👮

 

취약한 접근 통제는 바로 이 경비원이 졸거나, 허술해서 아무나 통과시키는 상황을 말합니다. 공격자는 이 허점을 이용해 다른 사용자의 정보를 보거나 수정하고, 관리자만 사용해야 할 기능을 마음대로 실행하는 등 시스템을 농락할 수 있습니다.

인증(Authentication)과 인가(Authorization)의 차이를 알면 이해하기 더 쉽습니다.

• 인증 (Authentication): 당신이 '누구'인지 증명하는 과정 (예: ID/PW로 로그인)
• 인가 (Authorization): 당신이 '무엇을 할 수 있는지' 권한을 부여하고 확인하는 과정 (예: 일반 사용자는 글 읽기만, 관리자는 글쓰기/삭제도 가능)

취약한 접근 통제는 바로 이 '인가' 과정에서 발생하는 문제입니다. 로그인은 성공했지만, 권한 없는 행동을 막지 못하는 것이죠.

---

대표적인 접근 통제 실패 시나리오들

공격자들은 어떤 허술한 경비 시스템을 노릴까요? 가장 대표적인 사례들을 만나보시죠.

1. 불안정한 직접 객체 참조 (IDOR, Insecure Direct Object References)

가장 흔하고 직관적인 접근 통제 취약점입니다. 시스템이 파일, 데이터베이스 키(Key)와 같은 내부 객체에 대한 참조(ID 값 등)를 URL이나 파라미터에 그대로 노출할 때 발생합니다. 공격자는 이 참조 값을 조작하여 다른 사용자의 정보를 탈취할 수 있습니다.

 

예시: 허술한 계좌 조회 페이지 💳

은행 웹사이트에서 제 계좌를 조회하는 URL이 다음과 같다고 가정해 봅시다. https://bank.example.com/account?acct_id=12345

 

여기서 acct_id가 제 계좌 번호입니다. 만약 공격자가 이 파라미터 값을 12346으로 바꾸어 요청을 보냈을 때, 서버가 "이 요청을 보낸 사용자가 12346 계좌의 주인인가?"를 확인하지 않고 그냥 정보를 보여준다면? 다른 사람의 계좌 정보가 그대로 노출되는 심각한 사고가 발생합니다.

 

2. 기능/함수 레벨의 접근 통제 부재

사용자 인터페이스(UI)에서는 관리자 메뉴가 보이지 않더라도, 공격자가 관리자 기능이 실행되는 URL을 직접 추측해서 요청했을 때 서버가 이를 막지 못하는 경우입니다. 눈에 보이는 문만 잠그고, 숨겨진 뒷문은 활짝 열어둔 셈이죠.

 

예시: 숨겨진 관리자 페이지 ⚙️

일반 사용자에게는 관리자 페이지로 가는 버튼이 보이지 않습니다. 하지만 공격자가 개발자 도구나 추측을 통해 관리자만 접근 가능한 URL(https://example.com/admin/delete_user?id=100)을 알아내 직접 접속을 시도합니다. 이때 서버가 요청자의 권한을 확인하지 않으면, 공격자는 다른 사용자를 삭제하는 관리자 기능을 실행할 수 있게 됩니다.

 

3. 경로 조작 (Path Traversal)

사용자가 입력한 파일 이름이나 경로를 제대로 검증하지 않아, 공격자가 시스템의 다른 경로에 있는 파일에 접근하는 취약점입니다. ../ 와 같은 상위 디렉터리 이동 문자를 이용해 접근이 제한된 영역의 파일을 읽거나 실행할 수 있습니다.

 

예시: 이미지 로딩 기능의 허점 🖼️

웹사이트가 사용자가 요청한 이미지 파일을 보여주는 URL이 다음과 같다고 가정합시다. https://example.com/show_image?file=user_pic.jpg

 

공격자가 file 파라미터에 ../../../../etc/passwd 와 같은 값을 입력하면, 서버가 이 경로를 필터링하지 않고 그대로 처리하여 시스템의 민감한 파일을 노출시킬 수 있습니다.

---

🛡️ 철통같은 접근 통제 시스템 만들기 (대응 방안)

그렇다면 어떻게 해야 이 허술한 경비 시스템을 철통같이 만들 수 있을까요?

1. 기본적으로 모든 것을 거부하라 (Deny by Default)

가장 중요한 원칙입니다. 특정 역할이나 사용자에게 명시적으로 접근을 허용한 리소스 외에는 기본적으로 모든 접근을 차단해야 합니다. 화이트리스트 방식으로, 꼭 필요한 권한만 하나씩 부여해야 합니다.

2. 서버 측에서, 한 번 더! (Server-Side Enforcement)

클라이언트(브라우저)에서 버튼을 숨기거나 비활성화하는 것은 아무 소용이 없습니다. 공격자는 프록시 툴을 이용해 클라이언트의 제약을 얼마든지 우회할 수 있습니다. 모든 접근 통제 로직은 반드시 서버 측에서, 모든 요청에 대해 빠짐없이 검사하고 강제되어야 합니다.

3. 최소 권한의 원칙 (Principle of Least Privilege)

사용자, 프로세스, 시스템에는 업무를 수행하는 데 필요한 최소한의 권한만 부여해야 합니다. 일반 사용자에게 관리자 권한을 줄 필요가 없고, 읽기만 필요한 기능에 쓰기/삭제 권한을 부여해서는 안 됩니다.

4. 간접 객체 참조 맵핑 (Indirect Object Reference Map)

IDOR 공격을 막기 위해, 데이터베이스의 실제 ID(1, 2, 3...)를 URL에 직접 노출하는 대신, 사용자 세션마다 각 객체에 대한 **간접적인 참조 값(예: 무작위 문자열이나 숫자)**을 맵핑하여 사용하는 것이 안전합니다.

 

안전한 예시: https://bank.example.com/account?acct_ref=aXb2CdeF 서버는 aXb2CdeF라는 참조 값이 현재 로그인한 사용자의 것인지 확인한 후, 실제 ID와 맵핑하여 데이터를 조회합니다.

---

2021년 OWASP Top 10에서 취약한 접근 통제가 1위로 올라선 것은, 이 취약점이 얼마나 만연하고 또 얼마나 치명적인지를 명백히 보여줍니다. 기능 개발에 집중하다 보면 권한 검증 로직을 놓치기 쉽지만, 보안의 가장 기본은 '허가된 자에게만 허가된 행동을 허용하는 것'임을 절대 잊지 말아야 합니다.