웹브라우저와 웹서버의 저장소

Dohyeon Kong·2024년 4월 30일
0

Web🌎

목록 보기
4/5

웹 브라우저와 웹 서버의 저장소

HTTP is a Stateless Protocol

  • Stateless(불연속성)
    - 웹 서버 입장에서 매요청이 웹 브라우저가 보낸 것인지 알 수가 없다.
    => HTTP
  • Stateful(연속성)
    - 웹 서버가 이전에 요청받았던 웹 브라우저와 현재 요청의 웹 브라우저를 구별할 수 있다.
    => 어떤 유저(웹 브라우저)의 요청인지 알 수 있다면, 요청마다 별개의 작업을 수행하고 결과를 반환할 수 있다. Ex) 로그인 계정 정보

Stateful HTTP : Cookie & Session

웹 서버는 웹 브라우저의 요청이 어떤 유저에 의해 요청된 것인지 알기 위해 응답 반환시 요청자 정보를 함께 반환한다.

  • 웹 브라우저는 응답을 받아, 응답 헤더에 붙어있던 요청자 정보를 웹 브라우저 쿠키에 저장한다.
  • 웹 브라우저는 이후 요청부터 웹 서버에게 요청자 정보를 함께 전달하여 웹 서버는 누구의 요청인지 알 수 있다.
    - 요청자 정보란? 어떤 웹 브라우저(유저)가 요청했는지 인지 가능한 정보를 의미한다.
  • 주의해야할 점은 세션도 쿠키를 전송한다는 점!
  • 웹 서버가 웹 브라우저에게 최초로 전달할 때는 웹 서버 응답(Response)의 헤더(=Set-Cookie)로 전송한다.
  • 웹 브라우저가 그 이후에는 웹 서버로 전송할 때는 웹 브라우저 요청(Request)의 헤더(=Cookie)로 전송한다.

  • 쿠키(Cookie)는 어떤 값이든 가능하나, 일반적으로 노출 방지를 위해 인간이 이해할 수 있는 형태가 아닌걸로 값들이 저장된다. (Client 측에서)

  • 세션(Seesion)은 웹 브라우저에 저장할 수 없을 정도로 크거나 복합적인 경우, 웹 브라우저에 저장할 수 없는 민감 정보인 경우 값들이 저장된다. (Server 측에서)

Cookie(쿠키) : 웹 브라우저에 저장하는 것(1)

Cookie(쿠키)는 웹 브라우저 내 저장되는 값으로서,
웹 서버의 제어 + 웹 브라우저 내 저장 및 전송하는 값을 의미한다.

쿠키의 사용 기준 : Domain + Path

  • 웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준이 된다.
    (해당 쿠키를 어떤 요청에 보낼지)
  • 모든 쿠키에는 도메인이 연결되어 있다.

Ex) 웹 브라우저내 저장되어 있는 쿠키 리스트

  • 1번 쿠키 : (Domain : a.com, Path : *)
  • 2번 쿠키 : (Domain : a.com, Path : /)
  • 3번 쿠키 : (Domain : b.com, Path : /hello)
  • 4번 쿠키 : (Domain : b.com, Path : /world)

Ex) 위 리스트 기반으로 아래 웹 서버에 대한 요청에 다라 전송되는 쿠키

  • 웹 브라우저에서 a.com/user/name 호출 시 1번 쿠키 전송
  • 웹 브라우저에서 a.com/ 호출 시 1번 쿠키 + 2번 쿠키 전송
  • 웹 브라우저에서 b.com/hello 호출 시 3번 쿠키 전송
  • 웹 브라우저에서 c.com/ 호출 시 어떤 쿠키도 전송하지 않음

쿠키 유효시간 : MaxAge or Expires

  • 명시되어 있다면 : Persistent Cookie (지속쿠키)
  • 명시되어 있지않다면 : Session Cookie (세션쿠키)

쿠키의 종류

퍼스트파티 쿠키와 서드파티쿠키로 나누어진다.

쿠키 보안 : HttpOnly, Secure, SameSite

  • HttpOnly : XSS(자바스크립트) 공격에 의한 쿠키 접근을 제어한다.
  • Secure : 패킷 탈취(Man-in-the-Middle) 방지를 위해 HTTPS 채널에서만 사용한다.
    • MITM (Man-in-the-Middle) : 요청(클라이언트)-응답(서버) 사이에서 요청, 응답 탈취한다.
  • SameSite : 웹 브라우저 주소란에 표시된 도메인과 동일한 도메인에 대한 요청(API)시에만 쿠키를 전송한다.
    • 동일 사이트 (Same Site) 의 정확한 의미 : www.web.dev 와 static.web.dev 는 Same Site
    • 막지 않는다면 CSRF 공격으로 크로스 사이트 요청 시 크로스 사이트에 과거에 설정됐던 쿠키가 전송 = 크로스 사이트 요청 시, 서드파티(크로스 사이트) 쿠키가 함께 전송된다면 아래의 문제 발생
      • HTTPS 미사용 시 = MITM 로 요청을 가로챈다면 서드파티 쿠키를 외부에서 볼 수 있다
      • HTTPS 사용 시 = 서드파티 쿠키가 로그인, 인증 정보를 담고있다면 어드민 API 호출도 가능
      • 전체 유저 정보 조회, 대량 삭제 등 권한이 필요한 API 호출이 인증정보 쿠키로 손쉽게 가능

