세션 하이재킹(Session Hijacking)
웹 애플리케이션의 보안에서 세션은 사용자의 신뢰와 인증을 유지하는 핵심 요소입니다. 하지만 이 세션이 공격자에게 탈취된다면? 사용자는 모르게 로그인 정보가 털리고, 민감한 정보가 유출될 수 있습니다.
이 글에서는 세션 하이재킹(Session Hijacking)의 개념과 종류, 방어 방법에 대해 깊이 있게 설명합니다.
1. 세션 하이재킹이란?
세션(Session)은 사용자가 로그인 등 인증 과정을 완료한 뒤, 서버가 사용자를 식별하기 위해 유지하는 상태 정보입니다. 세션 하이재킹(Session Hijacking)은 공격자가 사용자의 세션을 가로채서, 그 세션을 도용하는 공격 기법을 의미합니다.
즉, 인증된 사용자인 척하면서 웹 애플리케이션에 접근해 민감한 정보를 빼내거나, 계정을 조작할 수 있습니다.
왜 세션이 중요한가?
- 로그인 상태 유지 : 사용자가 로그인하면, 서버는 클라이언트에 세션 ID를 부여하고, 이를 기반으로 사용자를 식별합니다.
- 상태 없는 HTTP 보완 : HTTP는 본래 상태를 기억하지 않는 프로토콜이기 때문에 세션이 반드시 필요합니다.
- 보안상의 핵심 : 세션 ID가 곧 사용자 인증 정보를 대신하는 셈이므로, 이 정보가 유출되면 큰 보안 위협이 됩니다.
2. 세션 하이재킹의 주요 기법
다양한 방법으로 세션이 탈취될 수 있으며, 대표적인 기법은 다음과 같습니다:
a. 세션 스니핑(Session Sniffing)
세션 스니핑은 네트워크 상의 데이터를 몰래 들여다보는(패킷 스니핑) 기법으로, 사용자가 로그인할 때 주고받는 세션 ID를 가로채는 방식입니다. 주로 HTTP 통신을 사용하는 웹사이트에서 발생하며, 암호화되지 않은 트래픽이 공격자에게 그대로 노출됩니다.
공공 Wi-Fi나 개방형 네트워크처럼 누구나 접근 가능한 환경에서는 이런 공격이 특히 위험합니다.
공격자는 패킷 분석 도구(Fiddler, Wireshark 등)를 사용하여, 피해자의 요청에 포함된 세션 ID를 추출하고, 이 세션으로 서버에 접속하여 사용자인 척 행세할 수 있습니다.
b. 크로스 사이트 스크립팅(XSS)
XSS는 공격자가 악성 JavaScript를 웹 페이지에 삽입해, 브라우저에서 쿠키나 세션 정보를 탈취하는 방식입니다. 주로 게시판, 댓글, 검색창 등에 스크립트를 숨겨서 사용자 브라우저에서 실행되도록 유도합니다. 세션 ID가 document.cookie에 저장되어 있다면, XSS는 이를 쉽게 가져갈 수 있습니다.
[사용자] <--- HTTP 요청/응답 ---> [서버]
↑
[공격자: 패킷 스니핑]
c. 세션 고정(Session Fixation)
공격자가 미리 정한 세션 ID를 피해자에게 주입하고, 피해자가 그 세션으로 로그인하게 유도하는 방식입니다. 서버가 로그인 후에도 세션 ID를 변경하지 않으면, 공격자는 해당 세션 ID로 인증된 상태를 가로챌 수 있습니다.
1. 공격자: http://example.com?sessionid=abcd1234
2. 피해자: 위 링크 클릭 → 로그인
3. 서버: 세션 ID 그대로 유지
4. 공격자: abcd1234 세션으로 접근 가능
d. Malware/Keylogger 활용
악성코드나 키로거를 피해자 PC에 설치하여, 입력된 로그인 정보나 세션 ID를 직접 가로채는 방식입니다. 클라이언트 환경 자체를 탈취하는 방식이므로 방어가 어려우며, 백신 우회나 피싱 메일 등을 통해 감염되는 경우가 많습니다.
3. 세션 하이재킹 방어 방법
a. HTTPS 전면 적용
HTTPS는 클라이언트와 서버 간의 데이터를 암호화하여, 세션 ID가 네트워크에서 노출되지 않도록 보호합니다. 세션 스니핑이나 중간자 공격(MITM)을 막기 위해 모든 페이지에 HTTPS를 적용하는 것이 중요합니다.
또한, HSTS 헤더를 설정하면 브라우저가 해당 사이트를 항상 HTTPS로만 접속하도록 강제할 수 있어 보안을 더욱 강화할 수 있습니다.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- 이 설정은 브라우저가 해당 사이트에 대해 항상 HTTPS로 접속하도록 강제합니다.
b. HttpOnly, Secure 쿠키 설정
세션 ID를 브라우저의 쿠키(cookie)에 저장하는 경우가 많기 때문에, 이 쿠키를 안전하게 관리하는 것이 매우 중요합니다.
- HttpOnly 속성을 설정하면 JavaScript로 쿠키에 접근할 수 없게 되어 XSS를 통한 탈취를 방지할 수 있습니다.
- Secure 속성을 설정하면 HTTPS 연결을 통해서만 쿠키가 전송되어, 평문 통신 중 유출을 막을 수 있습니다.
Set-Cookie: sessionid=abcd1234; HttpOnly; Secure; SameSite=Strict
c. 세션 타임아웃 설정
사용자가 일정 시간 동안 활동하지 않으면 자동으로 세션을 종료하도록 설정합니다. 이는 세션 탈취 후 공격자가 악용할 수 있는 시간을 줄입니다.
// 예: 30분 비활성 시 로그아웃
app.use(session({
cookie: { maxAge: 30 * 60 * 1000 } // 30분
}));
d. 사용자 에이전트(User-Agent), IP 주소 확인
세션을 생성할 때 클라이언트의 IP 주소나 브라우저 정보(User-Agent)를 기록하고, 이후 요청에서 이를 비교하여 세션 탈취 여부를 감지할 수 있습니다.
if (storedIP !== request.ip || storedUserAgent !== request.headers['user-agent']) {
// 세션 탈취 가능성 → 강제 로그아웃 등 조치
}
- 단, 모바일 환경에서는 IP가 자주 변경될 수 있으므로 무작정 차단하면 사용자 경험이 나빠질 수 있습니다.
e. 세션 재발급(Session Regeneration)
사용자가 로그인하거나 중요한 보안 작업을 수행할 때마다 새로운 세션 ID를 발급하여, 세션 고정 공격(Session Fixation)을 방지할 수 있습니다.
req.session.regenerate(function(err) {
if (!err) {
// 새 세션 발급 후 안전하게 처리
}
});
f. XSS 방지
XSS는 세션 하이재킹의 주요 경로이므로, 이를 사전에 차단하는 것도 매우 중요합니다.
- 입력 값 필터링 및 이스케이핑 처리
- CSP(Content Security Policy) 헤더 적용
- 외부 스크립트 신뢰 도메인 제한
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
4. 마무리
개발자는 항상 "공격자가 세션을 탈취했을 때 어떤 일이 벌어질 수 있을까?"를 염두에 두고, 보안을 기본 전제로 시스템을 설계해야 합니다.
함께 보면 좋은 자료
블로그 글 :
[CSRF와 XSS] 웹 보안의 핵심
CSRF와 XSS 웹 애플리케이션을 개발하면서 반드시 고려해야 할 것이 바로 보안입니다. 특히 CSRF(Cross-Site Request Forgery)와 XSS(Cross-Site Scripting)는 자주 언급되지만, 정확한 차이나 방어 방법이 헷갈리
dachaes-devlogs.tistory.com
'시스템 지식 > 보안' 카테고리의 다른 글
[세션 쿠키] 로그인 보안을 위한 세션 쿠키 (0) | 2025.04.22 |
---|---|
[Access Token과 Refresh Token] 개발자를 위한 인증 토큰 설명서 (0) | 2025.04.14 |
[JWT의 구조] Header, Payload, Signature의 역할과 의미 (0) | 2025.04.14 |
[JWT] 인증 시스템의 핵심 (0) | 2025.04.14 |
[OpenID Connect] OAuth로는 부족했던 인증을 해결하다. (0) | 2025.04.13 |