인증/인가 취약점

인증(Authentication)이란 무엇인가?

인증(Authentication)이란 사용자가 주장하는 신원이 실제로 그 사용자 본인이 맞는지를 확인하는 과정이다.

웹사이트는 인터넷에 연결된 누구에게나 접근 가능하므로, 공격자 또한 언제든지 접근을 시도할 수 있다. 따라서 강력하고 안전한 인증 메커니즘은 웹 보안에서 매우 중요한 요소가 된다.

일반적으로 인증은 다음과 같은 세 가지 요소(Factor)를 기반으로 이루어진다.

1. 사용자가 알고 있는 정보 (Something you know)

사용자만 알고 있는 정보를 이용하는 방식이다.

대표적인 예시는 다음과 같다.

• 비밀번호(password)
• 보안 질문의 답변(security question answer)

이러한 방식은 지식 기반 인증(Knowledge Factor)이라고도 한다.

2. 사용자가 소유한 것 (Something you have)

사용자가 실제로 물리적으로 소유하고 있는 장치를 통해 인증하는 방식이다.

대표적인 예시는 다음과 같다.

• 휴대전화
• OTP 토큰
• 보안 키(Security token)

이러한 방식은 소유 기반 인증(Possession Factor)이라고 부른다.

3. 사용자의 고유한 특성 (Something you are or do)

사용자의 생체 정보나 행동 패턴을 기반으로 인증하는 방식이다.

대표적인 예시는 다음과 같다.

• 지문
• 얼굴 인식
• 홍채 인식
• 타이핑 패턴 등의 행동 기반 인증

이러한 방식은 생체 기반 인증(Inherence Factor)이라고 한다.

인증 메커니즘(Authentication Mechanisms)

실제 웹 서비스에서는 위에서 설명한 인증 요소 중 하나 이상을 조합하여 사용자의 신원을 확인한다.

ex:

• 아이디 + 비밀번호
• 비밀번호 + OTP
• 지문 + PIN

과 같은 방식으로 여러 인증 요소를 결합하여 보안을 강화할 수 있다.

이러한 방식은 일반적으로 다중 요소 인증(MFA, Multi-Factor Authentication)이라고 불린다.

인증(Authentication)과 인가(Authorization)의 차이

웹 보안에서는 Authentication(인증)과 Authorization(인가)를 명확히 구분해야 한다.

구분 의미

Authentication (인증)	사용자가 실제로 누구인지 확인하는 과정
Authorization (인가)	해당 사용자가 특정 행동을 할 권한이 있는지 확인하는 과정

 

예시

어떤 사용자가 mikle이라는 아이디로 웹사이트에 로그인하려고 한다고 가정해 보자.

1. 인증(Authentication)

시스템은 로그인 요청을 받은 후, mikle이라는 계정을 만든 실제 사용자 본인이 맞는지 확인한다.

2. 인가(Authorization)

인증이 완료된 이후에는,

해당 사용자가 어떤 기능을 수행할 수 있는지 권한을 확인한다.

예를 들어 다음과 같은 권한이 있을 수 있다.

• 다른 사용자의 개인정보 조회
• 관리자 기능 사용
• 다른 사용자의 계정 삭제

즉,

인증(Authentication)은 “누구인가?”를 확인하는 과정이고, 인가(Authorization)는 “무엇을 할 수 있는가?”를 결정하는 과정이다.

헌국인터넷진흥원

인증 취약점 주요 발생 원인

인증 메커니즘에서 발생하는 대부분의 취약점은 크게 두 가지 원인으로 발생한다.

1. 인증 메커니즘 자체가 약한 경우

인증 시스템이 무차별 대입 공격(Brute-force attack)에 대해 충분한 방어 기능을 갖추지 못한 경우 취약점이 발생할 수 있다.

예를 들어 다음과 같은 상황이 해당된다.

• 로그인 시도 횟수 제한이 없는 경우
• CAPTCHA 등의 자동화 공격 방지 장치가 없는 경우
• 비밀번호 정책이 지나치게 약한 경우
• 계정 잠금(account lockout) 기능이 없는 경우

