쿠키 세션 토큰의 차이를 이해하고, 쿠키 사용 시의 XSS CSRF 예방 알아보기

쿠키

쿠키는 stateless 방식으로 클라이언트의 상태를 유지할 때 사용합니다.

 

▶ 특징

- 쿠키는 보안이 취약하다

쿠키는 F12 의 Network 탭으로도 쉽게 조작이 가능하고, 볼 수 있는 만큼 보안에 취약합니다.

그렇기에 쿠키 단독으로 쓰지 않고 쿠키의 무결성을 위해 세션/JWT와 함께 쓰입니다.

 

- 클라이언트측에서 관리하며, 이를 stateless 방식이라 합니다.

 

-브라우저에 저장된 쿠키는 모든 요청에 포함되어 서버에 전송됩니다.

이는 쿠키가 필요없는 요청에 대해서도 네트워크 트래픽을 추가로 유발하게 됩니다.

그렇기에 쿠키를 사용할 때는 네트워크 트래픽을 줄이기 위해 최소한의 정보만 포함되어야 합니다.

또한, 쿠키를 사용하면 해당 특징을 악용한 CSRF 공격에 노출되기 쉽습니다.

세션

세션은 stateful 방식으로 클라이언트의 상태를 유지할 때 사용합니다.

 

▶ 특징

서버측에서 관리하며, 이를 stateful 방식이라 합니다.

장점으로는 사용자의 상태를 서버가 관리할 수 있습니다.

그러나, 단점으로는 세션이 많아질 경우, 서버 부하 문제가 발생합니다.

또, 서버가 확장될 경우 각 서버에 세션 정보를 동기화 해야합니다.

 

토큰

토큰은 stateless 방식으로 클라이언트의 상태를 유지할 때 사용합니다.

 

▶ 특징

- 토큰에는 서버가 개인키로 만든 서명이 담겨 있으며, 서버는 토큰의 서명을 공개키로 검증할 수 있습니다.

- 토큰은 stateless 방식입니다.

서버가 토큰을 관리하지 않기 때문에 서버 부하 문제가 해결되고, 서버 확장 시 문제가 되지 않습니다.

그러나, 사용자의 상태를 제어할 수가 없습니다.

예를 들어, 토큰이 탈취되어 비정상 요청이 들어오더라도 사용자를 강제 로그아웃 시킬 수 없습니다.

단 1개의 기기에서만 로그인을 유지하고 싶은 서비스일 경우, 토큰이 아닌 세션을 사용해야 합니다. 

 

JWT

JWT 는 클라이언트-서버, 서비스-서비스 간 인가를 위해 사용하는 토큰입니다.

 

▶ 구조

- 문자열로 구성되어 있기 때문에 URL, HTTP 헤더 등 어디에 위치할 수 있습니다.

- JWT는 Header.Payload.Signature(헤더.페이로드.서명 으로 이루어지며, 점(.)으로 구분됩니다)).

 

1. Header(헤더)

헤더는 JWT를 어떻게 검증하는지를 나타냅니다.

{
    "alg": "ES256",
    "kid": "Key ID"
}

alg 는 서명 시 사용하는 알고리즘, kid 는 서명이 사용하는 키(Public/Private Key) 를 식별하는 값입니다.

 

해당 JSON 객체를 문자열로 만들고 UTF-8 과 Base64 URL-Safe 로 인코딩하면 아래와 같은 헤더를 생성합니다.

인코딩 과정 -> Base64URLSafe(UTF-8('{"alg": "ES256","kid": "Key ID"}')) 
결과 -> eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9

 

* Base64 URL-Safe : 인코딩 결과를 URL과 파일 경로에서 안전하게 사용하기 위해 고안됐습니다.

+ 기호를 -(하이픈)으로 대체

/ 기호를 _(언더스코어)로 대체

= 기호는 필요에 따라 제거

 

2. Payload(페이로드)

페이로드는 클라이언트와 서버 간 주고 받기로 한 값으로 구성됩니다.

{
    "iss": "jinho.shin",
    "iat": "1586364327"
}

인코딩 과정 -> Base64URLSafe('{"iss": "jinho.shin","iat": "1586364327"}') 
결과 -> eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ

 

3. Signature(서명)

점(.)을 구분자로해서 헤더와 페이로드를 합친 문자열을 서명한 값입니다.

서명은 헤더의 alg 에 정의된 알고리즘과 비밀 키를 사용해 생성하고 인코딩합니다.

인코딩 과정 -> Base64URLSafe(Sign('ES256', '${PRIVATE_KEY}',
'eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ')))

결과 -> MEQCIBSOVBBsCeZ_8vHulOvspJVFU3GADhyCHyzMiBFVyS3qAiB7Tm_MEXi2kLusOBpanIrcs2NVq24uuVDgH71M_fIQGg

 

