브라우저가 만든 쿠키~ 세션을 위해 구 웠 지

내가 만든 쿠키~

 

그럼 브라우저가 만든 쿠키는?

누구를 위해 구웠을까요?

 

브라우저 쿠키라고도 하고 웹 쿠키라고도 불리는 HTTP 쿠키는

기본적으로 HTTP 통신을 기반으로 하며

브라우저에서 돌아가는 웹사이트나 웹 애플리케이션에서 널리 사용되고 있습니다.

 

 

1. 브라우저가 만든 쿠키?

HTTP의 쿠키를 실제 쿠키에 비유하자면

헨젤과 그레텔이 돌아갈 길을 잊지 않기 위해 (돌아갈 길을 찾기 위해) 사용한 쿠키와 비슷합니다.

HTTP의 쿠키는 HTTP 요청을 보내는 클라이언트를 식별하기 위한 것이라 할 수 있습니다.

 

즉 클라이언트 측(브라우저)에서 관리되는 작은 기록 정보 파일,

서버가 어떤 데이터를 브라우저 측에 저장한 후 다시 그 데이터를 받아오는 기술 또는 그 데이터 자체를 뜻합니다. 따라서 쿠키가 제대로 작동하기 위해서는 무엇보다 브라우저의 역할이 가장 중요합니다.

 

브라우저가 원격에 있는 서버와 네트워크를 통해 쿠키를 주고받으려면 둘 간에 일정한 약속이 필요하겠죠?

 

이 약속은 바로 HTTP 프로토콜 상에서 구현되며

쿠키는 HTTP 메시지의 헤더(header) 영역을 통해서 송수신되도록 약속이 되어 있습니다.

(쿠키를 확인하고 싶다면, 주소창 자물쇠 아이콘을 클릭해 보세요!)

쿠키의 메커니즘 쿠키를 기술적으로 제대로 이해하려면 브라우저와 서버가 어떤 과정을 거쳐 쿠키를 주고받으며 HTTP 통신을 하는지 알아야 합니다.

쿠키는 <이름>=<값> 형태를 지니는 단순한 문자열입니다.

서버와 브라우저는 기본적으로 HTTP 메시지 안에 이 쿠키를 담아서 주고받게 됩니다.

< 쿠키 동작 방식 >

쿠키의 동작 방식과 구성 요소 등

자세한 내용은 쿠키, 세션, 토큰, 인증방식 비교 글을 참고해 주세요!

 

 

2. 누굴 위해 구웠나?

쿠키가 왜 필요하게 되었을까요?

서버는 뭐하러 이리 수고를 들여서 굳이 데이터를 브라우저에 저장하려고 하나 의문이 생깁니다.

그냥 깡그리 데이터를 서버에 저장해두면 편할 것 같은데요.

지금보다 서버 비용이 만만치 않았던 예전에는 클라이언트 측에 데이터를 저장할 요구가 컸었고

이 부담을 덜고자 데이터를 클라이언트에 저장하기 위한 쿠키가 고안되었던 것입니다.

 

 

쿠키의 한계

쿠키가 브라우저, 즉 클라이언트 측에 저장된다라는 것은 상당히 널리 알려진 사실인데요. 이 부분은 쿠키가 탄생하게 된 중요한 배경이며, 안타깝게도 갖가지 이슈의 원흉이기도 합니다.

따라서 쿠키를 사용할 때는 아래와 같은 쿠키의 한계점들을 잘 인지하고 사용하는 것이 중요합니다.

 

 

1. 쿠키는 유실되기 쉽다.

대부분 브라우저는 환경 설정에서 쿠키 일괄 삭제 기능을 제공하며, 웹사이트 별로도 어렵지 않게 쿠키를 삭제할 수 있습니다. 또한 특정 브라우저가 하드디스크의 어느 경로에 쿠키를 저장하는지는 구글링을 해보면 누구나 쉽게 파악할 수 있어서 통째로 폴더를 삭제해버릴 수도 있습니다. 그러므로 유실되면 안 되는 중요한 데이터는 쿠키로 브라우저에 저장하면 안 됩니다.

 

2. 변조되기 쉽다.