이러한 경우 공격자는 자동화 도구를 이용해 수많은 비밀번호를 반복적으로 시도하여 계정을 탈취할 수 있다.

1. 인증 로직의 설계 오류 또는 구현 오류

인증 기능을 구현하는 과정에서 논리적 결함(logic flaw)이나 코딩 실수가 존재하면 공격자가 인증 절차를
완전히 우회(bypass)할 수 있다.

이러한 유형의 취약점을 일반적으로 Broken Authentication(깨진 인증)이라고 부른다.

웹 개발 전반에서 논리적 결함은 종종 웹사이트가 예상과 다른 방식으로 동작하게 만들지만, 반드시 보안 문제가 되는 것은 아니다.

그러나 인증(Authentication)은 보안의 핵심 요소이기 때문에, 인증 로직에 결함이 존재할 경우 높은 확률로 심각한 보안 취약점으로 이어질 가능성이 크다.

취약한 인증이 미치는 영향

1. 일반 사용자 계정이 탈취된 경우

공격자는 다음과 같은 정보를 획득할 수 있다.

• 개인정보
• 사용자 메시지
• 서비스 이용 기록
• 내부 시스템 접근 페이지

또한 해당 계정을 이용해 추가적인 공격을 수행할 수도 있다.

2. 관리자 계정이 탈취된 경우

만약 공격자가 관리자(System Administrator)와 같은 높은 권한의 계정을 탈취한다면 상황은 훨씬 심각해진다.

이 경우 공격자는 다음과 같은 행위를 할 수 있다.

• 전체 애플리케이션 제어
• 사용자 계정 관리
• 데이터베이스 접근
• 내부 시스템 접근

심지어 내부 인프라(internal infrastructure)까지 접근할 가능성도 있다.

인가 취약점(Authorization Vulnerabilities)이란?

인가 취약점이란 사용자가 자신의 권한 범위를 넘어 허용되지 않은 데이터나 기능에 접근할 수 있는 보안 취약점을 의미한다.

즉, 시스템이 사용자의 권한을 제대로 검증하지 못하는 경우 발생한다.

인가 취약점은 일반적으로 다음과 같은 상황에서 발생한다.

1. 권한 검증이 제대로 이루어지지 않는 경우

웹 애플리케이션이 특정 요청을 처리할 때 사용자의 권한을 확인하지 않으면 누구나 해당 기능을 사용할 수 있게 된다.

예를 들어 다음과 같은 상황이 있다.

• 일반 사용자가 관리자 페이지에 접근 가능
• 사용자 계정 관리 기능을 누구나 호출 가능
• 관리자 API가 권한 검증 없이 동작

이 경우 공격자는 단순히 URL을 직접 입력하거나 요청을 조작하여 관리자 기능을 실행할 수 있다.

2. 직접 객체 참조(IDOR, Insecure Direct Object Reference)

웹 애플리케이션이 사용자 입력을 통해 내부 리소스를 직접 참조하는 경우 인가 취약점이 발생할 수 있다.

예를 들어 다음과 같은 요청이 있다고 가정하자.

/account?id=123

이 경우 시스템이 사용자 권한 검증 없이 id 값만으로 데이터를 조회한다면, 공격자는 다음과 같이 요청을 변경할 수 있다.

/account?id=124

이렇게 하면 다른 사용자의 계정 정보에 접근할 수 있게 된다.

이러한 유형의 취약점은 IDOR(Insecure Direct Object Reference)라고 불리며, 웹 애플리케이션에서 매우 흔하게 발생하는 인가 취약점이다.

3. 권한 상승(Privilege Escalation)

사용자가 원래 가진 권한보다 더 높은 권한을 획득하는 경우를 권한 상승이라고 한다.

권한 상승은 크게 두 가지 유형으로 나뉜다.

수직 권한 상승 (Vertical Privilege Escalation)

일반 사용자가 관리자 권한을 획득하는 경우이다.

ex:

/admin/deleteUser?id=10

위와 같은 관리자 기능을 일반 사용자가 호출할 수 있다면 수직 권한 상승 취약점이 발생한다.