* 서명 vs 암호화

서명은 데이터가 변조되지 않았음을 확인하는 무결성을 증명하지만 암호화는 데이터를 보호하여 허가된 사람만 읽을 수 있게 하는 과정입니다. 토큰은 탈취 당해서 토큰의 값을 누구나 읽을 수 있기 때문에 암호화라고 설명하는 것은 부적절합니다.

 

XSS 와 CSRF

클라이언트의 상태를 유지하기 위해 사용하는 쿠키/세션/토큰의 보안 방법에 대해 소개하겠습니다.

어떻게 보안할 지를 알려면 XSS와 CSRF 에 대해 먼저 알아야 합니다.

 

▶ XSS ( Cross-Site Scripting )

XSS는 공격자가 사용자(일반 고객)의 브라우저에 스크립트가 실행되게 함으로써 세션을 가로채거나, 웹사이트 변조, 악의적 콘텐츠 삽입, 피싱 공격을 합니다.

 

 

추가로, XSS 는 자바스크립트에서 사용되는 <, >, ', " 와 같은 특수문자를 &lt; , &gt; 등의 HTML entity 로 치환하여 입력하도록 하고, HTML태그 사용이 필요한 경우, 사용 태그를 지정하여 해당 태그만 허용하도록 할 수 있습니다.

 

▶ CSRF ( Cross-Site Request Forgery )

CSRF( cross site request forgery attack ) 는 사용자가 인증한 세션에서 서버가 정상적인 요청과 비정상적인 요청을 구분하지 못한다는 점을 악용한 방식입니다. 사용자 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우에 발생합니다. 

 

즉, XSS 는 사용자 PC에서 스크립트를 실행해 사용자의 정보를 탈취하지만, CSRF는 요청을 위조함으로써 사용자 몰래 송금과 제품 구입등 특정 행위를 수행합니다.

 

쿠키 사용 시 보안 방법

그렇기 때문에 세션과 토큰이 로컬/세션 스토리지에 저장이 될 경우, XSS 공격으로부터 자유로울 수 없습니다(브라우저에서 스크립트로 인해 탈취될 가능성이 있기 때문)

 

그래서, 쿠키는 보안관련 속성들을 제공합니다.

 

- HttpOnly 

HttpOnly 속성은 자바스크립트에서 쿠키에 접근이 불가능 하게 함으로써 XSS 공격을 방지합니다.

 

- Secure

쿠키는 http, https 를 구분하지 않고 전송되기 때문에 https 인 경우만 전송이 되게 하는 Secure 속성을 제공합니다.

 

- SameSite=Strict

모든 요청에 쿠키를 넣어서 보내는 브라우저의 특성을 악용한 CSRF 를 막기위해 쿠키는 SameSite=Strict 속성을 지원합니다.

SameSite=Strict 속성은 브라우저로 하여금 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송하게 합니다.

만약, 쿠키를 사용하지 않고 세션과 토큰을 스토리지에 저장을 하면 CSRF 로 부터 조금은 자유로워질 수 있지만 XSS 공격으로부터 자유롭지 못하게 됩니다.

 

그래서, 쿠키를 사용할 때는 HttpOnly + Secure + SameSite=Strict 조합을 사용하여 XSS 와 CSRF 공격으로 부터 예방해야 합니다.

그러나, 완벽히 예방할 수 없기 때문에 추가적인 작업을 요구합니다.

 

클라이언트는 XSS 공격을 막기 위해 스크립트에 사용되는 <, >, ‘, “ 등의 특수문자를 &lt; , &gt; 등의 HTML entity로 치환하여 입력하거나 HTML 태그 사용이 필요한 경우, 사용한 태그를 지정하여 해당 태그만 허용합니다.

 

서버는 추가적으로 CSRF Token, Synchroniza token pattern, double-submit cookie, client-side secure 등 추가적인 작업이 필요하다고 합니다. 해당 내용들은 Wikipedia 의 CSRF 에서 가져왔으며, 보안보다는 개발에 흥미가 있는 저로써는 여기서 글을 마무리 할까 합니다. 글 읽어 주셔서 감사합니다.

 

 

 

 

출처

- MDN

Using HTTP cookies

 

- StackOverflow

Does this JWT implementation prevent XSS and CSRF attacks while still giving me access to payloads?

 

- StackExchange: Security 

Do I need CSRF token if I'm using Bearer JWT?

Should I use CSRF protection on Rest API endpoints?

Securely using JWTs with CSRF protection and refresh tokens

 

- blog

Store JWT in cookie or localstorage ?

Do SameSite Cookies Solve CSRF?

 

- 김영한님의 HTTP 강의

- JSCODE 의 JWT