웹 인증 보안에서 계정 열거와 MFA, 세션 상태 전이가 중요한 까닭은, 공격자가 단순한 비밀번호 대입을 넘어 응답의 미세한 차이로 사용자 존재 여부를 확인하고 인증 단계 사이의 논리적 허점을 이용해 권한을 획득하기 때문입니다.
웹 인증 취약점, 왜 ‘흐름’으로 봐야 하는가
많은 개발자와 보안 담당자가 개별 인증 엔드포인트의 입력값 검증에 집중하지만, 정작 치명적인 취약점은 전체 인증 상태 머신(State Machine)의 흐름에서 발생합니다. 인증 프로세스는 단순히 ‘로그인 성공/실패’의 이분법적 구조가 아니라 여러 단계의 상태 전이 과정으로 이해해야 합니다.
예를 들어 OTP 기반 인증은 ‘사용자명+비밀번호 입력 $\rightarrow$ OTP 챌린지 $\rightarrow$ OTP 검증 $\rightarrow$ 인증된 세션 생성’이라는 연속적인 상태 전이 과정으로 구성됩니다. 이때 보안의 핵심은 서버가 믿고 있는 사용자의 인증 상태와 실제 사용자의 상태가 일치하는지 확인하는 것입니다. 단순한 페이로드 기반 테스트만으로는 발견하기 어려운 비즈니스 로직상의 취약점은 바로 이 상태 전이 지점을 집중적으로 시험할 때 드러납니다.
계정 열거: 오류 메시지·응답 코드·응답 시간이 새는 이유
계정 열거(Account Enumeration) 테스트의 목적은 인증 메커니즘과 상호작용하면서 유효한 사용자명 집합을 수집할 수 있는지 확인하는 것입니다. 공격자는 서비스가 내놓는 다양한 신호로 특정 계정의 존재 여부를 가려냅니다.
1. 응답의 불일치 신호
유효한 사용자와 무효한 사용자를 가르는 신호는 매우 다양합니다.
- 메시지 및 문자열: “존재하지 않는 계정입니다”와 “비밀번호가 틀렸습니다”의 차이.
- HTTP 상태 코드: 동일한 오류 페이지를 보여주더라도 성공 시 200, 실패 시 403 등의 코드를 반환해 정보를 유출하는 경우.
- 물리적 차이: 응답의 길이(Response Length), JSON 필드의 구성, 리다이렉트 경로의 차이.
2. 타이밍 기반 공격(Time-based Attack)
비즈니스 로직 처리 시간의 차이 또한 결정적인 단서가 됩니다. 사용자가 없을 때 즉시 에러를 반환하는 ‘Quick Exit’ 구현과, 사용자가 있을 때 해시 함수로 비밀번호를 비교하는 과정의 시간 차이는 공격자가 계정의 유효성을 판단하는 근거가 됩니다.
그래서 로그인, 비밀번호 재설정, 복구 등 어떤 인증 메커니즘에서든 계정의 존재 여부나 잠금 상태와 관계없이 동일한 범용 오류 메시지를 돌려주는 일반화된 응답 전략이 필수입니다.
MFA·OTP 상태 전이 취약점: 어느 단계에서 뚫리는가
다중 인증(MFA)은 비밀번호 관련 공격에 대한 방어 수단으로 효과가 큽니다. 마이크로소프트 분석에 따르면 계정 침해의 99.9%를 막는다고 합니다. 다만 MFA 구현 로직 자체에 결함이 있으면 무용지물이 됩니다.
OTP 처리의 최소 보안 요건
안전한 OTP를 구현하려면 다음 기준을 충족해야 합니다.
- 짧은 TTL(Time-to-Live): 유효 시간을 최소한으로 설정해 탈취된 코드의 사용 가능 시간을 제한합니다.
- 단일 사용(Single-use): 한 번 검증된 코드는 그 즉시 무효화해 재사용을 막습니다.
- 엄격한 시도 한도: 브루트포스 공격에 대비해 입력 횟수에 제한을 둡니다.
- 성공 후 무효화: 검증이 성공하는 즉시 해당 OTP를 폐기합니다.
상태 전이 우회 점검 항목
MFA 로직을 테스트할 때 봐야 할 대상은 개별 엔드포인트가 아니라 전체 흐름의 우회 가능성입니다.
| 점검 항목 | 공격 시나리오 및 핵심 확인 사항 |
|---|---|
| 단계 건너뛰기(Step Skipping) | OTP 검증 단계를 생략하고 인증된 기능(Authenticated Functionality)에 직접 접근 가능한지 확인 |
| OTP 재사용 | 이전의 OTP 또는 이미 사용된 OTP를 다시 사용하여 인증을 통과할 수 있는지 점검 |
| 식별자 조작 | 인증 흐름 중간에 계정 식별자를 변경하여 타인의 계정으로 인증 세션을 획득하는지 확인 |
| 요청 조작 및 우회 | 검증 요청 파라미터를 조작하거나 레이트 리밋(Rate Limiting)을 우회하여 OTP를 무차별 대입하는지 점검 |
비밀번호 재설정 토큰 흐름과 상태 우회
비밀번호 재설정 과정은 단순한 폼 입력이 아니라 ‘재설정 요청 $\rightarrow$ 토큰 수신 $\rightarrow$ 토큰 검증 $\rightarrow$ 새 비밀번호 설정 $\rightarrow$ 로그인’으로 이어지는 전체 상태 흐름으로 분석해야 합니다.
토큰 보안 기준
재설정 토큰이나 코드는 암호학적으로 안전한 알고리즘으로 랜덤하게 생성해야 합니다. 브루트포스 공격을 방지할 수 있을 만큼 길이도 충분해야 하고, 단일 사용만 허용되며 적절한 기간이 지나면 만료됩니다.
로직 취약점 및 가용성 이슈
토큰의 예측 가능성, 사용자-토큰 바인딩 오류, 필수 단계 우회 여부를 확인하는 것이 중요합니다. 한편 보안을 위해 도입한 계정 잠금 정책은 오히려 가용성 문제를 일으킬 수 있습니다. 비밀번호 재설정 흐름에서 공격 탓에 계정이 잠기면 실제 사용자가 서비스에서 밀려나는 결과로 이어지므로 주의가 필요합니다.
세션 상태 전이: 재인증, 세션 무효화, 토큰 회전
인증 후 생성되는 세션 식별자는 추측 공격을 막으려면 최소 64비트의 엔트로피(2^64개의 가능한 값)를 확보해야 합니다. 세션 토큰이 인코딩되어 있더라도 이는 구조 파악을 위한 수단일 뿐이고, 디코딩이 가능하다고 해서 그 자체가 곧바로 취약점이 되는 것은 아닙니다.
보안성이 높은 세션 관리를 위해 OWASP는 다음 메커니즘을 권고합니다.
- 재인증 요구: 계정 복구나 비밀번호 재설정 등 고위험 활동이 발생했을 때 다시 인증을 거치도록 설계합니다.
- 세션 무효화 및 토큰 회전(Rotate): 재인증 후에는 이전 세션을 즉시 무효화하고 새로운 토큰을 발행해 세션 하이재킹 위험을 줄입니다.
결론: 공격 체인(Attack Chain)의 관점
웹 인증 취약점은 단독으로 있을 때보다 다른 취약점과 연결될 때 훨씬 위험해집니다. 호스트 헤더 취약점이 비밀번호 재설정 포이즈닝으로 이어져 계정 탈취로 연결되거나, XSS 취약점이 세션 침해로 계정 탈취로 이어지는 사례가 대표적입니다.
인증 로직을 설계하거나 점검할 때는 개별 기능의 무결성뿐 아니라 전체 인증 상태 머신의 전이 과정과 잠재적인 공격 체인을 함께 고려하는 분석적 접근이 필요합니다.