수평 권한 상승 (Horizontal Privilege Escalation)

같은 권한 수준의 다른 사용자 데이터에 접근하는 경우이다.

ex:

/myaccount?id=123

사용자가 자신의 계정 대신 다른 사용자의 ID를 입력하여 다른 사용자 정보에 접근할 수 있다면 수평 권한 상승 취약점이 발생한다.

 

취약한 인가가 미치는 영향

인가 취약점 역시 매우 심각한 보안 문제를 초래할 수 있다.

공격자가 인가 취약점을 악용할 경우 다음과 같은 공격이 가능하다.

1. 다른 사용자 데이터 접근

공격자는 다음과 같은 정보를 조회할 수 있다.

• 개인정보
• 주문 내역
• 결제 정보
• 기업 내부 데이터

이로 인해 개인정보 유출이나 기업 기밀 정보 유출이 발생할 수 있다.

2. 관리자 기능 악용

만약 공격자가 관리자 기능에 접근할 수 있다면 다음과 같은 행위가 가능하다.

• 사용자 계정 삭제
• 권한 변경
• 시스템 설정 변경
• 데이터 삭제

이 경우 공격자는 서비스 전체를 조작하거나 마비시킬 수 있다.

3. 추가 공격 수행

인가 취약점을 통해 내부 페이지에 접근하게 되면 공격자는 다음과 같은 추가 공격을 수행할 수 있다.

• SQL Injection
• File Upload 취약점 악용
• 내부 API 접근
• 시스템 설정 변경

이처럼 인가 취약점은 단독으로도 위험하지만, 다른 취약점과 결합되어 더 큰 보안 사고로 이어질 가능성이 높다.

정리

웹 보안에서 인증과 인가는 서로 다른 개념이며, 다음과 같이 구분된다.

• Authentication : 사용자의 신원을 확인하는 과정
• Authorization : 사용자의 권한을 확인하는 과정

웹 서비스는 일반적으로 먼저 인증을 수행한 뒤, 이후에 인가 과정을 통해 사용 가능한 기능을 제한한다.

이러한 구조를 통해 웹 서비스는 사용자 계정 보호와 권한 관리라는 두 가지 보안 목적을 동시에 달성할 수 있다.

인증 취약점

인증 취약점은 크게 다음 두 가지 원인으로 발생한다.

1. 약한 인증 메커니즘
   • Brute-force 공격 방어 부족
2. 인증 로직의 구현 오류
   • Broken Authentication

이러한 취약점이 존재할 경우 공격자는

• 사용자 계정 탈취
• 관리자 권한 획득
• 내부 시스템 접근
• 추가 공격 수행

과 같은 심각한 보안 문제를 일으킬 수 있다.

인가 취약점

인가 취약점은 사용자의 권한 검증이 제대로 이루어지지 않을 때 발생하는 보안 문제이다.

대표적인 유형은 다음과 같다.

• 권한 검증 누락
• IDOR(Insecure Direct Object Reference)
• 수직 권한 상승
• 수평 권한 상승

인가 취약점이 존재할 경우 공격자는

• 다른 사용자 데이터 접근
• 관리자 기능 악용
• 내부 시스템 접근

등의 공격을 수행할 수 있으며, 이는 웹 애플리케이션 전체 보안에 심각한 영향을 미칠 수 있다.

 

인증 취약점 대응방안

사용자 인증 정보 보호에 유의할 것

유효한 로그인 자격 증명을 공격자에게 의도치 않게 노출한다면 그 모든 보안은 무의미해진다.

• 로그인 정보는 당연히 암호화되지 않은 연결을 통해 전송되어서는 안 된다. 로그인 요청에 HTTP 요청이 시도될 경우 이를
  반드시 HTTPS로 리다이렉트하도록 강제해야 한다.
• 웹사이트를 점검하여 사용자 이름이나 이메일 주소가 공개 프로필이나 HTTP 응답에 반영되는 등의 방식으로 외부에 노출되지 않도록 해야 한다.

사용자에게 보안을 의존하지 말 것

