인증·인가·세션 취약점
계정 공격과 세션 고정·탈취, 객체 권한 검사의 차이를 익힙니다.
1. 인증·세션·인가의 차이
| 통제 | 질문 |
|---|---|
| 인증 | 누구인지 확인했는가? |
| 세션 | 인증 결과를 다음 요청과 안전하게 연결하는가? |
| 인가 | 이 사용자가 이 객체에 이 동작을 수행해도 되는가? |
사용자 A가 로그인 후 사용자 B의 주문을 볼 수 있다면 로그인 성공 여부보다 객체 인가를 확인해야 한다. 인증 성공은 모든 기능의 사용 허가가 아니다.
인증 실패는 인증이 성공하지 않은 결과를 뜻하며 정상적인 거부일 수도 있다. 인증 취약점은 올바른 절차를 우회하거나 다른 사용자의 인증정보를 악용할 수 있게 하는 결함이다. 두 표현을 혼용하지 않는다.
2. 반복 로그인 공격과 비밀번호 보호
| 유형 | 특징 |
|---|---|
| 무차별 대입(Brute Force) | 비밀번호 후보를 반복하여 추측 |
| Credential Stuffing | 다른 서비스에서 유출된 ID·비밀번호 조합 재사용 |
| Password Spraying | 흔한 소수 비밀번호를 많은 계정에 시도 |
계정·IP 등을 고려한 시도 제한, 지연, 비정상 패턴 탐지, 다중요소 인증을 조합한다. 강제 잠금만 사용하면 공격자가 정상 사용자 계정을 반복 잠그는 서비스 거부를 유발할 수 있다.
비밀번호는 충분한 길이와 유출·상용 비밀번호 제한을 고려하고, 서버에는 개별 솔트와 적절한 비용의 비밀번호 해시로 보관한다. 단순 해시 한 번이나 복호화 가능한 저장 방식으로 충분하다고 보지 않는다.
지식(비밀번호), 소유(보안키), 생체(지문)처럼 서로 다른 요소를 조합하는 것이 MFA다. 비밀번호와 보안질문처럼 지식 요소 두 개를 요구하는 것만으로 MFA가 되지는 않는다.
3. 계정 열거와 복구 경로
‘등록되지 않은 계정’과 ‘비밀번호 오류’처럼 외부 응답을 세분화하면 계정 존재 여부를 추측할 단서가 생긴다. 외부에는 불필요한 차이를 줄이되 내부 로그에서는 실패 이유와 반복 시도를 구분한다.
복구 절차도 인증 경계다. 재설정 토큰은 예측하기 어렵게 만들고 짧은 유효시간·일회 사용을 적용한다. 공개적으로 알 수 있는 질문만으로 복구를 허용하지 않고, 비밀번호 변경 후 기존 세션·복구 토큰의 처리도 정한다.
4. 세션 고정과 탈취
세션 고정은 공격자가 미리 아는 세션 ID를 피해자가 로그인 후에도 사용하게 만드는 공격이다. 로그인 전후 신뢰 수준이 바뀌었는데 ID를 교체하지 않는 것이 대표 원인이다.
세션 탈취는 유효한 인증 세션의 비밀값을 획득하여 재사용하는 공격이다. 전송 도청, XSS, 로그 유출 등 원인을 구분해 대응한다.
로그인 전 S1 → 인증 성공 → S1 무효화 + 새 S2 발급
이후 보호 요청은 유효한 S2로만 처리
로그인·권한 상승 시 새 ID를 발급하고 이전 ID를 더 이상 인정하지 않는다. HTTPS와 Secure·HttpOnly·SameSite의 기본 역할은 HTTP·HTTPS·쿠키·세션에서 확인한다. ID 재발급 하나가 모든 탈취 경로를 막지는 않는다.
5. 만료와 로그아웃
- Idle Timeout: 일정 시간 활동이 없으면 종료.
- Absolute Timeout: 활동과 관계없이 전체 유효시간이 지나면 종료·재인증.
- 로그아웃: 서버가 세션을 무효화하고 브라우저 쿠키도 만료.
로그인 화면으로 이동하거나 탭을 닫았다고 서버 세션이 사라지는 것은 아니다. 서버가 만료된 요청을 거부해야 한다. 비밀번호·복구 수단 변경 등 민감한 기능은 세션이 살아 있어도 재인증을 요구할 수 있다.
6. 객체·기능 인가
수평적 권한 상승은 같은 수준의 다른 사용자 데이터에 접근하는 것, 수직적 권한 상승은 일반 사용자가 관리자 기능처럼 상위 권한을 쓰는 것이다.
IDOR·BOLA는 객체 식별자를 받는 기능에서 해당 객체의 권한 검사가 빠지는 문제다. 주문 ID를 숫자에서 UUID로 바꾸어 추측을 어렵게 해도 인가를 대신하지 않는다.
현재 사용자 확인
→ 대상 주문 조회
→ 사용자·대상 주문·수행 동작의 권한 검사
→ 허용된 경우에만 결과 반환·변경
화면 버튼 숨김, 클라이언트 검사, 한 API의 검사만으로 충분하지 않다. 같은 객체를 다루는 웹·모바일·관리자 경로 모두에서 기본 거부와 일관된 서버 측 정책을 적용한다.
개념 확인 문제
문제를 누르면 바로 아래에서 정답과 해설을 확인할 수 있습니다.
01세션 고정을 막기 위해 로그인 성공 시 무엇을 해야 하는가?
공격자가 알 수 있는 로그인 전 세션 ID를 무효화하고 새 ID를 발급한다. 이후 보호 요청에서 이전 ID를 계속 인정해서는 안 된다.
02주문 식별자를 UUID로 바꾸면 IDOR가 해결되는가?
아니다. 추측은 어려워져도 객체 인가 누락은 남는다. 현재 사용자·대상 주문·요청 동작에 대한 권한을 서버에서 검사해야 한다.