Cookie(쿠키)란?

복습!

HTTP

• HTTP is a stateless Protocol
  • Stateless (무상태성):
    • 다음 프로세스는 누가(WB) 어떤 요청을 했는지 알 수 없음
    • 매번 요청할 때 마다 인증이 필요하다
    • 구현하기 위해 JWT (JSON Web Token)이 필요하다
    • 최소한의 자원으로서버 유지를 가능하게 한다
  • Stateful (상태성):
    • 다음 프로세스가 이전에 누가(WB) 어떤 요청을 했는지 알 수 있음
      • 요청마다 별개의 작업 수행 및 결과 반환 가능
      • 서버가 여러개일 경우, 어떤 서버를 호출해도, 서버에 장애가 생기더라도 다른 서버가 역할을 대신할 수 있다
    • 매번 요청할 때 마다 인증이 필요없다
      • 최초의 한번만 필요하다
      • WS가 WB에게 최초로 전달해줄때: WS 응답(Response) 헤더 Set-Cookie로 전송한다
        • WB가 이후로 웹 서버에게 전달할때: WB의 요청(Request) 헤더 Cookie로 전송한다
    • 구현하기 위해 Cookie + Seesion이 필요하다
      • Cookie: WB에 정보 저장
        • Ws로 정달하는 내용:
          • Key-value 값
          • Domain
          • Path
          • Expires
      • Session: WS에 정보 저장
        • 쿠키를 안쓰는게 아닌, WB 쿠키에 SEESION_ID를 저장하는 것
        • 언제 사용하는가?
          • WB에 저장할 수 없을 정도로 크거나 복잡한 정보
          • WB에 저장할 수 없을 정도로 민감한 정보
    • WS는 WB의 요청이 어떤 유저에 의해 요청된 것인지 알기 위해 응답 반환시 요청자 정보를 함께 반환한다
      • WB는 정보를 받아 응답 헤더 (Response Header)에 붙어있던 요청자 정보를 웹 브라우저 쿠키에 저장한다
      • WB는 이후 요청부터 WB에게 요청자 정보를 함께 전달하여 WS는 누구의 요청인지 알 수 있다

  ---

  Cookie

웹 서버의 제어 + 웹 브라우저 내 저장 및 전송

