| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- TypeScript
- 웹개발자
- 프론트엔드
- spring boot
- 자바스크립트
- frontend
- 수제비
- JS
- Front-End
- JWT
- spring boot security
- Authentication
- Node.js
- 스프링부트
- security
- 타입스크립트
- 리액트
- 백엔드
- React
- 백엔드개발자
- 정보처리기사 실기
- 정보처리기사
- TS
- It
- spring
- Redux
- VUE
- 큐넷
- JavaScript
- useState
- Today
- Total
솔적솔적
너는 어디에 저장할 것인가, 그 이유는 무엇인가(브라우저 저장소 결정1편) 본문
자동로그인, 로그인 상태 유지 기능을 구현할 때 고민했던 문제이다.
브라우저 저장소를 어떤 걸 적용할 지 결정할 때,
아, 나 로컬스토리지 써봤으니까 그거 써야겠다~라는 생각은?
않하느니만 못하다~
git에 푸시 전에 불안하잖아~
정말 이 선택이 맞는지~
HTTP의 기본 특성부터
먼저, 서버와 클라이언트가서로 소통할 때 지켜야할 규약인 HTTP,
HTTP는
1. 클라이언트가 request를 보내고
2. 서버가 클라이언트한테 받은 request대한 response를 보내고 접속을 종료한다.(통신 끝)
이는 인증에 쓰이는 상태정보를 유지하지 않는 무상태(Stateless) 프로토콜, 비연결성, 무상태성 특징이 있다.
이 특징(비지속적인 통신 연결)때문에 자원 낭비가 줄어드는 것은 장점이지만
통신을 할 때마다 다시 요청해서 응답받고, 다시 요청해서 응답받고 인증을 해줘야하는 단점이 있다.
지금 이 로그인 저장도 그러하다.
웹 사이트에서 로그인을 해도 페이지가 이동될 때마다 로그인을 다시 또 하고, 또 하고 해야하는 귀찮음이 있다.
그래서 이걸 서버에 요청 안하고 브라우저에 저장을 해두어 로그인상태를 유지하게 할 수 있는데
클라이언트와 서버에 좋은 점이 많다.
속도면에서도 서버에 저장하지않고 클라이언트에서 저장해놓으면 다음에 그 정보가 필요할 때 바로 꺼내올 수 있으니 네트워크를 통하지 않으니 속도면에서 빠름,
속도가 높아지면 비용도 낮아지고 서버로 전송되지않으니 클라이언트에 안전하게 보관된다면 비밀성에 있어서도 좋다.
이 때 브라우저 저장소가 종류별로 있다.
브라우저 저장소의 종류
웹스토리지
- 세션 스토리지
- 로컬 스토리지
- 쿠키
- indexedDB
모두 해당 도메인에 대하 데이터를 브라우저 저장한다.
쿠키(Cookie) 는
서버 ↔ 클라이언트에서 주고받는 작은 문자열 파일. 요청 시 Header에 자동 전송.
브라우저에 저장되는 작은 크기의 문자열만 저장됨
요청 시 header에 전송되며 주로 서버에서 사용된다. 또한 만료 기간 지정 가능하다.
또한 쿠키는 '만료 기간' 에 따라 영구 쿠키(Persistent Cookies)와 세션 쿠키(Session Cookie)로 나뉜다.
영구 쿠키는 만료기간이 끝난 후 삭제,
세션 쿠키는 브라우저 종료 시 삭제된다.
같은 도메인인지 아닌지로 구분하는 퍼스트 파티 쿠키와 서드 파티 쿠키로도 나뉜다.
모든 브라우저에서 지원하는 장점이 있지만
CSRF 사용자의 권한을 이용한 공격, XSS 사용자의 민감한 정보 탈취(토큰),
부족한 저장 용량 4KB
HTTP 요청 시 자동으로 모든 쿠키에 전송하여 불필요한 트래 필 증가
즉, 매번 서버에 전송이 되고 저장 용량이 작고 보안에 취약하다는 단점이 있다.
이런 HTML5부터는 쿠키의 단점을 보안해 등장한 웹 스토리지를 주로 사용한다.
쿠키의 부족한 저장 용량 문제를 해결할 수 있게 5MB의 저장 용량을 가지고 있으며
요청 시 Headers에 전송하지 않는다. 이는 쿠키의 CSRF, 트래픽 문제를 해결한다.
문자열만 저장가능하여 직렬화를 통해 객체 저장이 가능하다.
웹스토리지는 서버로 전송되지 않는다는 다른 점이 있지만 클라이언트에 저장만 할 뿐. 또한 key와 value의 형태로 저장을 한다.
웹스토리지는 로컬스토리지와 세션스토리지로 나눠지는데 이 둘은 지속성에 따라 쓰임새가 달라진다.
로컬스토리지는 브라우저 자체에 반영구적으로 데이터를 저장하고 브라우저를 종료해도 데이터가 유지된다.
저장 범위에 따라도 다른데 로컬 스토리지는 도메인, 브라우저
세션스토리지는 도메인, 브라우저, 탭에 저장가능하다.
세션 스토리지는 탭 윈도우 단위로 생성되고 탭 윈도우를 닫을 때 데이터가 삭제된다는 특징이 있다.
하지만 이런 웹스토리지도 문제점이 있느데
XSS 자바스크립트로 접근이 가능하고
독립된 스토리지로 브라우저와 탭 (세션 스토리지)간에 공유가 불가하다.
쿠키와 다르게 만료 기간 설정도 불가하며
동기적으로 실행하여 메인 스레드 블로킹, 용량이 크다면 IndexedDB를 고려해야한다.
indexedDB는 저장공간이 각 브라우저에 따라 정책이 다르다. 데이터를 비교적 많이 저장할 수 있다.
쿠키와 로컬스토리지는 문자열만 저장가능한데 인덱스드디비는 어떤 테이터 타입도 저장가능, 제한이 없다.
동작방법 또한 쿠키나 로컬스토리지는 동기식이지만 indexedDB는 비동기식이다.
그럼 이제 어떤 유형의 데이터를 어디에 저장하면 좋을까?
쿠키나 웹 스토리지같은 경우엔
보안 문제가 있기 때문에 민감한 정보는 저장하지않는 걸로 한다.
쿠키는 기간을 설정하거나 서버로 전송되어야하는 작은 용량인 데이터인 경우에 사용가능함으로
어떤 웹 사이트에 들어가면 나오는 팝업창 중 "7일 동안 보지 않기", "다시보지 않기" 이런거, 이런거 쿠키로 저장하는 것이 적절하고 각 스토리지의 특성을 살려서 자동 로그인 기능은 로컬 스토리지에
입력 폼 정보, 비로그인 장바구니 기능, 이전 페이지 저장, 이전 스크롤 위치 저장 같은 것은 세션 스토리지에
로컬 스토리지 같은 경우는 사용자 설정 저장, 글 임시 저장 같은 것을
보안 강화 방법
그럼 이 쿠키 보안 문제로 해결할 수 있는 방안은 뭘까?
XSS 해결 방안은 HttpOnly로 가능하다. 이거는 자바스크립트로 접근이 불가하다,
CSRF의 해결 방안으로는 SameStie로 같은 도메인의 요청에만 쿠키를 전송하도록 한다.
웹 스토리지 보안 문제를 해결할 수 있는 방안은 뭘까?
XSS로는 innerHTML 사용하지 않는 것이다. 이유는 자바스크립트 코드 삽입 불가하기 때문이다.
자동로그인·로그인 저장은 단순히 ‘편리함’을 위해 구현하는 기능이지만, 잘못된 저장소 선택은 보안 사고로 직결된다.