iamkanguk.dev

[HTTP] HTTP Header PART1 - 일반 헤더 (인증과 쿠키) 본문

CS지식/Network

[HTTP] HTTP Header PART1 - 일반 헤더 (인증과 쿠키)

iamkanguk 2024. 1. 9. 02:35
해당 포스팅은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 토대로 작성된 글입니다.

 

 

인증

출처: https://hseungyeon.tistory.com/447

 

Authorization (요청)

- 클라이언트 인증 정보를 서버에 전달할 때 사용한다.

- value 값은 인증 방식에 따라 다양하다. 우리가 흔히 아는 Bearer도 이에 해당한다.

WWW-Authenticate (응답)

- 리소스 접근 시 필요한 인증 방법을 정의

- 401 Unauthorized 응답과 함께 사용한다.

 

쿠키 (Cookie)

<쿠키 미사용>

 

- 로그인하지 않은 사용자가 서버에 /welcome을 요청하게 되면 서버는 ~손님을 응답한다.

- 사용자가 id, password 정보를 담아서 서버에 /login을 POST로 요청하면 서버에서는 로그인 성공 응답을 할 것이다.

- 그리고 사용자가 로그인을 한 후에 /welcome을 요청하면 서버는 로그인한 사용자임을 구분할 수 없기 때문에 ~손님을 응답한다.

 

그러면 여기서 서버는 왜 로그인한 사용자임을 알 수 없을까? 그 이유는 HTTP는 무상태(Stateless) 프로토콜이기 때문이다.

- 클라이언트와 서버가 요청 및 응답을 주고받은 후 연결이 즉시 끊어진다.

- 클라이언트가 재요청을 하게 되면 서버는 이전 요청을 기억하지 못한다.

- 클라이언트와 서버는 서로 상태를 유지 하지 않는다.

 

그러면 모든 요청과 링크에 사용자 정보를 포함하면 되지 않느냐? => 이렇게 되면 모든 요청에 사용자 정보가 포함되도록 개발을 해야한다. 개발자가 힘들어진다.

 

그래서 우리는 쿠키를 사용해서 위와 같은 문제를 해결할 수 있다.

 

<쿠키 사용>

 

웹 브라우저가 id, password를 담아서 로그인 요청을 서버에게 보내면 서버에서는 Set-Cookie에 유저 정보를 담아서 클라이언트에 응답한다. 이 때 쿠키는 클라이언트 웹 브라우저의 쿠키 저장소에 쿠키를 저장한다.

 

 

웹 브라우저에서는 이후 요청에서 자동으로 Cookie를 포함시킨다. 따라서 로그인을 하고 나서 /welcome을 서버에 요청하게 되면 서버에서는 쿠키를 까서 로그인한 유저를 확인하고 응답을 한다.

 

 

그래서 모든 요청에 쿠키 정보가 자동으로 포함되는 것이다. 이렇게 되면 모든 요청과 링크에 사용자 정보를 담을 필요가 없기 때문에 간결해지고 가시성이 좋다.

 

<쿠키 생성 및 접근 과정 정리>

[1] 클라이언트가 id, password를 담아 서버에 로그인 요청을 한다.

[2] 서버에서는 id, password 검증이 완료되면 사용자에게 sessionId(쿠키)를 생성한다.

[3] 서버는 Set-Cookie에 sessionId를 담아서 클라이언트에게 로그인 성공을 응답한다.

[4] 클라이언트는 쿠키 저장소에 sessionId(쿠키)를 저장한다.

[5] 이후 클라이언트가 쿠키 접근가능한 도메인에 요청을 보낼 때 마다 자동으로 쿠키 저장소에서 꺼낸 쿠키를 Cookie 헤더에 담아 서버에 요청을 보낸다.

[6] 서버는 쿠키의 유효성을 검증해서 클라이언트를 식별한다.

 

쿠키 설정옵션

 

쿠키 정보는 항상 서버에 전송된다. 그렇게 되면 네트워크 트래픽 추가 유발이 될 수 있기 때문에 최소한의 정보만 사용한다. 보통 세션id나 인증 토큰만을 담기도 한다.

 

참고로 쿠키 정보를 서버에 전송하지 않고 클라이언트에서 그 정보를 갖고있는 방식을 쓰고 싶으면 localStorage, sessionStorage를 참고하면 된다. 이 때 보안에 민감한 데이터는 저장하면 안된다.

(1) 생명주기

- expires, max-age