• 
  
  • 사용기준: Domain + Path
    • 같은 Domain임에도 불구하고 각 페이지마다 받고자 하는 쿠키가 따로 있다
  • 모든 쿠키에는 도메인이 연결되어 있다!
    • Domain + Path로 쿠키에 *어떤 요청을 보낼지 항상 명시를 해줘야한다 *
      • Path is case-sensitive
  • 쿠키 유효시간: MaxAge / Expires
    • Persistent Cookie (지속 쿠키): 지속시간이 명시되어있다면
    • Session Cookie (세션 쿠키): 지속시간이 명시되어 있지 않다면
      • Session이란?
        • "단발성": 창을 닫으면 없어진다
        • 열고(Connect) -> 닫힘(Disconnect)의 하나의 Pair에 모두 사용된다
        • ex.)
          • 로그인 세션: 로그인한 후 -> 로그아웃까지
          • HTTP Session: TCP/UDP 연결 후 Request 전송 후 -> Response 받기까지
          • Browser Session: 하나의 탭/창이 열리고 닫히기 까지
  • 쿠키 보안: HttpOnly, Secure, SameSite
    • 왜 보안이 중요한가?
      • 누구인지 식별이 가능해진다
      • 인증 완료 여부 판단을 위한 쿠키가 탈취되면, 해커가 해당 유저인것처럼 속일 수 있음
    • HttpOnly:
      • XSS (JS) 공격에 의한 쿠키 접근 제어
      • XSS (Cross Site Scripting): 외부에서 심은 JS를 실행 시킬 수 있다
      • JS로 쿠키를 읽을 수 없게 (숨긴다) 방지 설정을 한다
    • Secure:
      • MITM (Man-in-the-Middle: 패킷 탈취)를 방지하기 위해 HTTPS 채널에서만 사용한다
      • 통신 채널이 노출되지 않는다
      • HTTP라면 다른 사람도 통신 내용을 볼 수 있어 HTTPS 채널에서만 사용한다
        • 요청 (Client) - 응답 (Server) 사이에서 탈취가 가능하다
    • SameSite:
      • WB 주소란에 표시된 Domain과 동일한 Domain에 대한 요청(API)시에만 쿠키를 전송한다
      • CSRF 방지
        • Cross-Site Request Forgery: 유저가 의도하지 않았는데 해커가 심은 스크립트에 의해 크로스 사이트에 요청이 전달된다
          • 해당 Cross Site에 접속해서 얻은 로그인 인증 정보가 함께 전달됨
          • HTTPS를 사용해도 Third Party가 인증 정보를 담고 있다면 Admin API 호출도 가능하기에 매우 위험하다
          • HTTPS를 사용하지 않아도 MITM로 요청을 가로챈다면 Third Party Cookie를 외부에서 볼 수 있다
            • Third Party란?
              • Cookie의 Domain이 다르다면 Third Party Cookie로 판단한다
              • 많은 페이지를 오가며 행동을 기록 및 추적하기 위한 정보 수집을 한다
                • ex.) Google Ads
              • First Party Cookie란?
                • 인증 정보를 저장하는데 쓰인다
                • 현재 도메인에서 필요에 따라 생성 / 저장한 로그인 인증과 같은 개인화 정보 인식용 쿠키
                  

                  

                • Generate (채번): 각각 구별하기 위해 할당하는 ID
        • Cross Site: www.web.dev != static.another.com
        • Same Site: www.web.dev == static.web.dev
      • Cross Site 요청시 Third Party Cookie를 담을지 말지 결정할 수 있다
        • 3 가지 보안 레벨
          • 최고레벨(Strict): 퍼스트 파티 쿠키 전송만 허용한다
            • Strict로 잠굴 시 Third Party를 사용하지 못하게 할 수 있다
            • 발행된 key-value를 통해 Third Party에 담아 요청할 수 없다
              • 그래서 Frontend에서 API를 호출하는게 불가능해져 Backend에서 서버호출로 바꿔야한다
          • 중간레벨(Lax): 서드파티 쿠키라도 특수 케이스엔 부분 허용한다
            • 현재의 Chrome 설정
            • 특수케이스: 서버의 상태를 변경하지 않고 조회만 가능한 요청
              • ex.) GET, ,
                • prerender이란?
                  • UX를 향상시키기 위함
                  • 방문전에 자주 방문하던 페이지를 미리 Rendering하여 더 빨리 볼 수 있게 해준다
          • 낮은레벨(None): 서드 파티 쿠키 모두 허용
            • Secure (Secure = True)설정을 강제하여, HTTPS 미사용시 MITM 탈취에대한 문제를 방지한다
• 쿠키의 단점:
  • 쿠키가 WB에 저장되다보니 민감한 정보들이 안전하지 않은채로 저장되어있다
    • HttpOnly, Secure, Samesite로 방어가 가능하다
    • 저장되는 정보들에 대해 WS만의 키로 암호화해놓고, 필요할때마다 복호화해서 보면 된다
  • WB간의 공유가 불가능하다
    • WB단위의 저장소이다보니 지역성 문제가 발생한다
      • ex.) 매 WB에서 하는 검색과 같은 행위들이 해당 브라우저에만 저장된다
    • Session으로 해결 가능!
  • Cookie는 Domain + Path만 일치한다면 해당 WS로 모든 쿠키를 담아 보내다보니
    • 쿠키로 저장하려는 정보량이 많아질수록 -> 요청 크키가 커진다
      • 불필요한 Network Overhead (쿠키가 커질수록 요청 사이드도 커지는 상황)이 발생한다
        • 이 때문에 쿠키를 단순 저장소로 쓰면 안된다
        • WS에게 알려주지 않아도 되는 정보는 Web Storage로 사용하는게 났따
    • 이것또한 Session으로 해결 가능하다