Cookie의 단점

  1. 쿠키 정보가 웹 브라우저에 저장되어 있다.
    • 민감 정보들이 안전하지 않은채로 저장되어있다.
    • 물론 HttpOnly, Secure, SameSite로 방어도 가능하고 저장되는 정보들에 대해 웹 서버만의 키로 암호화해놓고, 볼때마다 복호화해서 보면되기도 한다.
    • 웹 브라우저간 공유 불가 : 웹 브라우저 단위의 저장소이다보니 지역성 문제
      • 매 웹 브라우저에서 하는 검색과 같은 행위들이 해당 브라우저에만 저장된다.
  1. 쿠키는 Domain + Path 만 일치한다면 해당 웹 서버로 모든 쿠키를 담아 보내다보니 쿠키로 저장하려는 정보량이 많아질수록 요청 크기가 커진다.
    불필요한 Network Overhaed : 비대해질수록 요청 사이즈도 커진다.
  • 쿠키를 단지 저장소로 써서는 안되는 이유
    - 그렇기에 웹 서버에게 알려주지 않아도 되는 정보의 경우 웹 스토리지 사용을 권장한다.

Storage : 웹 브라우저에 저장하는 것(2)

Storage는 Cookie, Session 처럼 Stateful HTTP 를 위한 기술은 아니다.

  • HTML5 표준에서 Storage 등장 전에는 웹 브라우저 저장소는 유일하게 Cookie 만을 활용해야 했다.
  • HTML5 표준에서 Storage 등장 후에는 웹 브라우저에서 아래 두 유즈케이스를 제대로 나눠 활용할 수 있게 된다.
  • Storage : 웹 브라우저 저장소
    • 유저에 의해 변경된 옵션 상태 등 필요에 따른 조회가 필요할때 (진짜 저장소)
      • 예) 마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할때 표시하여 알려주기
  • Cookie : 웹 서버에게 웹 브라우저가 매번 전달할 특정 정보 전달을 위한 저장(Stateful)
    • 로그인 인증 정보 등 → 웹 서버가 매번 요청때마다 판단해야 할 정보를 대신 전달

쿠키(Cookie)는 HTTP 요청 시 자동으로 서버로 전송이 되며, 사용자 인증과 같이 사용자를 식별할 때 유용하게 사용된다. <= 보안 취약성이 발생할 수 있다.

스토리지(Storage)는 로컬 스토리지와 세션 스토리지로 나뉘면서, 스토리지에 저장되는 데이터는 서버에 전송되지 않는다. <= 보안성이 강화되지만, 클라이언트 사이드에만 사용된다.

  • 웹 브라우저에 저장된다는 점에선 Storage와 Cookie는 동일하다.

  • Cookie : 웹 서버에게 반복적으로 전달하기 위한 + 작은 정보 + (만료 시간을 갖고있고)

  • Storage : 웹 브라우저에서만 사용가능한 + 큰 정보 + (만료 시간 없이)

Storage 의 종류

  • 유효시간에 따라 Storage 종류가 나뉘어진다.

Local Storage : 웹 브라우저 창이 닫혀도 데이터는 영구적으로 저장한다. - 용량 처리를 조심해야 한다.

Session Storage : 웹 브라우저 창이 닫히면 데이터는 삭제된다.

Storage 의 종류별 용례

  • 프론트엔드 개발자가 브라우저에서 무엇인가를 저장한다하면 Storage를 쓰면 된다.
    • 단발적이지만 중요한 내용은 Session Storage, 길게 저장해도 되는 내용은 Local Storage를 사용한다.
    • 예) 최근에 로그인했던 수단을 표기하기 위해 Local Storage 내 수단 저장

Session(세션) : 웹 서버내 저장되는 것(1)

Session은 웹 브라우저 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요하다.

  • 주의 : Session을 학습할때 Cookie vs Session 구도로 학습하기에 오해하기 쉬운것이
    - Session 을 사용한다고, Cookie 를 사용하지 않는건 아니다.
    - 웹 브라우저 내 Cookie 에는 어떤 세션인지 알기위한 ID 값 저장 필요하다.
    - Session 의 대표적인 예는 웹 브라우저로부터 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보 조회를 한다.
    • 속도가 매우 중요 : API 수천번의 호출마다 Session 조회가 필요하며,
      • 메모리 기반 DB 인 Redis 를 많이 사용한다.
        • 메모리 중심 인스턴스의 비용 이슈, 확장성 이슈

Cookie 의 단점을 살펴보고 이를 뒤집으면, Session 의 장점이 된다.

  • 쿠키(Cookie)는 정보를 웹 브라우저에 저장된다.
    • 민감 정보들이 안전하지 않은채로 저장되어있다.
      (HttpOnly, Secure, SameSite 방어는 가능하나)
    • 웹 브라우저간 공유 불가하다
      => 웹 브라우저 단위의 저장소이다보니 지역성 문제,
      • 한 유저가 PC 방을 돌아다니며 매 웹 브라우저에서 매번 로그인 해야한다.
  • 세션(Session)은 정보를 웹 서버측에 저장된다.
    • 민감 정보들이 웹 서버측에 안전하게 저장이 가능하다.
    • 웹 브라우저간 공유가 가능하다.

쿠키는 Domain + Path만 일치한다면 해당 **웹서버로 모든 쿠키를 담아 보낸다. 그러다보니

  • 쿠키로 저장하려는 정보량이 많아질수록 요청 크기가 커진다
    =>불필요한 Network Overhaed : 비대해질수록 요청 사이즈도 커진다

  • Session 은 정보를 웹 서버측에 저장하는것이기에, 아무리 많은 정보를 저장하더라도 요청을 방해하지 않는다.
    =>단, 매 요청마다 Session 저장소에 저장된 세션 정보를 조회해야하므로, 빠른 DB 인 Redis 고려할것
profile
Dohyeon Kong
천천히, 꾸준히, 그리고 끝까지
이전 포스트

Web의 구성과 흐름

다음 포스트

웹보안 : HTTPS와 웹 브라우저에서의 CORS

0개의 댓글