[10분 테코톡] 파인의 쿠키와 웹 스토리지 정리

쿠키

 

등장배경

 

HTTP는 비연결성과 무상태성의 특징을 가지고 있기 때문에 한번 서버에 요청하고 응답을 받으면 연결이 끊기게 된다. 그러면 다음에 서버에 또 요청하면 서버는 이 클라이언트가 누군지 식별을 할 수 없게 된다. 만약에 연결이 끊겨도 기억하고 싶은 정보가 있다면 어떻게 할까?

 

 

그래서 쿠키가 등장하게 된 것이다. 쿠키가 요청시에 서버에서 유저의 정보를 저장해서 보내주면 클라이언트에서는 이 쿠키와 함께 다음 요청시에  서버에서는 클라이언트가 누군지 식별할 수 있게 된다.

 

 

정의 및 특징

브라우저에 저장되는 key와 value로 이루어진 작은 크기의 문자열

 

1) 4KB의 크기 제한

2) 만료 시간 설정 가능

3) HTTP 요청시 따로 설정하지 않아도 자동으로 전달

 

실제 예시를 본다면 위와 같이 오늘의 집에 접속하면 설정이 되는 쿠키가 열일곱개가 있다. 이 쿠키가 하위 도메인의 이미지를 요청하면 실제 요청 쿠키에 가면 열일곱개의 쿠키가 자동으로 전달되는 것을 볼 수 있다.

 

 

활용 예시 - N일 동안 보지 않기 기능

모달에서 버튼을 눌렀을 때 document에 modalClose 속성에 true라는 값을 설정 해주고 expires(만료날짜)를 N일 후까지로 설정해 줄 수 있다 그러면 클라이언트에서는 modalClose이 존재하고 유효하다면 쿠키를 확인해서 모달을 띄우지 않는 식으로 활용을 할 수 있다.

 

 

단점

1) 4KB의 작은 용량밖에 저장할 수 없다.
2) HTTP 요청 시에 모든 쿠키가 자동으로 전달되기 때문에 원하지 않는 정보까지 전달되어 불필요한 트래픽이 증가하게 된다.

3) XSS 공격에 취약하다.

4) XSRF 공격에 취약하다.

 

XSS 공격은 공격자가 악성스크립트를 삽입해서 브라우저에서 실행시키도록 하는 공격이다. 만약에 홈페이지에 인풋이 있는데 그 인풋에다 악성코드를 포함한 스크립트를 직접 입력했을 때, 예를 들어서 document.cookie 나 localstorage.getItem 에서 사용자의 정보를 조회하는 식으로 실행을 하면 사용자의 정보 탈취가 가능하게된다. 테스트를 위해 alert('XSS') 라고 했지만 이게 만약에 악성코드라고 하면 실제로 실행될 것이다.

 

 

XSRF는 사용자인 척 악성 리퀘스트를 보내는 공격이다. 예를 들어서 bank.com 에 로그인을 했다고 하고 유저의 정보가 쿠키에 저장이 되어 있다고 가정한다. 또한 공격자가 bank.com에 어떤 사람에게 돈을 송금하는 리퀘스트를 이미 알고 있다고 가정한다. 이제 공격자가 어떤 위조된 사이트 attack.com에 접속하도록 유도를 했을 때 이미지 소스에 리퀘스트 URL을 설정하고 디스플레이 none을 하면 나도 모르는 사이에 bank.com에 요청되었고 유저에 내 정보가 저장되어 있기 때문에
성공된 요청으로 간주해서 이러한 공격이 통할 수 있게 되는 것이다.

 

 

단점 해결법

기본적으로 XSS 공격을 방지하기 위해서 HttpOnly 속성을 제공하고 있다. 속성은 자바스크립트로 쿠키를 줘야 하는 것을 방지해서 위에서와 같이 document.cookie 이렇게 조회하는 것을 막는 설정이다. 또한 XSRF 공격을 막기 위해서 SameSite 속성을 제공하고 있다. SameSite 사이트 속성은 strict 해주게 되면 사이트와 같은 도메인 요청에만 쿠키를 전송하게 된다.
그러면 위에서 본것과 같이 attack.com 에서 bank.com에 요청을 했는데 다른 도메인이기 때문에 쿠키가 전송되지 않게 된다. 또 Secure 속성을 제공해서 HTTPS 로 통신하는 경우에만 쿠키가 전송될 수 있도록 설정할 수 있다.

 

 

