안녕하세요! 👋 오늘은 개발자와 보안 담당자라면 반드시 알아야 할 OWASP Top 10 2021의 대망의 1위, 깨진 접근 통제 (Broken Access Control)에 대해 쉽고 자세하게 알아보겠습니다. 2017년 5위에서 1위로 껑충 뛰어오른 만큼, 정말 중요하고 흔하게 발견되는 취약점이니 꼭 집중해 주세요!

🤔 접근 통제? 그게 뭔가요?
가장 쉽게 비유하자면, '열쇠'와 같아요. 🔑
- 집주인: 모든 방에 들어갈 수 있는 마스터키를 가집니다. (관리자)
- 가족: 자기 방과 거실, 화장실 열쇠를 가집니다. (일반 사용자)
- 외부인: 어떤 열쇠도 없어서 집에 들어올 수 없습니다. (인증되지 않은 사용자)
이처럼 접근 통제(Access Control)는 사용자가 누구인지, 그리고 그 사용자가 어떤 권한을 가지고 있는지 확인해서 허용된 작업만 수행하도록 제어하는 보안의 핵심 원칙입니다. 즉, "당신은 이 문을 열 수 있습니다" 또는 "당신은 이 버튼을 누를 수 없습니다"를 결정하는 시스템이죠.
'깨진 접근 통제'는 바로 이 열쇠 시스템이 고장 난 상태를 말합니다. 외부인이 내 방에 마음대로 들어오거나, 일반 사용자가 관리자만 접근해야 하는 비밀 공간에 들어가는 끔찍한 상황이 발생하는 거죠. 😱
🚨 왜 1위가 되었을까요?
OWASP에 따르면, 분석된 애플리케이션의 94%에서 어떤 형태로든 깨진 접근 통제 취약점이 발견되었다고 해요. 거의 모든 웹 애플리케이션이 이 문제에 노출되어 있다는 뜻이죠. 사용자 인증(로그인) 기능은 잘 만들지만, 로그인 이후에 각 사용자의 권한을 페이지마다 꼼꼼하게 확인하는 로직을 놓치는 경우가 많기 때문입니다.
🕵️♀️ 깨진 접근 통제의 대표적인 유형들
어떤 경우에 접근 통제가 '깨졌다'고 말할 수 있을까요? 대표적인 사례들을 통해 알아보겠습니다.
1. 불안정한 직접 객체 참조 (IDOR - Insecure Direct Object References)
가장 흔하고 직관적인 유형입니다. URL 주소나 파라미터에 있는 단순한 숫자(ID)를 바꿔서 다른 사람의 정보에 접근하는 공격이에요.
- 공격 시나리오 🧑💻
- 해커가 자신의 게시글을 확인합니다. URL이 https://example.com/posts?id=100 입니다.
- 호기심이 생긴 해커는 URL의 id 값을 101로 바꿔서 요청합니다. (https://example.com/posts?id=101)
- 서버에서 이 요청이 정당한 사용자의 요청인지 확인하지 않으면, 101번 게시글(다른 사람의 비공개 글)이 그대로 노출됩니다!
2. 권한 상승 (Privilege Escalation)
사용자가 원래 가지고 있던 권한보다 더 높은 권한을 획득하는 경우입니다. 크게 두 가지로 나뉩니다.
- 수직적 권한 상승 (Vertical Privilege Escalation) 👩💼 ➡️ 👑
- 일반 사용자가 관리자(Admin) 권한을 얻는 경우입니다.
- 예시: 관리자 페이지 URL(https://example.com/admin)을 알아내서 직접 접속했는데, 권한 검사를 하지 않아서 관리자 페이지가 그대로 열리는 상황입니다.
- 수평적 권한 상승 (Horizontal Privilege Escalation) 👤 ➡️ 👤
- 같은 등급의 다른 사용자 정보에 접근하는 경우입니다.
- 예시: 위에서 설명한 IDOR가 대표적인 수평적 권한 상승 공격입니다. user/123에서 user/124로 접속해 다른 사용자의 정보를 보는 것이죠.
3. 기능 수준의 접근 통제 누락
사용자 인터페이스(UI)에서는 특정 버튼이나 메뉴를 숨겨서 접근을 막았지만, 서버에서는 해당 기능에 대한 접근을 막지 않은 경우입니다.
- 공격 시나리오 😈
- 일반 사용자에게는 '사용자 삭제' 버튼이 보이지 않습니다.
- 하지만 해커는 개발자 도구를 통해 '사용자 삭제' 기능의 API 주소(https://example.com/api/deleteUser?id=50)를 알아냅니다.
- 이 주소를 직접 호출했을 때, 서버가 요청한 사용자가 관리자인지 확인하지 않으면 50번 사용자는 그대로 삭제됩니다.
🛡️ 어떻게 막을 수 있을까요? (방어 방법)
깨진 접근 통제를 막기 위한 핵심 원칙은 간단합니다. "아무도 믿지 말고, 모든 요청을 의심하라!"
- 기본적으로 모두 거부 (Deny by Default) 🔒 가장 중요한 원칙입니다. 특정 권한을 명시적으로 허용하기 전까지는 모든 접근을 기본적으로 차단해야 합니다. 화이트리스트 방식이라고 생각하면 쉽습니다.
- 중앙화된 접근 통제 로직 구현 ⚙️ 권한 검사 로직을 여기저기 흩어놓으면 실수가 발생하기 쉽습니다. 한곳에서 권한을 관리하고, 모든 요청이 이 중앙화된 로직을 통과하도록 설계해야 합니다.
- 서버에서! 모든 요청에 대해! 권한 검사 🖥️✔️ 사용자 눈에 보이는 화면(클라이언트)에서 무언가를 숨기는 것은 아무 의미가 없습니다. 모든 요청이 서버에 도달했을 때, 해당 사용자가 이 작업을 수행할 자격이 있는지 반드시 서버 측에서 다시 확인해야 합니다.
- 최소 권한의 원칙 (Principle of Least Privilege) 사용자에게 꼭 필요한 최소한의 권한만 부여하세요. 일반 사용자에게 관리자 기능에 접근할 권한을 줄 필요는 전혀 없습니다.
- 추측하기 어려운 ID 사용 1, 2, 3과 같이 순차적인 숫자 ID 대신, a1b2c3d4-e5f6-.... 와 같은 복잡하고 추측하기 어려운 UUID(Universally Unique Identifier)를 사용하면 IDOR 공격을 훨씬 어렵게 만들 수 있습니다.
✨ 마치며
깨진 접근 통제는 아주 사소한 실수에서 비롯되지만, 그 결과는 개인정보 유출부터 시스템 장악까지 매우 치명적일 수 있습니다. '이 정도는 괜찮겠지'라는 안일한 생각이 가장 큰 적입니다.
오늘부터라도 내가 만드는 기능에 대해 "이 요청을 보낸 사용자가 정말 이 작업을 할 권한이 있는가?"를 항상 스스로에게 질문하는 습관을 들여보는 것은 어떨까요? 안전한 웹 세상을 만드는 첫걸음이 될 것입니다!
'일반IT > IT보안' 카테고리의 다른 글
| 💉 당신의 애플리케이션을 감염시키는 치명적인 공격, 인젝션(Injection) 파헤치기 (0) | 2025.09.29 |
|---|---|
| 🔐 내 비밀번호는 안전할까? OWASP 2위, 암호화 실패 파헤치기 (0) | 2025.09.29 |
| 🔗 n8n으로 SecOps 자동화, 복잡한 워크플로를 코딩 없이! 🚀 (1) | 2025.09.20 |
| 🚨 끝없는 경보와의 사투: SecOps의 3대 핵심 과제와 해결책 (0) | 2025.09.20 |
| 🤖 당신의 코딩 부사수, GPT Codex 완벽 가이드: API 키 발급부터 실제 활용까지! (1) | 2025.09.16 |