쿠키와 세션(Cookie & Session )

지난번 http 방식과 websocket 방식에 대해서 정리를 했는데, 백엔드 개발에서 세션과 쿠키에 대해서 함께 물어보는 경우가 많은 것 같다. 정확하게는 세션과 쿠키의 사용목적과 약점, 보안방안을 함께 묻는 것 같다. 세션과 쿠키도 한번 정리를 해야겠다.

[ 쿠키 ]

• 서버에서 필요로하는 클라이언트 정보를 클라이언트가 서버에 요청을 보낼 때 자동적으로 헤더에 붙여서 전달하도록 구현하는 매커니즘의 구현체
• 클라이언트 로컬에 저장되는 키와 값들이 들어있는 파일
• 클라이언트의 상태 정보를 브라우저에 저장하여 참조
• 구성 요소 : 이름, 값, 만료시간, 전송할 도메인 이름, 전송할 경로, 보안 연결 여부, HttpOnly여부
• 취약점 : 브라우저의 쿠키관리 탭, 쿠키 플러그인을 설치하면 쉽게 조작이 가능하다. 따라서 암호화가 필요하다. 그래서 Secure과 HttpOnly 에 저장된다.
• 참고 : 링크

[ 세션 ]

• 웹서버와 브라우저 사이의 논리적인 연결
• 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술
• 서버가 발행하고 서버에서 관리하는 정보

동작 순서 : https://chrisjune-13837.medium.com/web-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98%EC%9D%B4%EB%9E%80-aa6bcb327582

[ 쿠키와 세션의 차이점 ]

쿠키와 세션의 차이점은 아래와 같다.

쿠키 데이터의 영속성은 로컬에서 쿠키를 삭제하기 전까지는 영속성이 보장된다고 볼 수 있다. 다만 세션 쿠키는 라이프 사이클 상 그렇지 못하다.

https://coyagi.tistory.com/entry/%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9-%EC%BF%A0%ED%82%A4-%EB%B0%8F-%EC%84%B8%EC%85%98%EA%B4%80%EB%A6%AC

[사용 목적]

Http 프로토콜이 가지는 약점으로 connectionless와 stateless를 커버하기 위한 목적으로 쓰인다.

쿠키는 보통 아래 내용으로 쓰인다.

• ID 저장, 쇼핑몰 장바구니
• 광고에서 ‘몇일간 다시보지 않기’ 기능
• 사용자 추천 광고 기능

세션은 보통 아래 내용으로 쓰인다.

• 사용자 트랙킹 : 사용자 행동과 패턴을 분석가능. 세션 ID가 할당되어 있기 때문에 그 ID를 기반으로 사용자의 행동 분석가능

[세션과 쿠키를 적용한 기능에서 발생되는 문제점]

표현이 정확한지를 모르겠다. 문제가 생기는 상황에 대한 서술이 조금 더 필요한 듯.

쿠키기반 광고

쿠키를 기반으로 광고를 하는 경우에 흔히 접하는 부분은 소비자의 개인정보 이슈가 많은데, 반대로 쿠키를 조작하거나 재발급을 통해서 광고 서비스를 교란하는 행위들도 있다.

흔히 많은 광고서비스들이 광고에 대한 조회수가 많을 수록 해당 광고를 게시한 블로그나 게시판 운영자들에게 광고수익을 지급한다. 이 경우 쿠키 정보를 기반으로 어뷰징을 방지하지만, 쿠키가 쉽게 조작되는 이유로 회사가 손실을 볼 수 있다.

세션을 기반으로 하더라도, 브라우저를 변경하는 등의 방법으로 회피가 가능하다. 이걸 막기위한 방안은 무엇인가?

정책적인 방법

네이버 광고 수익을 얻어본 경험으로 보건데 100% 막는 것은 불가능하다는 생각이든다. 그래서 광고를 눌렀을 경우에 그 링크를 통해서 광고하는 대상을 얼마나 사이트를 돌아다니면서 탐색을 했는지를 기준으로 광고비를 다르게 산정해서 지급하는 것으로 알고 있다.

기술적인 방법

일단 자바스크립트에서 액세스 할 수 없도록 쿠키의 속성을 지정하여 조작이 불가능하도록 하는 방법이 생각이 난다.

세션 보안 이슈

링크의 블로그가 잘 정리되어 있는 듯하다.