cookie

쿠키를 사용한 상태관리

HTTP는 stateless 프로토콜이기 때문에 과거에 교환했던 리퀘스트와 리스폰스의 상태를 관리하지 않습니다.

이는 과거 상태를 근거로 한 현재 리퀘스트 처리는 어렵다는 것을 뜻합니다.

 

쿠키

이러한 stateless한 특성으로 인해 발생하는 문제를 해결하기 위해 도입된 시스템.

리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트 상태를 파악하기 위한 시스템

서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 쿠키를 클라이언트에 보존하고 다음 리퀘스트 요청에 자동으로 쿠키 값을 넣어서 송신

이로 인해 서버는 클라언트가 보낸 쿠키를 확인하여 어느 클라이언트가 접속했는지나 서버상의 기록을 확인할 수 있다.

 

쿠키 추가 공부

쿠키는 브라우저에 저장되는 작은 크기의 문자열로, RFC 6265 명세에서 정의한 HTTP 프로토콜의 일부입니다.

1. 사용자가 로그인하면 서버는 HTTP 응답 헤더의 Set-Cookie에 담긴 “세션 식별자(session identifier)” : sid 정보를 사용해 쿠키를 설정합니다.
2. 사용자가 동일 도메인에 접속하려고 하면 브라우저는 HTTP Cookie 헤더에 인증 정보가 담긴 고윳값(세션 식별자)을 함께 실어 서버에 요청을 보냅니다.
3. 서버는 브라우저가 보낸 요청 헤더의 세션 식별자를 읽어 사용자를 식별합니다.

쿠키의 한계

쿠키엔 몇 가지 제약 사항이 있습니다.

• encodeURIComponent로 인코딩한 이후의 name=value 쌍은 4KB를 넘을 수 없습니다. 이 용량을 넘는 정보는 쿠키에 저장할 수 없습니다.
• 도메인 하나당 저장할 수 있는 쿠키의 개수는 20여 개 정도로 한정되어 있습니다. 개수는 브라우저에 따라 조금씩 다릅니다.

expires와 max-age

쿠키는 default로 브라우저가 닫힐 때 쿠키도 삭제됩니다. 이를 세션 쿠키라고도 부릅니다.

expires(유효일자)와 max-age(만료 기간)옵션이 지정되어있으면 브라우저를 닫아도 쿠키가 삭제되지 않고 설정된 유효 일자까지 쿠키를 유지하다가 해당 일자에 도달하면 삭제합니다.

쿠키 유효일자는 GMT 포맷으로 설정해야함

예시 : Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT

secure (보안)

이 옵션 설정하면 HTTPS로 통신하는 경우에만 쿠키가 전송됩니다.

https://a.com 에서 설정된 쿠키를 http://a.com 에서 읽을 수 있고 그 반대도 됨

이는 쿠키가 기본적으로 도메인만 확인하고 프로토콜은 따지지 않기 때문입니다.

쿠키에 민감한 내용이 저장되어 있으면 암호화를 위해 https연결만을 사용하도록 이 옵션을 사용하면 됩니다.

samesite(보안)

크로스 사이트 요청위조 (XSRF)공격을 막기 위해 만들어진 옵션입니다.

XSRF : 다른 사이트에서 a사이트의 쿠키를 사용해 요청을 보내는 것

XSRF보호 토큰이라는 특수 필드를 사용하면 되지만 이는 많은 리소스 소비.

samesite 옵션

samesite 옵션으로 “XSRF 보호 토큰” 없이도 크로스 사이트 요청 위조를 막을 수 있다.

 

samesite=strict : default

사용자가 외부 도메인에서 요청이 이루어지는 경우 쿠키 전송하지 않음

→ 이는 메일 등 링크로 입장한 사용자를 인식 못함

⇒ 이러한 문제는 일반 인증용 쿠키, 데이터 교환용 (samesite-strict 옵션이 설정된) 쿠키 두가지를 사용해서 해결 가능

 

samesite=lax : 사용자 경험을 해치지 않으면서 XSRF도 막는 느슨한 접근법

strict와 마찬가지로 외부 요청 쿠키 전송을 막지만 예외 사항 존재

1. GET과 같은 안전한 메서드인 경우 (POST는 안전하지 않음?!) (안전한 메서드는 읽기 작업만 수행하고 쓰기나 데이터 교환 방식은 수행하지 않음) (GET은 캐싱이되니 안전하지 않다고 알고 있는데 이부분에 대한 고민이 필요할듯 합니다.)
2. 작업이 최상위 레벨 탐색에서 이루어질 때 (브라우저 주소창에서 URL변경) iframe 내에서 탐색이 일어나는 경우를 제외하곤 대부분을 만족함, AJAX 요청 또한 조건 충족 X

httpOnly 옵션

httpOnly옵션은 웹서버에서 Set-Cookie 헤더를 이용해 쿠키를 설정할 때 지정

이는 자바스크립트 같은 클라이언트 측에서 쿠키를 사용할 수 없게 하는데 document.cookie 같은 명령어로 쿠키를 볼 수도 조작할 수도 없습니다.

XSS 공격 : 악성 스크립트를 삽입한 페이지에 접속하기만을 기다리는 해킹

httpOnly 옵션은 이러한 공격을 예방할 때 사용합니다.

 

예시 : Set-Cookie: 쿠키명=쿠키값; path=/; HttpOnly

가장 마지막에 HttpOnly라는 접미사만 추가함으로써 HTTP Only Cookie가 활성화 되며, 위에서 말한 XSS와 같은 공격이 차단되게 됩니다. HTTP Only Cookie를 설정하면 브라우저에서 해당 쿠키로 접근할 수 없게 되지만, 쿠키에 포함된 정보의 대부분이 브라우저에서 접근할 필요가 없기 때문에 HTTP Only Cookie는 기본적으로 적용하는 것이 좋습니다.

 

쿠키 사용에서 브라우저 관련 보안 취약점

1) XSS(Cross-Site Scripting) 공격

• 공격자(해커)가 클라이언트 브라우저에 악의적인 스크립트를 삽입해 실행하는 공격이다.
• 보통 javascript같은 브라우저가 읽을 수 있는 코드를 사용하여 서버에서 스크립트를 실행하거나, url에 Javascript를 적어 클라이언트에서 스크립트 실행이 가능하다면 공격자가 사이트에 스크립트를 삽입해 XSS 공격을 할 수 있다.
• 사용자가 의도치 않은 명령을 실행 시키거나 쿠키, 세션 등 민감한 정보를 탈취할 수 있습니다.

2) CSRF(Cross Site Request Forgery) 공격

• 사이트간 위조 요청의 줄임말으로 공격자가 다른 사이트에서 우리 사이트의 API 콜을 요청해 실행하는 공격
• 사용자가 웹사이트에로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

토큰 저장 방식으로만 모든 보안 취약점을 막는 것은 불가능 하지만 저장 위치에 따른 취약점을 인식하고 저장공간을 정하는 것이 중요하다고 생각합니다. 

그리고 이러한 보안적 취약점을 보완하기 위해 jwt토큰을 사용하고 그 내부 로직에서도 탈취의 가능성을 염두해두고 accessToken과 refreshToken 두가지 토큰을 사용하는 것을 알고 있습니다. 나중에 기회가 된다면 이부분도 정리해보려고 합니다!

 

Reference

https://ko.javascript.info/cookie    

https://hoime.tistory.com/94   

https://nsinc.tistory.com/121    

그림으로 배우는 http & 네트워크