가능한 한 모든 영역에서 안전한 사용자 행동이 강제되도록 설계한다.

• 효과적인 비밀번호 정책을 구현 : 전통적인 비밀번호 정책은 사용자가 예측 가능한 패턴의 비밀번호를 억지로 맞춰 사용하는 경우가 많아 실효성이 떨어질 수 있다.
• 사용자가 다양한 비밀번호를 시도해 볼 수 있도록 하고 그 강도를 실시간으로 피드백해 주는 간단한 비밀번호 검사기를 도입
  • ex: Dropbox에서 개발한 JavaScript 라이브러리 zxcvbn.
    비밀번호 검사기를 통해 높은 점수를 받은 비밀번호만 사용하도록 제한하면, 기존의 전통적인 정책보다 훨씬 효과적으로 안전한 비밀번호 사용을 유도

브루트포스 공격 방어

• 일정 횟수 이상 로그인 실패 시 계정을 잠금하거나 임시로 차단하여 무차별 대입 공격 및 사전 공격(Dictionary Attack)을 방지한다.
• 일정 횟수 이상의 로그인 시도가 발생할 경우, 사용자가 CAPTCHA 인증을 수행하도록 요구한다.

이와 같은 방법이 브루트포스 공격을 완전히 차단할 수 있는 것은 아니다. 그러나 공격 과정을 최대한 번거롭고 수동적으로 만들면, 공격자가 시도를 포기하고 보다 취약한 다른 대상로 이동할 가능성을 높일 수 있다.

다중 인증(MFA/2FA) 도입

아이디와 비밀번호 외에 OTP, 생체 인증, SMS 인증 등 추가적인 인증 수단을 강제하여 단일 인증 수단 무력화에 대비한다.

 

인가 취약점 대응방안

최소 권한 원칙(Least Privilege) 적용

• 사용자에게 업무 수행에 필요한 최소한의 권한만을 부여하며, 기본적으로 모든 접근을 차단(Deny All)한 후 필요한 권한만 명시적으로 허용한다.

서버 측 권한 검증 강제

• 클라이언트에서 전달되는 파라미터(예: user_id, role)를 신뢰하지 않고, 모든 요청에 대해 현재 세션 사용자가 해당 리소스를 처리할 권한이 있는지 서버에서 매번 확인한다.

간접 객체 참조 활용

• 데이터베이스의 기본 키(PK) 컬럼이나 실제 파일 경로(이미지 등)를 URL 파라미터로 직접 노출하는 대신,
  임의의 맵핑 값이나 난수화된 식별자를 사용하여 사용자가 값을 변조하여 타인의 자원에 접근하는 것을 차단한다.

객체 수준의 접근 제어(RBAC/ABAC):

역할 기반(Role-Based) 또는 속성 기반(Attribute-Based) 접근 제어 모델을 도입하여 체계적이고 일관된 권한 관리 구조를 유지한다.

• 역할 기반 접근 제어 (RBAC) : 사용자의 직무나 직책에 따라 정해진 역할(Role)을 부여하고, 그 역할에 허용된 권한을 할당하는 방식
  • 사용자를 개별적으로 관리하는 대신 '관리자', ' 일반 사용자', '회계 담당자' 등과 같은 그룹(역할)에 권한을 묶어 관리
• 속성 기반 접근 제어 (ABAC) : 사용자, 자원, 환경 등 다양한 속성(Attribute)들의 조합을 논리적으로 판단하여 접근 여부를 결정하는 방식
  • "누가(사용자 속성), 어떤 데이터에(자원 속성), 어디서/언제(환경 속성), 무엇을(행위 속성)" 하려는지에 대한 정책(Policy)을 기반으로 권한을 부여
  • IF (사용자.부서 == '보안' AND 자원.보안등급 == '기밀' AND 접속시간 == '업무시간') THEN 허용

IDOR 방지

고유ID(ex: id=100)를 직접 노출하는 것이 아니라, 예측 불가능한 암호회된 토큰을 사용하거나,

해당 ID가 현재 세션 정보에 등록된 사용자의 것인지 확인한다.