웹브라우저의 캐시 #3. 쿠키(Cookie)
브라우저의 작은 데이터 조각.
쿠키는 보통 어떻게 설정되냐 사용자가 서버에 요청
사용자가 서버 페이지 내놔하면 서버는 set-cookie라는 응답헤더에 설정한 쿠키를 보낸다.
다음부터 이 사용자가 쓰고있는 브라우저는 해당 쿠키값을 가지고 있게 됨
그 다음 서버에다가 요청을 할 때 자동으로 쿠키가 요청헤더의 쿠키라는 키를 가진 헤더를 추가해서 요청이 되고 브라우저에도 저장되게 된다.
쿠키는 클라이언트와 서버 둘 다 조작이 가능하지만 보통 서버에서 만료 기한 등을 설정 및 컨트롤 함
저장용량 최대 4Kb
로그인, 장바구나, 사용자 커스터마이징, 사용자 행동분석(주로 개인화된 광고에 활용되는 것들)에 사용
클라이언트에서도 설정 가능한 쿠키
- 클라이언트에서 자바스크립트 - document.cookie를 통해 쿠키를 설정할 수 있고 보낼때도 header - Cookie에 값을 정해서 보낼 수도 있다. (권장X)
왜 권장 X? -> 이렇게되면 쿠키에대한 제어권을 클라이언트에게 두게 되는데 쿠키는 보통 민감한 정보들이 담길수도 있기 때문에 이 제어권에 관한 것을 클라이언트가 아닌 서버에 두게 만들어야한다.
== (네이버 서버가 해킹당할 확률 vs 내 폰 해킹될 확률 당연히 내폰이 높음 ㅇㅇ
보안이취약하겠지? 쿠키는 사용자도 되고 서버도되지만 서버에 두라는게 이런 이유)
세션쿠키
- Expires 또는 Max-Age 속성을 지정하지 않은 것. 브라우저가 종료되면 쿠키도 사라짐
영구쿠키
- Expires 또는 Max-Age 속성을 지정해서 특정날짜 또는 일정기간이 지나면 삭제되게 만든 쿠키.
브라우저를 닫을 때 만료되지 않음
secure
- 쿠키에 secure 옵션을 추가하면 https로만 쿠키를 주고받을 수 있게 하는 옵션이다.
하지만 Chrome v89 및 Firefox v75이상부터 localhost에서는 이 사양을 무시함.
-> 위 버전의 브라우저는 http라도 localhost라면 secure 옵션을 걸어도 http로 쿠키를 주고 받을 수 있어 쉽게 테스팅이 가능함
httponly
- 공격자가 쿠키를 자바스크립트로 빼낼 수 없게 만든다. (document.cookie로 접근 불가)
samesite
쿠키의 시큐어코딩
- 쿠키 - 세션으로 로그인을 처리한다면 다음과 같이 시큐어 코딩을 해야한다.
- cookie에 세션 ID를 담을 때 이 세션 ID를 기반으로 클라이언트의 개인정보를 유추할 수 없게 해야 한다.
- 자바스크립트로는 파악할 수 없게(document.cookie로 추출불가능하게) httponly 옵션을 걸고 https로만 쿠키를 주고받을 수 있게 secure옵션을 걸어야 한다.
- 일정시간의 세션 타임아웃을 걸어야 한다.
쿠키허용관련 알림창
- 서비스 운용시 쿠키를 사용한다면 쿠키허용관련 알림창을 만들어야한다.
-> 방문기록을 추적할 때 쿠키가 사용되기 때문
이는 사용자의 데이터 간접수집에 해당하며 거기에 해당하는 KISA(한국인터넷진흥원) 지침을 준수해야하기 때문이다.