Web Storage (웹스토리지)

 

특징

웹스토리지는 HTML5 부터 지원하는 브라우저의 데이터를 저장하는 API 이다.
웹스토리지는 다음과 같은 특징이 있다. 쿠키는 4KB의 정보를 저장 가능했는데 웹스토리지는 브라우저마다 조금씩 다르지만 5MB의 정보 저장이 가능하고, 쿠키와 달리 자동으로 서버에 전송되지 않기 때문에 쿠키의 트래픽 문제를 해결할 수 있다는 점이 있다. 그 다음으로 오리진 단위로 접근이 제한이 되는데 오리진 단위란 HTTP, HTTPS의 프로토콜, 도메인, 포트 번호로 이루어진 것이 오리진 단위이다. 그래서 위에서 본것과 같이  bank.com, attack.com은 도메인이 달라 접근이 제한되기 때문에 CSRF로부터 기본적으로 안전하다.

 

종류와 활용 예시

웹 스토리지는 로컬 스토리지와 세션 스토리지로 나눌 수 있다. 로컬 스토리지에 저장범위는 도메인 별로 저장범위가 달라지지만 세션 스토리지는 도메인 별 그리고 탭 별로도 저장범위가 달라진다. 로컬 스토리지는 직접 삭제하기 전까지는 데이터가 영구적으로 남아 있어서 직접 삭제해야 삭제가 되고 세션 스토리지는 브라우저나 탭을 닫을 때 데이터도 같이 삭제하게 된다. 그 다음에 로컬 스토리지의 활용 예시는 글을 임시로 저장하거나 사용자 설정 같은 것을 저장해 놓을 때 활용할 수 있고 세션 스토리지는 입력폼을 임시로 저장하거나 일회성 로그인 등에 사용할 수 있다.

 

예시를 살펴보기 위해 현재 벨로그에 설정되어 있는 로컬 스터리지를 기지고 왔다. 벨로그의 테마가 다크모드로 설정되어 있으면 다음 번 벨로그에 접속했을 때 로컬 스토리지 때문에 다크모드로 접속이 될 것이다. 
세션 스토리지는 예를 들어서 결제하기 창에서 결제정보를 다 입력해놓고 결제하기를 눌렀을 때 결제 중 창으로 넘어간다. 만약에 거기서 결제를 취소하고 결제하기 페이지에 다시 왔을 때 결제 정보가 지워져 있으면 짜증이 날 수 있다. 여기서 세션 스토리지를 활용하면 이 정보가 다시 복구될 수 있게 활용할 수 있다.

 

단점

1) 만료기간 설정 불가

2) 동기적으로 실행되기 때문에 용량이 큰 데이터 같은 경우 메인 쓰레드가 블로킹 돼서 실행이 되기 때문에 비동기적으로 처리되는 IndexedDB를 고려해 보는 방법도 있다.

3) 미지원하는 브라우저나 사파리 시크릿 모드는 할당량이 영어로 되어 있어서 에러처리가 필요하다.

4) XSS 공격에 취약하다. 사용자 입력이 자바스크립트 코드로 실행될 수 있는 코드를 (document.cookie 같은 코드)  작성하지 않는 식으로 방지할 수 있다.

 

 

프론트엔드에서 그럼 중요한 정보를 쿠키, 로컬 스토리지 중 어디에 저장해야 할까?
특히 프론트엔드에서 사용자 인증을 위해 사용하는 JWT 토큰 같은 경우에 어디에 저장하는 것이 좋을까?

정답은 없다.

 

---

참고

https://www.youtube.com/watch?v=c7eLPK9RzEM&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC