Security trend

We will deliver the up-to-date security information timely.

[보안동향] Security Cookie Option Same-Site

2020-01-23
  1. 개요

웹 브라우저에는 사용자가 해킹에 쉽게 노출되지 않도록 여러 보안 정책들을 지원합니다. 그 중 Same-Site라는 Cookie Option은 CSRF 공격을 방지할 수 있는 보안 설정이며 파이어폭스 브라우저에서는 현재 Default지만 Chrome 브라우저에서는 올해 곧 업데이트 예정인 80 버전부터 Default로 적용될 예정입니다.

 

  1. 적용되는 버전

Chrome >= 80 ~

 

  1. 설명 및 분석

먼저 아래는 현재 사용되고 있는 Cookie Option 입니다.

 

Secure

- https와 같은 암호화 통신에서 요청할 경우 쿠키 전송

- 암호화 통신 목적

 

 

HttpOnly

- Javascript로 접근 불가

- XSS 방지

 

 

Same-Site

- Option Mode에 따라 쿠키 전송 여부 결정

- CSRF 방지

 

그 중 Same-Site 설정에는 3가지 mode가 존재합니다.

Strict

- 사용자가 직접 주소창에 입력하는 Top-level navigation으로 접근해야 Cookie설정

- Ex) Cookie=cookie; SameSite=Strict;

 

Lax

- Strict에 비해 조금 느슨하게 Cookie 설정

- Ex) Cookie=cookie; SameSite=Lax;

 

None (Normal)

- Option 끄기

 

 

실제 a tag 및 form action으로 cookie설정이 어떻게 되는지 보겠습니다.

먼저 Strict, Lax, None 설정으로 3개의 cookie를 서버로부터 받아놓은 상태 입니다.

 

 

 

 

그 다음 다른 도메인에서 위의 도메인을 요청합니다.

 

먼저 a tag로 접근했을 때는 Lax, None 으로 설정된 Cookie로 페이지를 요청합니다.

 

Post 요청으로 접근했을 땐 None으로 설정된 Cookie로 페이지를 요청합니다.

 

Get으로 요청했을 땐 Lax, None 으로 설정된 Cookie로 페이지를 요청합니다.

 

Strict mode의 경우 Top-level navigation으로 접근할 경우에만 Cookie가 설정됩니다.

 

아래는 도메인 접근 방식에 대해 설정되는 Cookie 입니다.

 

위에서 보이듯이 SameSite 설정으로 인해 외부 도메인에서 오는 CSRF 공격을 방지할 수 있습니다.

하지만 정확한 숙지 없이 설정을 한다면 아래와 같은 문제가 생길 수 있습니다.

  1. Strict mode로 설정 시 서비스 내에서의 Link 및 Redirect에도 문제가 생길 수 있음
  2. Strict 및Lax로 설정 시 외부 도메인에서의 접근 시 서비스 이용이 제한적일 수 있음

Ex) 이메일을 통해서 들어오는 Link, 다른 서비스에서의 Redirect 등

 

특히 Strict mode의 경우 사용자가 직접 주소창에 입력해야만 Cookie를 설정하여 페이지를

요청하기 때문에 CSRF 공격 방지에 매우 효과적이지만 서비스적인 요소에서는 불편함을 야기할 수 있습니다.

 

즉, 잘못 설정하게 되면 상용화 및 사용자의 편의성에 문제가 생기게 됩니다. 그래서 현재 Google 쪽에서는

Github를 통해 자주 사용하는 서버 사이드 언어에 대해서 SameSite 사용법에 대한 가이드를 제공하고 있습니다.

 

  1. 효과

1) CSRF 방지

- csrf token을 사용한 시큐어 코딩을 하지 않아도 csrf 대응이 가능

 

 

LIST