✴️ 일반 정보
• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소
• User-Agent: 유저 에이전트 애플리케이션 정보
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
• Date: 메시지가 생성된 날짜
From
From 은 일반적으로 잘 사용되지는 않지만, 검색 엔진 같은 곳에서 유저 에이전트의 이메일 정보를 넣을 때 사용한다.
Referer
Referer 은 현재 요청된 페이지의 이전 웹 페이지 주소를 가리킨다. 예를 들어, A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청한다.
따라서 이 필드를 사용해 유입 경로 분석이 가능하다.
User-Agent
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36User-Agent 는 클라이언트의 애플리케이션 정보(웹 브라우저 정보)를 나타낸다.
이 필드를 사용해 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있으며, 이를 통계 정보에 활용할 수 있다.
Server
Server: Apache/2.2.22 (Debian)Server 는 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 나타낸다. 클라이언트가 요청을 보낼 경우 많은 캐시 서버, proxy 서버 등을 거치게 되는데, 그들을 거쳐 최종으로 요청을 받는 서버를 ORIGIN 서버라고 한다.
Date
Date: Tue, 15 Nov 1994 08:12:31 GMTDate 는 메시지가 발생한 날짜와 시간을 나타낸다.
✴️ 특별한 정보
🧩 Host
Host 헤더는 클라이언트가 요청한 호스트 정보(도메인)를 나타낸다. 하나의 IP 주소에 여러 도메인이 적용되어 있을 때나 하나의 서버가 여러 도메인을 처리해야 할 때 이 필드 값을 통해 구분할 수 있다.
클라이언트의 요청 메세지에 Host 헤더가 없는 경우를 살펴보자. 이 요청 메세지를 받는 서버는 하나의 IP 주소에 총 3개의 도메인이 적용되어 있기 때문에, 클라이언트에게 어떤 도메인을 응답해야 할지 알 수 없다.
따라서 클라이언트가 요청 메세지에 Host 헤더를 통해 호스트 정보를 정확하게 기재해주면, 서버는 이를 확인하여 대응하는 도메인으로 응답할 수 있다.
🧩 Location
웹 브라우저는 3XX 응답의 결과에 Location 헤더가 있을 경우 Location 위치로 자동으로 이동(Redirect)한다.
201 (Created) 의 경우에도 Location 헤더를 사용하는데, 이때 Location 값은 클라이언트의 요청에 의해 생성된 리소스 URI를 의미한다.
그리고 3XX 에서 Location 값은 요청을 자동으로 리다이렉션하기 위한 대상 리소스를 가리킨다.
🧩 Allow
Allow: GET, HEAD, PUTAllow 헤더는 허용 가능한 HTTP 메서드를 나타낸다. 사용자가 허용 불가능한 메서드를 사용해서 요청했을 경우, 405 (Method Not Allowed) 상태 코드와 함께 Allow 헤더를 응답에 포함해야 한다.
🧩 Retry-After
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
Retry-After: 120 (초단위 표기)Retry-After 헤더는 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간을 의미한다.
503 (Service Unavailable) 상태 코드를 응답할 때 이 헤더와 함께 응답한다.
✴️ 인증
🔐 Authorization
Authorization: Basic xxxxxxxAuthorization 헤더는 클라이언트 인증 정보를 서버에 전달하기 위해 사용한다.
🔐 WWW-Authenticate
WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"WWW-Authenticate 헤더는 리소스 접근시 필요한 인증 방법을 정의하기 위해 사용한다. 이 헤더는 401 Unauthorized 응답과 함께 사용한다. 헤더에 기재된 정보를 참고해 제대로 된 인증 정보를 제공하라는 의미이다.
✴️ 쿠키
쿠키는 왜 사용할까? 🤔
쿠키를 사용하지 않았을 때 로그인하는 상황을 살펴보자.
사용자가 홍길동 이라는 이름으로 로그인한다고 가정해보자. 클라이언트는 서버에게 POST 메서드를 통해 로그인을 요청하고, 서버는 이에 200 OK를 응답하며 로그인에 성공한다.
이후 사용자가 사이트의 메인 페이지에 다시 접속했을 때 기대하는 것은 "안녕하세요. 홍길동님"이지만, 사용자가 받는 것은 "안녕하세요. 손님"이 된다.
이런 상황이 왜 발생하는 걸까? HTTP의 특징을 살펴보며 알아보자.
Stateless
- HTTP는 무상태(Stateless) 프로토콜이다. 클라이언트와 서버가 서로 상태를 유지하지 않는다는 뜻이다.
- 클라이언트와 서버가 요청과 응답을 한 번 주고 받으면 연결이 끊어진다.
- 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
그렇다면 클라이언트가 서버에 요청을 보낼 때마다 사용자 정보를 포함시키는 건 어떨까?
이 방법은 일단 개발자가 힘들다 (ㅎㅎ) 브라우저를 완전히 종료하고 다시 열었을 때도 고려해야 하므로 꽤나 복잡하다!
쿠키를 사용한다면
이제 쿠키를 사용하는 방식에 대해 살펴보자.
클라이언트가 요청하는 방식은 쿠키를 사용하지 않을 때와 동일하다. 달라진 점은 서버의 응답 메세지이다. 서버의 응답 메세지를 보면, Set-Cookie 헤더를 통해 클라이언트에게 쿠키를 전달하는 것을 확인할 수 있다.
클라이언트는 서버의 응답 메세지 내에 포함된 쿠키를 받아 쿠키 저장소에 저장하는데, 이 쿠키는 이후 모든 요청마다 Cookie 헤더를 통해 자동으로 포함된다.
이 방식을 통해 클라이언트는 서버에 요청을 보낼 때마다 path에 쿼리 파라미터로 사용자 정보를 포함하지 않아도 되며, 쿠키 저장소에서 자동으로 쿠키를 요청 메세지에 포함시켜주기 때문에 보다 편리하게 서버와 통신할 수 있다.
하지만 이 쿠키 정보가 필요하지 않을 때도 매번 서버에게 보내기 때문에, 보안 상 위험한 점도 있다. 좀 더 구체적으로 알아보자.
서버의 응답 메세지 예시
set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure- 쿠키는 주로 사용자의 로그인 세션 관리나 광고 정보 트래킹 시 사용한다.
- 쿠키 정보는 항상 클라이언트 요청 메세지에 포함되어 서버로 전송되기 때문에 추가적인 네트워크 트래픽을 유발한다.
- 사용자 정보를 그대로 쿠키에 저장하기보다는
세션 id나인증 토큰을 활용하는 방식이 더 추천된다. - 만약 사용자 정보를 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage)를 사용하는 것이 추천된다.
- 하지만 가장 기본적인 것은 🚨보안에 민감한 데이터는 저장하면 안된다🚨는 것이다.
🍪 쿠키 - 생명 주기
Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
expires를 통해 만료일을 지정할 수 있다. (GMT 기준으로 기재)- 만료일이 되면 쿠키는 삭제된다.
Set-Cookie: max-age=3600
max-age를 통해 만료 시간을 초 단위로 지정할 수 있다.- 0이나 음수를 지정하면 쿠키는 삭제되며, 지정한 유효 기간이 지나도 쿠키가 삭제된다.
- 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료 시까지만 유지된다.
- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지된다.
🍪 쿠키 - 도메인
예를 들어 domain=example.org 라고 설정한다고 가정해보자.
1️⃣ 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
- domain=example.org 를 지정해서 쿠키 생성.
- example.org 는 물론이고, dev.example.org 에서도 쿠키 접근 가능.
2️⃣ 생략: 현재 문서 기준 도메인만 적용
- example.org 에서 쿠키를 생성하고 domain 지정을 생략하는 경우.
- example.org 에서만 쿠키 접근이 가능하며, dev.example.org 에서는 쿠키 접근이 불가능하다.
🍪 쿠키 - 경로
path 를 통해 경로를 지정하며, 이 경로를 포함한 하위 경로 페이지들만 쿠키에 접근할 수 있다.
일반적으로 path=/ 루트로 지정하며, 이 경우에는 /home, /home/level1, /home/level1/level2, /hello 등의 경로에서 모두 쿠키에 접근할 수 있다.
🍪 쿠키 - 보안
Secure
쿠키는 http, https를 구분하지 않고 전송하는데,Secure를 적용하면 https인 경우에만 전송하게 된다.
HttpOnly
HttpOnly는 XSS 공격의 방지를 위해 설정하며, 자바스크립트에서 접근이 불가능하게 된다.- HTTP 전송에서만 사용이 가능하다.
SameSite
SameSite는 CSRF(사이트 간 요청 위조) 공격 방지를 위해 설정하며, 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다.
Reference