브라우저의 개발자 도구를 사용하면 각 웹사이트 별로 현재 어떤 쿠키가 저장되어 있는지 한눈에 파악할 수 있으며 쿠키를 손쉽게 변경할 수 있습니다. 이를 통해 서버가 브라우저로 보낸 쿠키와 전혀 다른 쿠키를 서버에 돌려보낼 수도 있으며, 심지어 서버가 저장한 적이 없는 새로운 쿠키를 만들어서 서버에 보낼 수도 있습니다. 뿐만 아니라 프록시 서버를 이용해서 브라우저에서 보낸 쿠키를 중간에서 변조해서 서버에 보내는 것도 충분히 가능한 일입니다. 따라서 서버에서는 브라우저로부터 수신한 쿠키 데이터가 유효한지 검증할 필요가 있습니다.

Cross-Site Scripting (XSS)

 

3. 도난되기 쉽다.

클라이언트의 컴퓨터에 저장되는 쿠키는 항상 온갖 해킹의 위험에 노출되어 있습니다. 아무리 클라이언트 단에서 개개인이 보안에 신경을 쓴다고 해도 기업이 소유하고 있는 서버 단의 보안 수준에 비할 바가 못되겠죠. 클라이언트에 저장되어 있는 쿠키가 탈취되는 것을 서버 입장에서 막을 수 없습니다. 따라서 개인 정보와 같이 민감한 데이터를 쿠키를 사용해서 저장하는 것은 위험합니다.

 

4. 쿠키의 보안 속성

이러한 쿠키의 한계와 대체 기술에도 불구하고 반드시 쿠키를 사용해야 하는 상황이라면 가급적 보안 속성을 사용해야 합니다.

 

(1) Secure

Set-Cookie 응답 헤더에 Secure 속성이 명시된 쿠키는 브라우저가 https 프로토콜 상에서만 서버로 돌려보냅니다. 네트워크 상에서 탈취되었을 때 문제가 될 수 있는 쿠키를 상대로 쓰면 유용할 것입니다.

Set-Cookie: <쿠키 이름>=<쿠키 값>; Secure

 

 

(2) HttpOnly

Set-Cookie 응답 헤더에 이 속성이 명시된 쿠키는 브라우저에서 자바스크립트로 Document.cookie 객체를 통해 접근할 수 없습니다. 그래서 서드 파티 자바스크립트 코드가 쿠키에 접근하는 것을 제한할 수 있습니다.

 

 

쿠키의 대체 기술

서버 자원이 풍족한 현재는 순수하게 데이터를 클라이언트 측에 저장하기 위한 용도로서의 쿠키를 잘 사용하지 않는 추세입니다. 대부분의 모던 브라우저가 로컬 스토리지나 세션 스토리지와 같은, 쿠키를 대체할 수 있는 웹 스토리지 기술을 지원하고 있기 때문입니다. 게다가 웹 개발의 패러다임이 백엔드에서 프런트 앤드로 옮겨오면서 예전보다 많은 코드가 서버가 아닌 브라우저에서 실행되고 있습니다. 굳이 브라우저에 저장되어 있는 데이터를 서버로 전송하지 않고도 자바스크립트로 해당 데이터에 쉽게 접근할 수 있게 되었죠.

이러한 웹 스토리지 기술과 쿠키를 비교했을 때, 쿠키의 최대 단점은 매 요청마다 같은 데이터가 서버로 전송됨에 따른 네트워크 대역폭 낭비입니다.

 

 

그럼 이 쿠키를 어따 쓰지?🤔

이런 어마어마한 단점들에도 불구하고 쿠키가 아직 웹에서 활발하게 사용되는 이유는 바로

세션이라는 환상의 짝꿍이 있기 때문입니다.

쿠키의 단점이었던 '브라우저에 저장하기 때문에 유실/변조/도난되기 쉽다'가 서버 측에서 관리되는 세션을 만나게 됩니다. 결국 세션을 위해 구운 쿠키가 되었네요ㅎㅎ 저는 이 가사가 더 좋은 것 같아요.

이에 대한 내용은 다음 링크를 참고해 주세요.

 

Stateful과 Stateless, 쿠키와 세션

 

어텐~션~~ /(^^)/

 

 

참고 :

https://blog.naver.com/ghdalswl77/222517833354 https://www.daleseo.com/http-session/