세션 고정(Session Fixation)이란?
세션 고정은 세션 식별자 관리의 실패를 악용하여 공격자가 정상 사용자의 세션을 탈취할 수 있게 하는 웹 애플리케이션 취약점입니다. 핵심 결함은 단순합니다. 사용자가 인증할 때 애플리케이션이 새로운 세션 ID를 할당하지 않는 경우입니다. 즉, 공격자가 인증 전 세션 식별자를 알고 있거나 제어할 수 있다면, 이를 이용해 인증된 세션에 접근하여 마치 정상 사용자처럼 행동할 수 있습니다.
MITRE CWE는 이 취약점을 공식적으로 다음과 같이 정의합니다. "사용자를 인증하거나 새로운 사용자 세션을 설정할 때 기존 세션 식별자를 무효화하지 않으면, 공격자가 인증된 세션을 탈취할 기회를 얻게 된다." 이로 인해 사용자는 거의 완전한 계정 탈취를 당할 수 있으며, 피해자는 아무 일도 일어난 줄 모를 수 있습니다.
세션 고정은 세션 하이재킹과는 구별되며, 두 용어가 혼동되는 경우가 있습니다. OWASP는 이 차이를 명확히 구분합니다. 세션 고정은 피해자가 로그인하기 전에 시작되고, 세션 하이재킹은 이미 활성화된 인증 세션이 존재한 후에 발생합니다. 고정 공격에서는 공격자가 세션 ID를 미리 알고 있거나 설정합니다. 하이재킹 공격에서는 공격자가 활성 세션에서 세션 ID를 탈취하거나 예측해야 합니다.
| 속성 | 세션 고정 | 세션 하이재킹 |
| 공격 시점 | 피해자 인증 전 | 피해자 인증 후 |
| 세션 ID 인지 | 공격자가 미리 ID를 설정하거나 알고 있음 | 공격자가 ID를 탈취하거나 예측해야 함 |
| 주요 대응책 | 로그인 시 세션 ID 재생성 | 토큰 암호화, 안전한 전송 |
이 구분은 보안 통제에 매우 중요합니다. 애플리케이션이 로그인 후 세션 ID를 재생성하면 고정 공격을 차단할 수 있습니다. 전송 중 세션 토큰만 암호화하면 하이재킹은 막을 수 있지만, 고정 공격에는 취약하게 됩니다. 공격의 작동 원리를 이해하면 이 차이가 왜 중요한지 알 수 있습니다.
.jpg)
세션 고정은 어떻게 작동하는가?
세션 고정은 MITRE CWE와 OWASP WSTG 모두에서 문서화된 4단계 공격 흐름을 따릅니다.
- 1단계: 세션 획득. 공격자가 대상 애플리케이션에 접속하여 인증 전 유효한 세션 ID를 받습니다. 예를 들어, 서버가
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1을 반환할 수 있습니다. 관대한 세션 수락 메커니즘을 사용하는 애플리케이션에서는 공격자가 임의의 세션 ID 값을 제공해도 애플리케이션이 이를 그대로 수락할 수 있습니다. - 2단계: 세션 전달. 공격자는 알고 있는 세션 ID를 피해자에게 전달합니다. 이 전달은 조작된 URL, 크로스사이트 스크립팅 페이로드, 삽입된 META 태그, HTTP 응답 분할 등을 통해 이루어질 수 있습니다. 목표는 피해자의 브라우저가 공격자가 제어하는 세션 ID를 사용하여 대상 애플리케이션에 접근하도록 만드는 것입니다.
- 3단계: 피해자 인증. 피해자가 조작된 링크를 클릭하거나 공격자의 전달 메커니즘을 통해 애플리케이션에 접속하여 정상적으로 로그인합니다. 애플리케이션은 자격 증명을 검증하고 접근을 허용하지만, 로그인 성공 후 세션 ID를 재생성하지 않고 공격자가 이미 알고 있는 동일한 식별자를 계속 사용합니다.
- 4단계: 계정 탈취. 공격자는 알고 있는 세션 ID를 사용하여 애플리케이션에 요청을 보냅니다. 서버는 이 요청을 인증된 피해자로부터 온 것으로 처리합니다. MITRE는 이를 "세션이 유지되는 동안 피해자 계정에 거의 무제한 접근"을 제공한다고 명시합니다.
이 네 가지 핵심 단계 외에도, 세션 고정은 공격자의 접근 권한과 대상 애플리케이션의 구성에 따라 여러 가지 방식으로 전달될 수 있습니다.
주요 5가지 공격 벡터
- URL 파라미터 삽입은 가장 단순한 벡터입니다. 공격자가 세션 ID를 URL 쿼리 파라미터로 삽입하고 피싱이나 이메일을 통해 링크를 전달합니다:
https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner는 "URL 내 세션 토큰"을 CWE-384로 분류합니다. - XSS를 통한 쿠키 삽입은 피해자 브라우저에서 실행되는 JavaScript를 이용해 세션 쿠키를 설정합니다:
document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE는 크로스사이트 스크립팅이 세션 고정 페이로드 전달의 대표적인 두 가지 기법 중 하나임을 확인합니다. - META 태그 삽입은 브라우저가 쿠키를 설정하도록 지시하는 HTML 태그를 심는 방식입니다:
<meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP는 이 방법이 JavaScript 삽입보다 방어가 더 어렵다고 지적합니다. "브라우저에서 이러한 태그의 처리를 비활성화하는 것은 불가능하다"고 설명합니다. - HTTP 응답 헤더 삽입은 응답 분할 취약점을 이용해
Set-Cookie헤더를 서버 응답에 직접 삽입하여, 클라이언트 측 스크립트 없이 제어된 세션 ID를 심습니다. - 교차 서브도메인 쿠키 고정은 도메인 공유 구조를 악용합니다. MITRE는 이를 직접 문서화합니다.
bank.example.com과recipes.example.com이 동일 최상위 도메인을 공유할 경우, recipes 애플리케이션의 취약점이 전체example.com도메인에 걸쳐 세션 ID를 고정할 수 있습니다. 다양한 전달 벡터로 인해 실제 운영 환경에서도 세션 고정이 여전히 발견됩니다.
세션 고정의 원인
세션 고정의 근본 원인은 잘 문서화되어 있으며, 각각은 개발팀이 해결할 수 있는 보안상의 빈틈을 의미합니다.
인증 후 세션 ID 재생성 실패
이것이 모든 권위 있는 자료에서 지적하는 주요 원인입니다. OWASP 가이드는 "애플리케이션이 성공적으로 사용자 인증 후 세션 쿠키를 갱신하지 않으면, 세션 고정 취약점이 발생할 수 있다"고 명시합니다.
OWASP 시트는 로그인, 비밀번호 변경, 권한 변경, 역할 전환 시 세션 ID 재생성이 필수임을 명시합니다. CVE-2022-24895 기록은 Symfony의 NONE 세션 마이그레이션 전략이 인증 후에도 동일 세션을 유지하여 고정 공격을 가능하게 하며, HIGH 심각도 등급을 받았음을 보여줍니다.
관대한 세션 ID 수락
OWASP Session Management Cheat Sheet는 세션 ID 처리 방식으로 두 가지 메커니즘을 정의합니다. 관대한 메커니즘은 사용자가 설정한 임의의 세션 ID 값을 유효한 것으로 받아들이고, 이에 대해 새 세션을 생성합니다. 엄격한 메커니즘은 애플리케이션이 미리 생성한 세션 ID만 허용합니다. 관대한 메커니즘을 사용하면 공격자가 서버에서 발급받지 않은 임의의 값을 심을 수 있습니다.
예측 가능한 세션 식별자
MITRE는 예측 가능한 세션 식별자를 기여 조건으로 지적하며, 이는 CWE-340 (예측 가능한 숫자 또는 식별자 생성)과 관련이 있습니다. 세션 ID가 패턴을 따르거나 약한 난수성을 사용할 경우, 공격자는 서버에서 값을 획득하지 않고도 유효한 값을 예측할 수 있습니다.
관대한 쿠키 도메인 범위
Domain 쿠키 속성을 최상위 도메인(예: Domain=example.com)으로 설정하면, 모든 서브도메인에 쿠키가 전송됩니다. 어느 한 서브도메인의 취약점이 전체 도메인 내 모든 애플리케이션의 고정 진입점이 될 수 있습니다.
세션 재생성 없는 HTTP-HTTPS 전환
OWASP WSTG-SESS-03은 다음과 같은 시나리오를 지적합니다. 사이트가 HTTP로 세션 식별자를 발급한 후 HTTPS 로그인 폼으로 리디렉션하지만, 인증 시 세션 ID를 재발급하지 않으면, 인증 전 ID가 네트워크 수준 도청에 노출됩니다. 공격자는 비인가 연결에서 ID를 탈취한 뒤 피해자가 인증할 때까지 기다릴 수 있습니다. 이러한 원인은 단독으로 나타나는 경우가 드물며, 표준 커뮤니티가 이를 공식적으로 어떻게 분류하는지 이해하면 소통과 우선순위 지정에 도움이 됩니다.
OWASP의 세션 고정 분류
세션 고정은 MITRE Common Weakness Enumeration, OWASP Top 10, OWASP Web Security Testing Guide 등 세 가지 권위 있는 표준 시스템에서 공식적으로 분류됩니다. OWASP A07에서는 인증 실패 범주 내에서 관련 취약점과 함께 다루며, 동일한 대응 범위를 공유합니다. 각 분류는 서로 다른 대상과 조치 신호를 제공합니다.
CWE-384: 공식 취약점 식별자
MITRE CWE-384는 세션 고정의 주요 분류로, 기존 세션 식별자를 무효화하지 않고 사용자를 인증하는 취약점을 정의합니다. MITRE 분류 내 프로필은 다음과 같습니다.
- 취약점 유형: 세션 자격 증명 범주의 기본 취약점
- 일반적 결과: 권한 상승 또는 피해자 신원 도용; 세션 유지 기간 동안 전체 계정 탈취
- 공격 가능성: 중간 — 로그인 전 알려진 세션 ID를 피해자에게 전달해야 함
- 플랫폼 범위: 언어 독립적; 웹 스택 또는 프레임워크와 무관하게 적용
- CWE Top 25 상태: 2019년 Top 25 진입; 2023년판에서도 활성 추적 취약점
이러한 특성으로 CWE-384는 취약점 스캐너 및 평가 프레임워크에서 세션 라이프사이클 처리 테스트 케이스와 직접 매핑됩니다.
OWASP Top 10 및 테스트 표준
CWE-384는 A07:2025 — 인증 실패와 매핑됩니다. 이 분류는 중요한 의미를 가집니다. 세션 고정은 쿠키 설정 오류가 아니라 인증 통제 실패로 간주됩니다. 이로 인해 로그인 흐름 검토 및 인증 강화 작업의 범위에 포함되며, 단순 쿠키 설정 감사에만 국한되지 않습니다.
| 참조 | 시스템 | 목적 |
| MITRE CWE | 공식 취약점 추적; SAST/DAST 도구 및 CVE 기록에 사용 | |
| OWASP Top 10 | 위험 우선순위 신호; 인증 통제 검토 범위 지정 | |
| OWASP WSTG | 공식 블랙박스 테스트 절차 및 합격/불합격 기준 | |
| OWASP CheatSheets | 재생성, 쿠키 범위, 엄격 모드에 대한 개발자용 예방 참조 |
이 네 가지 참조는 세션 고정을 기존 보안 프로그램 내에서 해결할 수 있는 용어, 테스트 케이스, 대응 가이드를 제공합니다. 분류 맥락이 정립되면, 실제로 취약점이 악용될 때 어떤 일이 발생하는지 살펴볼 가치가 있습니다.
세션 고정의 영향 및 위험
세션 고정은 손상된 세션의 유효 기간 동안 전체 계정 탈취를 가능하게 합니다. 공격자가 인증된 세션 ID를 확보하면, 피해자가 가진 모든 권한으로 동작할 수 있습니다. 민감 데이터 열람, 거래 수행, 계정 설정 변경, 피해자가 관리자 권한을 가진 경우 권한 상승까지 가능합니다.
OWASP 분류 및 심각도
CWE-384는 OWASP A07에 속합니다. A07:2025 범주는 평균 가중치 공격 가능성 점수 7.69를 가지며, 테스트된 애플리케이션 전반에 7,147건의 CVE가 매핑되어 있습니다. A07 범주에 매핑된 총 CVE 수도 2021년판 대비 2025년판에서 증가하여, 공격 표면이 확장되고 있음을 보여줍니다.
CVSS 점수 범위
확인된 세션 고정 CVE는 중간에서 치명적까지 다양합니다. 가장 높은 등급의 사례는 고정 공격이 널리 배포된 인증 플러그인 또는 프레임워크에서 인증되지 않은 계정 탈취를 가능하게 하는 시나리오에서 나타납니다. 실무자에게 중요한 점은, 세션 고정 CVE는 NIST NVD와 벤더 CNA 간 점수 불일치가 자주 발생한다는 것입니다. 예를 들어, CVE-2019-17563(Apache Tomcat)은 NIST에서 CRITICAL 등급을 받았으나, Apache에서는 "실제 악용이 어려울 정도로 짧은 윈도우"라며 "Low"로 평가했습니다.
복합 위험 요인
세션 고정은 단독 위험으로 작동하는 경우가 드뭅니다. CVE-2024-56529(Mailcow)는 피해자 브라우저에서 HSTS가 비활성화된 경우에만 공격이 성공함을 보여줍니다. Microsoft Research의 IEEE S&P 2015 논문은 쿠키 삽입이 실제 웹사이트에서 표준 세션 재생성 방어를 우회할 수 있음을 입증했습니다. 심층 방어 통제가 동시에 실패하면, 세션 고정 취약점은 빠르게 심각해질 수 있습니다. 누가 취약한지의 문제는 웹 애플리케이션에만 국한되지 않습니다.
공격자가 세션 고정을 악용하는 방법
공격자는 표적 피싱부터 기회적 세션 오염까지 다양한 시나리오로 세션 고정을 악용합니다.
피싱 기반 URL 삽입
공격자는 알려진 세션 ID가 포함된 URL을 만들어 피싱 또는 사회공학을 통해 전달합니다. URL은 실제 애플리케이션 도메인을 가리키므로 정상적으로 보입니다. 피해자가 링크를 클릭하고 정상적으로 로그인하면, 공격자가 제어하는 세션이 인증됩니다. 이는 URL 기반 세션 ID 전달의 가장 일반적인 시나리오입니다.
공용 단말기 악용
MITRE CWE-384는 대표적 시나리오를 문서화합니다. 공격자가 공용 단말기에서 세션을 생성하고 세션 식별자를 기록한 뒤, 브라우저를 로그인 페이지로 재설정하고 다음 사용자가 인증하기를 기다립니다. 애플리케이션은 기존 세션 ID를 계속 사용하여, 공격자에게 "세션이 유지되는 동안 피해자 계정에 거의 무제한 접근"을 허용합니다.
비표적 세션 오염
CVE-2022-30769(ZoneMinder)는 공격자가 "다음 로그인 사용자를 위해 세션 쿠키를 오염시킬 수 있는" 공격을 입증했습니다. 특정 개인을 표적으로 삼을 필요가 없었습니다. 오염된 세션은 다음 인증자에게 상속됩니다. 감시 플랫폼처럼 공유 접근 환경에서는 이 패턴이 특히 위험합니다.
경쟁 조건 악용
CVE-2013-2067(Apache Tomcat)은 FORM 인증 경쟁 조건을 드러냈습니다. 피해자가 로그인 폼을 작성하는 동안, 공격자가 인증된 리소스 요청을 반복적으로 보내면 피해자 자격 증명으로 실행되는 요청을 삽입할 수 있었습니다. Apache는 이를 "중요" 심각도로 평가했습니다.
교차 서브도메인 공격
최상위 도메인을 공유하는 다중 애플리케이션 구조에서, 공격자는 취약한 저보안 애플리케이션을 이용해 상위 도메인에 범위가 지정된 세션 쿠키를 고정합니다. 해당 도메인의 모든 다른 애플리케이션이 고정된 세션 ID를 수락하게 됩니다. 이 시나리오는 여러 내부 도구를 공유 도메인에서 운영하는 엔터프라이즈 환경에서 흔히 나타납니다. 누가 영향을 받는지 아는 것은 취약점 탐지 우선순위에 도움이 됩니다.
세션 고정의 영향 대상
세션 고정은 사용자 세션을 식별자로 관리하면서 인증 시 이를 재생성하지 않는 모든 애플리케이션에 영향을 미칩니다. CVE 기록과 MITRE 문서는 구조적으로 고위험인 여러 범주를 지적합니다.
- URL 기반 세션 식별자를 사용하는 웹 애플리케이션이 가장 직접적인 노출을 가집니다. URL 기반 세션 전송은 공격자가 별도의 취약점 없이 조작된 링크로 제어된 세션 ID를 전달할 수 있게 합니다.
- CMS 및 인증 플러그인 생태계는 반복적으로 영향을 받습니다. CVE-2024-13279(Drupal TFA, CISA 참조), CVE-2010-1434(Joomla!), CVE-2012-5391(MediaWiki), CVE-2019-8116(Magento) 등은 인증 모듈이 세션 재생성을 강제하지 않을 때 치명적 세션 고정 위험을 도입함을 보여줍니다.
- J2EE/Java EE 애플리케이션은 가장 광범위한 CVE 시리즈를 보유하고 있습니다. Apache Tomcat만 해도 2013년부터 2025년까지 CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563, CVE-2025-55668 등 다수의 CVE가 존재합니다.
- 다중 애플리케이션 공유 도메인 구조는 설계상 취약합니다. 테넌트 서브도메인을 가진 SaaS 플랫폼과 최상위 도메인을 공유하는 엔터프라이즈 애플리케이션 포트폴리오는 MITRE가 직접 문서화한 교차 서브도메인 고정 위험에 노출됩니다.
- ICS/SCADA 플랫폼은 새로운 위험 표면을 나타냅니다. CVE-2025-70973(ScadaBR 1.12.4, 2026년 3월 공개)은 산업제어시스템 플랫폼에서 세션 고정을 보여주며, CWE-384의 ICS 범주 매핑(CWE-1364, CWE-1366)과 일치합니다.
- 엔터프라이즈 워크플로우 플랫폼도 문서화된 노출을 가집니다. CVE-2022-38369(Apache IoTDB), CVE-2022-38054(Apache Airflow)는 워크플로우 자동화 도구도 예외가 아님을 보여줍니다. 다양한 영향 범주는 실제 사례를 통해 취약점이 어떻게 나타나는지 이해하는 데 도움이 됩니다.
세션 고정의 실제 사례
세션 고정은 엔터프라이즈 Java 프레임워크부터 산업제어 플랫폼까지 다양한 운영 시스템에서 확인되었습니다. 아래 사례는 동일한 근본 결함이 환경에 따라 어떻게 다르게 나타나는지 보여줍니다.
Apache Tomcat FORM 인증 경쟁 조건 (CVE-2013-2067)
이는 "중요"로 평가된 Apache의 가장 영향력 있는 Tomcat 세션 고정 CVE입니다. Tomcat 6.0.21~6.0.36, 7.0.0~7.0.32에 영향을 미쳤으며, FORM 인증의 경쟁 조건을 악용했습니다. 공격자는 피해자가 로그인 폼을 작성하는 동안 인증된 리소스 요청을 반복적으로 보내 피해자 자격 증명으로 실행되는 요청을 삽입할 수 있었습니다. 아이러니하게도, 인증 시 세션 ID 변경 옵션은 Tomcat 6.0.21에 추가된 기능이었습니다. 이 CVE는 Tomcat 자체 고정 방어의 버그를 의미했습니다.
Symfony 프레임워크 CSRF 토큰 우회 (CVE-2022-24895)
Symfony 2.0.0~6.2.5는 HIGH 심각도 취약점의 영향을 받았습니다. 프레임워크는 로그인 시 세션 ID를 재생성했지만, CSRF 토큰 등 나머지 세션 속성은 유지했습니다. 이 부분적 재생성으로 인해 동일 사이트 공격자가 세션 고정 변종을 통해 CSRF 보호를 우회할 수 있었습니다. 교훈은 명확합니다. 세션 ID만 재생성해서는 충분하지 않습니다. 전체 세션 무효화 및 재발급이 필요합니다.
ScadaBR 산업제어시스템 (CVE-2025-70973)
2026년 3월 공개된 ScadaBR 1.12.4의 이 취약점은 전형적인 세션 고정 패턴을 따릅니다. 애플리케이션은 인증되지 않은 사용자에게 JSESSIONID 세션 쿠키를 할당하고, 인증 후에도 세션 식별자를 재생성하지 않습니다. 로그인 전 생성된 세션이 인증 후에도 그대로 사용됩니다. 이 CVE는 ICS/SCADA 환경에서 세션 고정 위험이 여전히 존재함을 보여줍니다.
ZoneMinder 비표적 세션 오염 (CVE-2022-30769)
ZoneMinder 1.36.12 이하 버전은 공격자가 다음 인증 사용자에게 상속될 세션 쿠키를 오염시킬 수 있었습니다. 특정 피해자를 표적으로 삼을 필요가 없어, 여러 운영자가 동일 플랫폼에 접근하는 감시 환경에서 특히 위험합니다.
PHP 세션 채택 (CVE-2011-4718)
PHP의 세션 모듈은 "채택형"으로, 외부 소스의 세션 ID를 수락했습니다. PHP RFC는 "session_regenerate_id()만으로는 session adoption/fixation을 막을 수 없으며, session.use_strict_mode도 활성화해야 한다"고 명시합니다. PHP 5.5.2에서 session.use_strict_mode가 도입되었으나, 엄격 모드가 활성화되어도 커스텀 세션 핸들러는 여전히 취약할 수 있습니다. 이러한 사례의 전체 기록은 이 취약점이 얼마나 오랫동안 지속되어 왔는지 보여줍니다.
세션 고정 타임라인 및 역사
세션 고정은 2002년부터 공식적으로 문서화되었으며, CVE 기록은 신규 및 레거시 코드베이스 모두에서 여전히 활발함을 보여줍니다. 아래 타임라인은 주요 공개 사건과 프레임워크 차원의 대응을 추적합니다.
| 연도 | 이벤트 |
| 2002년 12월 | Mitja Kolšek(ACROS Security)가 "웹 기반 애플리케이션의 세션 고정 취약점"을 발표하며, 세션 식별자에 대한 네 번째 공격 클래스로 세션 고정을 공식 명명 |
| 2006년 | CVE-2006-1228(Drupal 4.5.x/4.6.x): URL 기반 세션 ID 고정 |
| 2006년 7월 | MITRE가 CWE-384를 Common Weakness Enumeration(Draft 3)에 추가 |
| 2008년 2월 | Oracle/BEA WebLogic Server 권고 BEA08-196.00: 세션 고정으로 인한 권한 상승 |
| 2009년 | CVE-2009-1580(SquirrelMail); Black Hat USA가 BitTorrent 트래커 커뮤니티에서 CWE-384 문서화 |
| 2010년 | CVE-2010-1434(Joomla! 1.5.0~1.5.15): CVSS 7.5 HIGH |
| 2011년 12월 | CVE-2011-4718(PHP 세션 채택): PHP 5.0.0~5.5.1 영향 |
| 2013년 5월 | CVE-2013-2067(Apache Tomcat 6.x, 7.x): FORM 인증 경쟁 조건, Apache "중요" 심각도 |
| 2015년 | Microsoft Research(IEEE S&P)가 널리 채택된 재생성 방어 우회 쿠키 삽입 문서화 |
| 2019년 | CWE-384가 Top 25 진입 |
| 2019년 12월 | CVE-2019-17563(Apache Tomcat): NIST 9.8 CRITICAL vs. Apache "Low" |
| 2022년 | CVE-2022-24895(Symfony): 부분 재생성 우회 |
| 2025년 1월 | CVE-2024-56529(Mailcow): HSTS 비활성화 시 세션 고정 |
| 2025년 8월 | CVE-2025-55668(Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 MODERATE |
| 2026년 3월 | CVE-2025-70973(ScadaBR 1.12.4), CVE-2026-25101(Bludit): 신규 CVE로 취약점 클래스가 여전히 활성 상태임을 확인 |
이 타임라인은 20년 이상 지속되고 있으며, 둔화 조짐이 없습니다. 세션 고정은 과거의 취약점이 아닙니다. 엔터프라이즈 프레임워크부터 ICS 플랫폼까지 신규 및 레거시 코드베이스 모두에서 계속 발견되고 있습니다. 자체 애플리케이션을 검토할 수 있다면, 다음 단계로 나아갈 수 있습니다.
세션 고정 탐지 방법
세션 고정은 확인이 비교적 간단한 취약점입니다. 핵심 테스트는 인증 전 세션 식별자를 캡처하고, 인증 후 값을 비교하는 것만으로 충분합니다. 아래 방법은 수동 검증, 쿠키 속성 점검, 자동 스캐닝, WAF 계층 식별을 포함합니다.
수동 침투 테스트(OWASP WSTG-SESS-03)
공식 테스트 절차는 OWASP WSTG에서 제공합니다. 블랙박스 테스트는 다음과 같이 진행됩니다.
- 인증 전 세션 ID 캡처. 애플리케이션에 접속하여 세션 쿠키 값을 기록합니다
(예: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1). - 캡처한 세션 ID로 인증. 원래 세션 쿠키를 첨부한 채로 유효한 자격 증명을 제출합니다.
- 세션 ID 값 비교. 인증 후 서버가 동일한 세션 ID를 반환하면, 애플리케이션은 취약합니다.
HSTS가 완전히 적용되지 않은 애플리케이션의 경우, WSTG-SESS-03은 두 번째 전략을 설명합니다. 로그인 후 새로 발급되지 않은 모든 쿠키를 별도 머신에서 피해자 브라우저로 강제로 주입한 뒤, 해당 쿠키가 인증 후 세션 접근을 허용하는지 확인합니다.
쿠키 속성 검증
세션 쿠키의 보안 강화 지표를 확인합니다. __Host- 접두사는 네트워크 기반 세션 고정에 대한 무결성을 제공합니다. __Secure- 접두사는 부분적 강화임을 나타냅니다. WSTG-SESS-03을 실행하여 HttpOnly, Secure, SameSite 속성이 올바르게 설정되어 있는지 확인합니다.
DAST 스캐닝
OWASP ZAP은 세션 관리 지원을 포함한 능동 및 수동 스캐닝 모드를 제공하며, 쿠키, 토큰 등 다양한 메커니즘을 처리합니다. ZAP의 세션 및 인증 강제 분석은 인증 우회 및 세션 고정 버그를 탐지하는 데 도움이 됩니다. Burp Suite Professional은 세션 관리 테스트 워크플로우를 지원하며, 세션 관리 테스트에 적용 가능한 동적 웹 취약점 스캐너로 동작합니다.
WAF 기반 식별
OWASP 시트는 ModSecurity와 OWASP Core Rule Set을 결합하면 세션 고정 공격에 대한 대응책을 제공한다고 명시합니다. WAF 계층 접근은 소스 코드를 사용할 수 없거나, 수정이 불가능하거나, 전체 애플리케이션 수준 수정을 위해 대규모 재설계가 필요한 경우 권장됩니다. 효과적인 검토는 곧바로 예방으로 이어져야 하며, 필요한 통제는 명확히 정의되어 있습니다.
세션 고정 예방 방법
예방의 핵심은 하나의 비타협적 요구사항에 있습니다. 애플리케이션은 모든 인증 이벤트마다 새로운 세션 ID를 발급해야 하며, 서버가 직접 생성하지 않은 세션 식별자는 거부해야 합니다. 아래 통제는 애플리케이션 계층, 프레임워크 수준, 쿠키 설정, 네트워크 아키텍처에서 이 요구사항을 충족합니다.
애플리케이션 계층 통제
- 인증 후 세션 ID 재생성. 가장 중요한 통제입니다. OWASP WSTG-SESS-03은 "애플리케이션은 항상 사용자를 인증하기 전에 기존 세션 ID를 먼저 무효화해야 하며, 인증이 성공하면 새로운 세션 ID를 제공해야 한다"고 명확히 명시합니다. 로그인, 비밀번호 변경, 권한 변경, 역할 전환 등 모든 권한 수준 변경 시 재생성이 필수입니다.
- 엄격한 세션 관리 사용. 애플리케이션이 서버에서 생성한 세션 ID만 허용하도록 구성합니다. 클라이언트가 제출한 임의의 세션 ID 값은 거부해야 합니다. PHP는 이를 위해 5.5.2 버전에 session.use_strict_mode를 도입했습니다.
- 세션 완전 무효화. CVE-2022-24895(Symfony)는 부분적 세션 재생성이 충분하지 않음을 입증했습니다. 세션 ID만 재생성하고 CSRF 토큰 등 다른 세션 속성을 유지하면 잔여 취약점이 남습니다. 전체 세션 무효화 및 재발급이 필요합니다.
프레임워크별 구현
| 프레임워크 | 기존 세션 무효화 | 새 세션 생성 |
| J2EE | HttpSession.invalidate() | request.getSession(true) |
| ASP.NET | Session.Abandon() | Response.Cookies.Add(new HttpCookie(...)) |
| PHP | session_start() | session_regenerate_id(true) |
Spring Security는 사용자가 로그인할 때 자동으로 새 세션을 생성하거나 세션 ID를 변경하여 세션 고정을 방지합니다. 네 가지 구성 전략이 제공됩니다: changeSessionId()(권장), migrateSession(), newSession(), none()(비권장).
쿠키 보안 설정
NIST SP 800-63B 요구사항을 따르십시오.
Secure플래그: 반드시 설정(쿠키는 HTTPS로만 전송)Domain및Path: 최소한의 범위로 제한해야 함HttpOnly플래그: 설정 권장(JavaScript 접근 방지)SameSite=Lax또는Strict: 설정 권장(NIST SP 800-63B v4 초안 기준)__Host- 접두사 및Path=/:설정 권장(NIST SP 800-63B v4 초안 기준)
이 플래그를 조합하여 적용하면, 가장 흔한 네트워크 기반 및 교차 사이트 고정 전달 시나리오를 차단하고, 쿠키 삽입을 시도하는 공격자에 대한 방어 수준을 크게 높일 수 있습니다.
아키텍처 수준 통제
보안 수준이 다른 애플리케이션을 동일 도메인에서 혼합하지 마십시오. 네트워크 기반 고정 공격을 방지하려면 서브도메인을 포함한 전체 HSTS를 구현하십시오. 애플리케이션 수준 변경이 즉시 불가능한 경우, WAF 계층 보호를 위해 OWASP Core Rule Set과 함께 ModSecurity를 배포하십시오. 예방과 검토는 적절한 도구의 지원을 받을 때 가장 효과적입니다.
탐지 및 예방 도구
세션 고정을 식별하고 차단하려면, 실제 공격 조건을 시뮬레이션하는 동적 스캐너, 코드 수준에서 안전한 기본값을 강제하는 프레임워크 네이티브 보호, 인증 세션에 도달한 고정 기반 침입을 탐지하는 행위 분석 등 세 가지 계층의 도구가 필요합니다. 아래 도구는 이 세 가지를 모두 포괄합니다.
DAST 및 침투 테스트 도구
- OWASP ZAP은 무료 오픈소스 동적 애플리케이션 보안 테스트 도구입니다. 공식 문서에 따르면, ZAP은 세션 고정을 포함한 세션 관리 결함을 탐지하기 위해 능동 및 수동 스캐닝 모드를 사용합니다.
- Burp Suite Professional은 세션 테스트 워크플로우와 세션 토큰 처리 취약점 식별용 스캐너 규칙을 제공합니다. 수동 테스트 기능을 통해 WSTG-SESS-03 절차를 요청/응답 전체 가시성으로 단계별 수행할 수 있습니다.
- ModSecurity와 OWASP Core Rule Set은 세션 고정에 대한 WAF 계층 대응책을 제공하며, 보안 쿠키 속성 식별 및 강제, 스티키 세션 추적, 권한 변경 시 세션 ID 갱신을 지원합니다.
프레임워크 보안 기능
Spring Security의 내장 세션 고정 방지, PHP의 session.use_strict_mode 및 session_regenerate_id(), ASP.NET의 Session.Abandon() 등은 모두 언어 네이티브 예방 기능을 제공합니다. 배포 환경에서 이러한 기능이 활성화 및 올바르게 구성되어 있는지 반드시 확인해야 하며, 기본 설정에만 의존해서는 안 됩니다.
관련 취약점
세션 고정은 단독으로 작동하지 않습니다. 여러 밀접하게 관련된 취약점이 CWE-384와 전달 메커니즘, 악용 조건, 위험 증폭 요인을 공유합니다. 이들을 그룹으로 이해하면 세션 고정만 따로 다루는 것보다 더 강력한 대응 범위를 확보할 수 있습니다.
- 크로스사이트 스크립팅 (CWE-79)은 세션 고정의 전달 메커니즘 역할을 합니다. 반사형 XSS는 피해자 브라우저에 제어된 세션 쿠키를 설정하는 JavaScript를 삽입할 수 있습니다. XSS를 차단하면 주요 고정 전달 채널 중 하나를 제거할 수 있습니다.
- 크로스사이트 요청 위조(CWE-352)는 세션 고정과 혼동되는 경우가 많지만, 동작 방식이 다릅니다. CSRF는 브라우저의 자동 쿠키 전송을 악용해 인증 세션에서 요청을 위조합니다. 공격자가 세션 ID를 알거나 제어할 필요가 없습니다. CWE-352는 2023 CWE Top 25에서 9위를 차지했습니다.
- 부적절한 인증(CWE-287)은 세션 고정과 밀접하게 관련되며, 동일한 OWASP A07 인증 실패 범주에 속합니다. CWE-287은 모든 형태의 인증 우회를 포괄하며, 2023년 CWE Top 25에서 13위, CISA Known Exploited Vulnerabilities 카탈로그에 10건이 등재되었습니다.
- 불충분한 세션 만료(CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/)는 세션 고정 위험을 증폭시킵니다. 고정된 세션 ID가 유효한 기간이 길수록 공격자가 이를 악용할 수 있는 시간이 늘어납니다.
- 예측 가능한 숫자 생성(CWE-340)은 MITRE 분류에서 CanFollow 관계를 통해 세션 고정에 선행할 수 있습니다. 예측 가능한 세션 식별자는 유효한 세션 ID 값을 추측할 수 있게 하여 고정 공격의 장벽을 낮춥니다. 세션 고정만 따로 다루면 전체 위험 표면을 커버하지 못하므로, 관련 취약점도 함께 검토해야 고정 공격이 초기 진입점을 얻는 경로를 차단할 수 있습니다.
관련 CVE
CVE ID | 설명 | 심각도 | 영향 제품 | 연도 |
| 로그인 후 세션 식별자가 재생성되지 않음; 공격자가 인증 전 피해자 세션 ID를 설정하고 로그인 후 세션을 탈취 | Pending | OpenSolution: Quick.Cart | 2026 | |
| 원격 인증에 SSO 변수를 사용할 때 세션 고정 발생; 공격자가 동일 머신에서 이전에 열린 세션을 탈취 가능 | Pending | GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5) | 2026 | |
| 세션 고정(CWE-384)으로 공격자가 사용자 세션을 탈취하고 피해자 대신 무단 거래 수행 가능 | MEDIUM (6.5) | HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0) | 2025 | |
| ManageEngine ADSelfService Plus의 세션 처리 오류(CWE-287); 저권한 인증 사용자가 부적절한 세션 관리 악용해 타 사용자 계정 탈취 | HIGH (9.3) | Zohocorp ManageEngine ADSelfService Plus (≤ build 6510) | 2025 | |
| GoFiber 세션 미들웨어의 세션 고정(CWE-384); 사용자 제공 session_id 값을 수락하여 공격자가 인증 세션 키를 제어 | CRITICAL (9.8) | GoFiber: Fiber (< 2.52.5) | 2024 | |
| 지원 중단된 VMware Enhanced Authentication Plug-in의 세션 하이재킹(CWE-384); 로컬 비권한 공격자가 권한 있는 도메인 사용자의 인증된 EAP 세션 탈취 | HIGH (7.8) | VMware: Enhanced Authentication Plug-in (deprecated) | 2024 | |
| 지원 중단된 VMware EAP의 인증 릴레이 및 세션 하이재킹; 악의적 행위자가 도메인 사용자를 속여 임의 Active Directory SPN에 대한 Kerberos 서비스 티켓 릴레이 | CRITICAL (9.6) | VMware: Enhanced Authentication Plug-in (deprecated) | 2024 | |
| Apache Superset의 기본 SECRET_KEY로 세션 쿠키 서명; 기본값을 아는 공격자가 유효한 세션 쿠키를 위조해 관리자 포함 모든 사용자로 인증 가능; CISA KEV | CRITICAL (9.8) | Apache Superset (≤ 2.0.1) | 2023 | |
| SessionListener#sessionDestroyed()에서 예외 발생 시 세션 ID가 세션 ID 관리자에 남아 있음(CWE-613); 로그아웃 후 공유 컴퓨터에서 이전 사용자 세션 접근 가능 | LOW (3.5) | Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3) | 2021 | |
| 기본 비밀키로 서명된 세션 토큰이 서로 다른 Airflow 배포 간에 수락됨; 한 인스턴스의 인증 사용자가 다른 인스턴스에 재인증 없이 접근 가능 | HIGH (8.8) | Apache Airflow Webserver (< 1.10.14) | 2020 |
결론
세션 고정은 잘 알려진 단일 실패, 즉 애플리케이션이 인증 후 세션 ID를 재생성하지 않는 점을 악용합니다. CWE-384로 공식 분류되고 OWASP Top 10 2025 A07에 매핑되어 있으며, CMS 플랫폼, Java 프레임워크, PHP 애플리케이션, ICS/SCADA 시스템 등에서 계속 발견되고 있습니다.
모든 권한 변경 시 세션 ID를 교체하고, 엄격한 세션 수락을 강제하며, 쿠키 범위를 강화하고, 인증 후 활동을 오남용 여부로 점검하면 위험을 줄일 수 있습니다.
자주 묻는 질문
세션 고정은 애플리케이션이 로그인 전후에 동일한 세션 ID를 유지할 때 발생합니다. 공격자는 먼저 피해자가 알려진 세션 ID를 사용하도록 만들고, 이후 피해자가 인증할 때까지 기다립니다.
애플리케이션이 새로운 ID를 발급하지 않으면, 공격자는 동일한 인증된 세션을 사용할 수 있습니다. 주요 방어책은 간단합니다: 로그인 및 기타 권한 변경 후 기존 세션을 무효화하고 새 세션을 생성해야 합니다.
예. CWE-384는 OWASP Top 10 2025 A07: 인증 실패에 포함되어 있습니다. 방어자 입장에서는 이 분류 자체보다는 우선순위 신호로서 더 중요합니다: 세션 고정은 단순한 쿠키 오구성이 아니라 인증 실패로 간주됩니다.
로그인 플로우 검토, 세션 관리 테스트, 인증 강화 작업에 포함되어야 합니다.
예. 공격자가 피해자가 선택한 세션 ID를 사용하도록 만드는 방법만 있으면 되기 때문에 원격 전달이 일반적입니다. 이는 조작된 URL, 브라우저 측 스크립트, 악의적인 응답, 동일 상위 도메인 내의 취약한 애플리케이션을 통해 발생할 수 있습니다.
공유 또는 공용 단말기와 같은 시나리오에서만 물리적 접근이 필요합니다.
가장 위험도가 높은 애플리케이션은 사용자로부터 제공된 세션 ID를 허용하거나 인증 후 세션 ID를 회전하지 않는 경우입니다. 기사에서 언급된 일반적인 예로는 URL 기반 세션 방식, CMS 인증 모듈, Java 애플리케이션 스택, 공유 도메인 환경, 워크플로우 플랫폼, ICS/SCADA 웹 인터페이스 등이 있습니다.
공통된 패턴은 특정 언어나 산업이 아니라 취약한 세션 수명 주기 관리입니다.
로그인 후에도 세션이 변경되지 않는지 테스트합니다. 간단한 방법은 인증 전 세션 ID를 캡처하고, 해당 ID로 인증한 후 값을 비교하는 것입니다.
동일한 ID가 여전히 유효하다면 취약점이 존재합니다. 스캐닝 도구가 도움이 될 수 있지만, 부분적 재생성이나 교차 서브도메인 쿠키 동작과 같은 예외 케이스는 수동 테스트가 필요합니다.
하나의 세션이 두 사용자가 소유한 것처럼 동작하는지 확인하십시오. 실질적인 경고 신호로는 동일한 세션이 서로 다른 IP 주소에서 나타나거나, 갑작스러운 디바이스 또는 위치 변경, 로그인 직후 즉시 변경되는 접근 패턴 등이 있습니다.
세션 식별자가 URL을 통해 인증 엔드포인트로 전달되는 요청도 정상적인 브라우징이 아닌 고정 시도일 수 있습니다.
심각도는 탈취된 계정의 권한에 따라 달라집니다. 가치가 낮은 환경에서는 중간 정도로 평가될 수 있습니다. 고가치 시스템에서는 동일한 취약점이 전체 계정 탈취 및 관리자 권한 남용으로 이어질 수 있습니다.
본문의 CVE 예시는 4.6에서 9.8까지 다양하며, 세션 고정이 본질적으로 경미한 취약점이 아님을 보여줍니다. 영향은 권한, 노출, 주변 통제에 의해 결정됩니다.
대상 계정의 완전한 탈취로 직접 이어질 수 있으며, 피해자가 관리자라면 더 광범위한 침해로 확장될 수 있습니다. 공격자가 상승된 권한을 획득하면 설정 변경, 민감 데이터 접근, 전체 환경에 영향을 미치는 작업을 수행할 수 있습니다.
취약점 자체는 세션을 대상으로 하지만, 비즈니스 영향은 단일 로그인 이상으로 확장될 수 있습니다.
가장 단순한 형태는 인증 전후 세션 ID를 비교할 수 있기 때문에 비교적 쉽게 탐지할 수 있습니다. 더 어려운 경우는 부분적 재생성, 서브도메인 간 쿠키 상속, 전송 및 브라우저 동작에 따른 조건이 포함됩니다.
실제로 스캐닝은 범위 확보에 유용하지만, 실제 악용 가능성을 확인하려면 집중적인 수동 테스트가 여전히 중요합니다.
인증된 웹 애플리케이션을 운영하는 모든 산업이 노출되어 있으며, 특히 사용자가 민감한 데이터나 거래를 처리하는 경우 위험이 높습니다. 본문에서는 전자상거래, 엔터프라이즈 플랫폼, 공유 도메인 환경, 의료 규제 시스템, ICS/SCADA 배포 환경을 강조합니다.
플러그인, 레거시 세션 처리, 여러 애플리케이션이 상위 도메인을 공유하는 경우 위험이 증가합니다.
