세션 하이재킹 실전 흐름: 쿠키 탈취부터 방어(HTTPS·HttpOnly·SameSite)까지 한 번에 정리

세션 하이재킹이 터지는 전형적 흐름: “쿠키가 신분증”이 되는 순간

로그인 이후 웹 서비스는 사용자를 계속 다시 로그인시키지 않기 위해 세션을 유지한다.

이때 브라우저는 세션을 식별하는 값을 쿠키로 들고 다니고, 서버는 그 값을 보고 “이미 로그인한 사용자”로 판단한다.

세션 하이재킹은 이 쿠키 값이 공격자에게 넘어가면서 시작되는 경우가 많다.

현장에서 자주 보이는 장면은 다음과 같다.

• 공용 와이파이에서 로그인한 뒤, 다른 기기에서 같은 계정으로 동시에 접속 흔적이 보인다
• 사용자는 비밀번호를 바꾸지 않았는데도 특정 기능(결제, 계정 변경)이 이미 처리된 상태다
• 로그는 정상 로그인처럼 보이는데, IP·User-Agent가 갑자기 달라진다

흔한 오해는 “HTTPS만 쓰면 세션 하이재킹은 더 이상 일어나지 않는다”는 생각이다.

HTTPS는 전송 중 도청 위험을 줄이지만, 쿠키가 다른 경로로 탈취되는 경우까지 자동으로 막지는 못한다.

 

세션 하이재킹 흐름도(쿠키 탈취 → 재사용 → 피해)

 

쿠키 탈취 경로 3가지: 어디서 새는지부터 구분한다

쿠키가 새는 경로는 하나로 고정되지 않는다.

방어책도 유입 경로에 맞춰 조합해야 효과가 난다.

경로 1) 평문 전송 구간에서 가로채기

HTTPS가 강제되지 않거나 일부 리소스가 HTTP로 섞이면 쿠키가 노출될 수 있다.

특히 로그인 직후의 리다이렉트, 서브도메인 이동, 오래된 링크가 섞인 페이지에서 틈이 생긴다.

경로 2) 스크립트로 쿠키를 읽어 가는 탈취

페이지에 악성 스크립트가 실행되면 document.cookie로 쿠키를 읽어 외부로 보낼 수 있다.

이때 HttpOnly가 없으면 “브라우저 안에서 읽기”가 가능해져 피해가 커진다.

경로 3) 다른 사이트 요청에 쿠키가 딸려 나가는 상황

사용자가 다른 사이트를 방문했을 때도 브라우저가 쿠키를 자동으로 전송하는 경우가 있다.

SameSite 설정이 느슨하면 의도하지 않은 요청에 세션 쿠키가 붙어 나갈 여지가 생긴다.

핵심 개념 2개: Session ID와 쿠키 속성(Secure·HttpOnly·SameSite)

개념 1) Session ID

정의: 로그인 상태를 식별하기 위해 서버가 발급하고, 브라우저가 쿠키로 보관하는 식별 값이다.

핵심 특징: 이 값만 동일하면 비밀번호 없이도 서버가 같은 사용자로 판단할 수 있다.

핵심 특징: 서버는 Session ID를 키로 세션 저장소에서 사용자 상태를 조회하는 구조를 갖는 경우가 많다.

주의점: Session ID가 유출되면 공격자가 그대로 “재사용”할 수 있으므로, 값 자체를 비밀로 취급해야 한다.

개념 2) 쿠키 속성(Secure·HttpOnly·SameSite)

정의: 브라우저가 쿠키를 언제, 어떤 방식으로 전송하거나 접근할지 제한하는 규칙이다.

핵심 특징: Secure는 HTTPS 연결에서만 쿠키 전송을 허용한다.

핵심 특징: HttpOnly는 자바스크립트가 쿠키에 접근하는 길을 막는다.

핵심 특징: SameSite는 다른 사이트에서 들어오는 요청에 쿠키를 얼마나 붙일지 제어한다.

주의점: 속성을 하나만 켜도 전체가 안전해지는 구조가 아니며, 서비스 흐름(로그인, 결제, 외부 연동)에 맞춰 조합해야 한다.

방어 선택 기준: HTTPS·HttpOnly·SameSite를 어떻게 조합할지(비교표 포함)

방어는 “어떤 경로의 탈취를 줄이는가” 기준으로 판단하는 편이 빠르다.

아래 표는 세션 하이재킹 관점에서 자주 쓰이는 조합을 비교한 것이다.

방어 요소	막는 방향	설정이 약할 때 생기는 일	운영 시 주의점
HTTPS(전 구간 강제)	전송 중 도청·변조 위험을 낮춘다	HTTP 섞임 구간에서 쿠키가 노출될 수 있다	리다이렉트·서브도메인·오래된 링크까지 강제해야 한다
Secure 쿠키	HTTPS에서만 쿠키 전송을 허용한다	HTTP 요청에 쿠키가 붙어 나갈 수 있다	개발/스테이징 환경에서도 혼동 없이 적용해야 한다
HttpOnly 쿠키	스크립트가 쿠키를 읽는 경로를 막는다	스크립트 탈취가 가능해져 쿠키 유출이 쉬워진다	프론트에서 쿠키 값을 직접 읽어야 하는 설계라면 구조를 다시 봐야 한다
SameSite 설정	다른 사이트 요청에 쿠키가 붙는 범위를 줄인다	원치 않는 요청에도 세션 쿠키가 동반될 수 있다	외부 결제/로그인 연동이 있으면 동작 검증이 필요하다

아래 판단 체크리스트는 “지금 상태에서 당장 손봐야 할 부분”을 고르는 용도다.