- expires는 만료 날자를 설정할 수 있는 것이다.

- max-age는 초단위로 설정할 수 있다.

 

참고로 쿠키의 종류는 크게 2가지가 있다.

- 세션 쿠키: 만료 날짜를 생략하게 되면 브라우저 종료시까지만 유지한다.

- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지가 된다. 브라우저가 종료되어도 클라이언트 시간이 남아있는 한 유지가 된다.

(2) 도메인

- domain

- 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함 적용

  -- domain = example.org를 지정하고 쿠키를 생성했다.

  -- example.org와 dev.example.org (서브도메인)도 쿠키에 접근할 수 있다.

- 생략: 현재 문서 기준 도메인만 적용

  -- example.org에서 쿠키 생성, domain 지정 생략

  -- example.org에서만 쿠키에 접근할 수 있다.

  -- dev.example.org (서브도메인)은 쿠키에 접근할 수 없다.

(3) 경로

- path

- 이 경로를 포함한 하위 경로 페이지만 쿠키에 접근할 수 있다.

- 일반적으로 path=/ (루트)로 지정한다.

 

(4) 보안

- Secure, HttpOnly, SameSite

- Secure: https인 경우에만 쿠키를 전송한다. 참고로 쿠키는 http, https를 구분하지 않고 쿠키를 서버에 전송한다.

- HttpOnly: XSS 공격 방지 목적으로 사용한다. 자바스크립트에서 document.cookie를 통해 접근할 수 없다. 오로지 HTTP 전송에서만 쿠키를 사용한다.

- SameSite: XSRF 공격 방지 목적으로 사용한다. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다.

 

올라온 질문 정리

(1) HTTP 통신을 하는 상황에서 로그인을 한 후 Set-Cookie로 발급받은 쿠키 정보를 해커에게 탈취당하면 해커는 해당 쿠키를 이용해 제 아이디로 로그인한 상황이 되는건가요?

- 해커에게 쿠키를 탈취당하면 큰일난다. 이는 쿠키 뿐만 아니라 대부분의 인증에서 동일한 문제가 있다. 그래서 암호화를 위해 HTTPS를 사용하고 추가로 session의 생존 기간을 짧게 가져가야 한다.

(2) HttpOnly는 HTTP 전송에서만 쿠키를 사용한다고 했는데, HTTPS에서는 사용할 수 없다는 의미인가?

- 쿠키는 javascript로 document.cookie를 이용해서 로컬 PC에 저장된 쿠키를 조회할 수도 있다. HttpOnly는 자바스크립트로 해당 로컬 PC에 저장된 쿠키를 조회하는 기능을 막는다는 것에서 HTTP 전송에서만 쿠키를 사용한다고 표현한 것이다. 여기서 말하는 HTTP는 HTTP와 HTTPS를 구분하는 것이 아니다.

(3) 쿠키와 세션? 세션 쿠키에서 쿠키의 만료날짜를 생략하면 브라우저 종료시까지만 쿠키를 유지한다고 했는데, 서버에서는 웹 브라우저가 종료되었다는 사실을 모를텐데 언제까지 세션을 보관하고 있나?

- 쿠키는 브라우저(클라이언트), 세션은 서버에서 관리하는 정보다.

- 세션쿠키는 만료 날짜를 생략하면 브라우저 종료시까지만 유지된다는 것. 즉, 쿠키의 만료 날짜를 설정하지 않을 시 브라우저를 닫게 되면 브라우저에 저장한 해당 쿠키를 날려버린다는 것이다.

 

- 서버가 특정 클라이언트에 대한 정보를 기억하기 위해 쿠키 값을 매번 받아서 내부에 있는 세션 값과 비교하는 방식으로 사용하는 것이다.

- 프레임워크나 개발자에 따라 세션은 다르게 설정될 수 있다. Spring boot의 경우 기본 1800초로 세션이 지속되고 maxIntervalTimeout으로 특정 세션값을 마지막으로 사용한 시점으로부터 어느정도 지나면 서버에서 세션값을 지우게 된다.


참고자료

- https://hseungyeon.tistory.com/447

 

[모든 개발자를 위한 HTTP 웹 기본 지식] 07. HTTP 헤더1(일반헤더) - 인증, 쿠키

(인프런) 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 리뷰한 글입니다. 7. 인증 인증 헤더 종류 설명 사용 헤더 사용 목적 Authorization 클라이언트 인증 정보 요청 인증 방식에 따

hseungyeon.tistory.com