• YES: 세션 쿠키에 Secure가 붙어 있고, HTTP로는 전송되지 않는다
• YES: 세션 쿠키에 HttpOnly가 붙어 있고, 스크립트로 값이 보이지 않는다
• YES: SameSite 값이 의도한 로그인 흐름과 충돌 없이 동작한다
• NO: 네트워크 로그에서 Set-Cookie에 Secure/HttpOnly가 빠져 있다
• NO: 브라우저 개발자 도구에서 document.cookie로 세션 쿠키가 그대로 보인다
• NO: 다른 사이트에서 넘어온 요청에도 세션 쿠키가 예기치 않게 붙는 흔적이 있다

실전 점검 절차: 쿠키가 어디서 새는지 “화면에서” 확인하는 방법

현장에서 필요한 것은 개념보다 확인 순서다.

아래 절차는 “경로/메뉴/체크 포인트”를 포함해 바로 따라 할 수 있게 구성했다.

1. 경로: 브라우저 개발자 도구 → Application(또는 Storage) → Cookies → 대상 도메인 선택체크 포인트: Secure가 표시되는지 확인하고, SameSite 값이 무엇인지 기록한다.
2. 체크 포인트: 세션 쿠키에 HttpOnly가 표시되는지 확인한다.
3. 경로: 브라우저 개발자 도구 → Network → 로그인 요청 선택 → Response Headers의 Set-Cookie 확인체크 포인트: 동일한 쿠키가 여러 번 덮어쓰이는지, 경로(Path)와 도메인(Domain)이 의도와 맞는지 확인한다.
4. 체크 포인트: 서버가 내려준 Set-Cookie에 Secure/HttpOnly/SameSite가 실제로 포함되는지 확인한다.
5. 경로: 브라우저 주소창 → http://로 접속 시도(테스트 환경에서만) → 자동으로 https://로 이동되는지 확인체크 포인트: HTTP로 접근했을 때 세션 쿠키가 전송되지 않는지(네트워크 요청의 Cookie 헤더) 확인한다.
6. 체크 포인트: HTTP 요청이 남아 있지 않은지 확인한다.
7. 경로: 서버/프록시 설정 화면 → HTTPS 리다이렉트, 쿠키 속성 강제 설정 항목 확인체크 포인트: 배포 후에도 동일하게 Set-Cookie가 찍히는지 운영 로그로 재확인한다.
8. 체크 포인트: 특정 경로(로그인, 계정 변경, 결제)에서만 예외가 생기지 않는지 확인한다.
9. 경로: 로그인 후 민감 기능 수행 → 다시 로그인(또는 권한 상승) → 세션 쿠키 값 변화 여부 확인체크 포인트: 로그아웃 후 같은 쿠키로 접근했을 때 서버가 거부하는지 확인한다.
10. 체크 포인트: 로그인 직후 Session ID가 재발급(회전)되는지 확인한다.

세션 하이재킹 방어 점검 플로우(HTTPS→쿠키 속성→재발급)

 

실전 예시 1개: HttpOnly를 빼먹어 쿠키가 스크립트로 읽힌 경우

문제: 특정 페이지에서만 계정 탈취 신고가 반복되고, 피해자는 공용 PC 사용 이력이 없다고 말한다.

왜 발생: 해당 페이지에 스크립트가 삽입될 여지가 있었고, 세션 쿠키에 HttpOnly가 없어 쿠키가 그대로 읽혀 외부로 전송됐다.

어떤 선택이 적합: 세션 쿠키에 HttpOnly를 적용하고, 동시에 Secure와 SameSite를 함께 점검해 전송 범위를 줄이는 구성이 맞다.

잘못 쓰면 어떤 문제: HttpOnly만 추가하고 HTTPS 강제나 SameSite를 방치하면, 다른 경로의 노출 가능성이 남아 운영 불안이 이어질 수 있다.

확인/해결: 개발자 도구에서 document.cookie로 세션 쿠키 노출 여부를 확인한 뒤, 로그인 응답의 Set-Cookie에 HttpOnly가 포함되도록 수정하고, 배포 후 같은 화면에서 재검증한다.

결론

세션 하이재킹은 세션 쿠키가 탈취되어 재사용될 때 현실화된다.

HTTPS 강제와 Secure·HttpOnly·SameSite 조합은 쿠키가 새는 경로를 줄이는 방향으로 작동한다.

브라우저 개발자 도구와 Set-Cookie 확인 절차로 실제 설정이 적용됐는지 검증하는 흐름이 필요하다.

연계 주제 제안: 세션 만료 시간과 재발급(회전) 정책을 운영에 맞게 잡는 방법, 쿠키 도메인/경로(Path) 설계로 노출 면적을 줄이는 방법이 다음으로 이어지기 좋다.

FAQ

HTTPS를 쓰는데도 세션 하이재킹이 발생할 수 있나?

전송 중 도청 위험은 줄어들지만 쿠키가 스크립트로 읽히거나 다른 방식으로 유출되면 피해가 생길 수 있다.

HTTPS와 쿠키 속성은 역할이 달라 함께 점검하는 편이 안전하다.

SameSite는 어떤 값을 선택해야 하나?

서비스가 외부 연동 없이 내부에서만 로그인 흐름이 끝난다면 제한적인 설정이 유리한 편이다.

외부 결제나 외부 로그인 연동이 있으면, 실제 요청 흐름에서 쿠키 전송이 막히지 않는지 검증한 뒤 결정해야 한다.

HttpOnly를 켜면 모든 스크립트 관련 위험이 사라지나?

HttpOnly는 스크립트가 쿠키를 읽는 길을 줄이는 데 초점이 있다.

쿠키 전송 자체를 줄이는 Secure·SameSite, 그리고 HTTPS 강제와 함께 적용했을 때 운영에서 흔들림이 덜하다.