모든 개발자를 위한 HTTP 웹 기본지식 - 챕터 7

Chooooo·2022년 11월 12일
HTTP 웹 기본지식스프링
0

스프링 - 모든 개발자를 위한 HTTP 웹 기본지식

목록 보기
7/8
post-thumbnail

이 글은 강의 : 김영한님의 - "[모든 개발자를 위한 HTTP 웹 기본지식]"을 듣고 정리한 내용입니다. 😁😁

HTTP 헤더들에 대해서 공부해보자.

HTTP 헤더

header-field = field-name":"OWS field-value OWS

  • HTTP 전송에 필요한 모든 부가정보를 담는 용도로 사용된다.
  • 스펙에 정의된 헤더 뿐 아니라 임의의 헤더 추가도 가능하다.
    ex) HELLO_WORLD : catsbi

표현(Representation)

과거 RFC2616 스펙에서는 엔티티헤더, 엔티티 본문 등으로 불리던 HTTP 헤더와 바디는 2014년부터 개정된 RFC2730~7235부터는 표현(Representation)이라는 용어로 불리게 되었다.
HTTP 헤더는 표현 헤더, HTTP Message Body는 표현 데이터라 부른다.
표현 헤더 역시 표현 메타데이터와 페이로드 메세지로 구분해야 하지만, 생략한다.

표현 헤더

전송,응답 양측에서 사용이 가능한 정보로 서버/클라이언트간에 송/수신할 때 해당 정보로 무엇을 어떻게 표현할지에 대해 알려주고 표현한다. 이는 표현 헤더보다는 Payload 헤더라 부르는게 더 명확하지만, 그냥 표현 헤더라고 해도 문제 없다.


🎈 Content-Type
표현 데이터의 형식 정보를 설명한다.
text/html;charset=utf-8, application/json, image/png, ...

  • 클라이언트(웹 브라우저)는 이 Content-Type을 보고 표현 데이터를 적절히 렌더링 한다.

HTML 형식의 표현 데이터의 Content-Type을 text/html이 아닌 application/json으로 보내면 우리가 아는 포맷으로 렌더링되지 않고 그대로 데이터가 브라우저에 출력된다.

🎈 Content-Encoding
표현 데이터의 인코딩을 설명한다.
gzip, deflate, identity(압축을 하지 않는다.)

  • 서버 및 클라이언트 양측에서 사용할 수 있는 정보다.
  • 데이터를 받는 측에서는 해당 정보를 보고 압축을 해제하여 데이터를 읽는다.
  • 데이터를 전달하는 측에서는 해당 데이터를 압축 후 압축 형식을 헤더에 추가한다.

🎈 Content-Language
표현 데이터의 자연 언어를 설명한다.

  • ko, en, en-US, de, ...
  • 서버측에서 지원을 한다는 가정하에 해당 언어로 응답을 받을 수 있다.

🎈 Content-Length
표현 데이터의 길이를 설명한다.

  • 바이트 단위이다.
  • Transfer-Encoding(전송 코딩)을 사용하면 내부에 Content-Length 정보도 포함되어 있기에 헤더 필드를 사용하면 안된다.

콘텐츠 협상

클라이언트에서 선호하는 표현에 대해 작성하여 서버에게 전달을 할 수가 있는데, 이 정보들을 토대로 서버측에서는 우선순위에 맞춰 지원이 가능한 범위까지 표현 데이터를 만들어서 클라이언트에게 제공하도록 하는 정보이다.
일단은 클라이언트가 선호하는 표현 요청!이라고 이해하자.

🎈 Accept-Language
클라이언트에서 우선적으로 선호하는 자연 언어에 대한 정보를 담는다. 서버측에서는 다국어를 지원한다는 가정하에 해당 정보를 읽고 우선순위대로 지원 여부에 따라 가장 높은 우선순위의 언어로 표현데이터를 작성해 응답한다.

🧨협상과 우선순위(Quality Values)
: 콘텐츠 협상이라는 말 그대로 클라이언트는 자신이 요구하는 언어나 포맷등이 하나로 단일적이지 않고 우선순위에 따라 데이터를 요청할 수 있는데 이런 우선순위를 작성하는 방식은...?

  • q(quality) 필드 사용
    Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
    0~1사이의 값을 q의 값으로 작성하며 1과 가까울수록 높은 우선순위를 가진다.
    우선 순위가 1인경우 해당 정보는 생략할 수 있다.

  • 정보의 구체화
    정보를 **구체적으로 작성 할수록 우선순위는 높아진다.**
    Accept: text/*, text/plain, text/plain;format=flowed, */*
    위와 같이 적혀있다면 우선순위는...

1.text/plain;format=flowed
2.text/plain
3.text/
4./*

일반 정보

  • Referer : 이전 웹 페이지 주소로 요청에서 사용하며 유입경로 분석등에 사용한다.
  • User-Agent : 클라이언트의 애플리케이션 정보로 클라이언트 장비 혹은 웹 브라우저등의 정보를 의미하며 요청에서 사용한다.
  • Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 의미한다. 응답에서 사용한다.
  • Date : 메세지가 발생한 날짜와 시간정보이며 예전에는 요청과 응답모두 사용되었지만 현재는, 응답에서만 사용한다.
    (여기까지는 간단하고 쉬워)

특별한 정보

특별한 HTTP 헤더들에 대해서 알아보자.

🎁 HOST --> 매우 중요!

  • 요청한 호스트(도메인) 정보를 의미한다.
  • 요청에서 사용한다.
  • 필수 헤더이다.
  • 하나의 서버에서 여러 도메인을 가상 호스팅하거나, 하나의 IP주소에 여러 도메인이 적용되어 있을 때 필수적으로 필요한 정보다.

🎁 Location

  • 응답에서 사용한다.
  • 페이지 리다이렉션에 사용되는 정보
  • 웹 브라우저에서 3XX 응답에 해당 정보가 있을 경우 자동 리다이렉션 한다.
  • 201(Created) 응답에서 Location은 리소스 생성 요청에 의해 생성된 리소스 식별자 URI이다.

🎁 Allow

  • 해당 경로로 허용 가능한 HTTP 메서드 정보
  • /members 라는 경로가 GET, POST, DELETE 만 제공한다고 할 때 PATCH로 요청을 보낼 경우 다음과 같이 응답메세지에 포함된다.
  • 405(Method Not Allowed)
  • Allow: GET, POST, DELETE
    (이런게 있구나 참고 정도)

🎁 Retry-After

  • User-Agent가 다음 요청을 하기까지 기다려야 하는 시간
  • 언제 요청을 받을 수 있을지 유추하기 힘들기 때문에 사용하기가 쉽지 않다.
  • 503(Service Unavailable): 서비스가 언제까지 불가능한지 알려줄 수 있다.
  • Retry-After: Fri, 31 Dec 1999 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초단위 표기)
    (실제로 사용 잘 X)

인증

🎈 Authorization

  • 클라이언트 인증 정보를 서버에 전달한다.
  • Authorization: BASIC xxxxxxxxxxxxxxxxxx
  • 인증 방식에 따라 전달 해야하는 값이 다르다.

🎈 WWW-Authentication

  • 리소스 접근시 필요한 인증 방법 정보
  • 401 Unauthorized 상태코드와 함께 전달된다.

쿠기

--> 매우 중요!

개요
: (HTTP는 무상태 프로토콜) 서버는 무상태성(stateless)를 보장해야하는데, 특정 상태(로그인등)는 계속 유지가 되야하는 경우 매 번, 요청시 클라이언트에서 정보들을 동봉해서 보내야하는데, 이를 직접 작성하는것은 큰 비용 소모가 들고 개발자가 놓치면 정보가 누락될 가능성도 높다.
그렇기에 브라우저에서는 이러한 몇몇 데이터 덩어리를 저장해놨다가 동일한 서버에 재 요청시 저장된 데이터를 함께 전송하는데, 이를 쿠키라 한다.

🎃 쿠키의 용도

  • 세션관리(Session Management)

    • 서버에서 사용하고 유지되야 할 정보들(로그인, 장바구니, 게임 스코어등의 정보)관리

  • 개인화(Personalization)

    • 사용자가 선호하는 테마나 장르등의 세팅정보들

  • 트래킹(Tracking)

    • 사용자 행동을 기록하고 분석하는 용도

🎃 사용법

서버측에서 Set-Cookie라는 필드에 정보들을 담아 응답하면 웹 브라우저는 해당 정보를 쿠키에 저장한다.

🎃 주의사항
1. 쿠키정보는 항상 서버에 전송되기에 네트워크 비용이 추가된다. 그렇기에 항상 최소한의 정보들만 쿠키에담아 사용하며 전송을 해야 한다.
2. 보안에 민감한 정보들은 쿠키에 저장해서는 안된다. (Ex: 주민번호, 신용카드 번호 등)

웹 스토리지(Web Storage)
서버에 전송할 필요 없이 클라이언트측에서만 관리하면 되는 민감하지 않은 데이터들은 웹 스토리지를 사용할 수 있다. 이 웹 스토리지는 모두 HTML5에서 추가된 저장소로 간단한 key/value를 저장할 수 있다. 그리고 도메인별로 같은 스토리지를 공유하는데 보통 모바일은 2.5mb, 데스크탑은 5~10mb정도라고 생각하면 된다.
(프로토콜, 호스트, 포트가 같은 경우 같은 스토리지를 공유한다.)

  • Local Storage

    데이터의 지속성이 영구적이다.
    window.localStorage에 위치한다.
    모든 값은 문자열로 변환 되어 저장된다.
    Object 타입도 toString의 결과가 저장된다.([object Object])
    JSON.stringify를 이용해 직렬화 하여 사용할 수 있기는 하다.

  • Session Storage

    윈도우&브라우저 탭을 닫을 경우 모두 삭제된다.
    window.sessionStorage에 위치한다.
    사용법은 LocalStorage와 동일하다.

쿠키의 생명주기(LifeCycle)

Expires, max-age 를 이용해 생명주기를 관리할 수 있다.
Set-Cookie: expires=Sat, 10-Jan-2022 04:39:21 GMT
⇒ 2022년 1월 10일 4시 39분 21초가 되면 해당 쿠키는 삭제된다.
Set-Cookie: max-age=3600(sec)
⇒ 3600초 이후 삭제된다.
⇒ 0이나 음수로 지정할 경우 쿠키는 즉시 삭제된다.
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료 시 까지만 유지된다.
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지된다.

쿠키의 도메인

domain 필드에 명시한 도메인 (+ 서브 도메인)정보로 쿠키의 접근 가능여부가 결정된다.
ex) domain=example.org를 지정해서 쿠키 생성

  • example.org는 쿠키가 접근이 가능하다.
  • dev.example.org 역시 서브 도메인도 포함되기에 쿠키 접근이 가능하다.

해당 필드를 생략하면 현재 문서 기준 도메인만 적용된다.

  • example.org에서 쿠키를 생성하면 해당 도메인만 쿠키 접근이 가능하고 그 외 서브도메인은 쿠키 접근이 불가하다.

쿠키 경로 지정

  • path 필드에 작성한 경로와 그 하위 경로 페이지에서만 쿠기 접근이 가능하다.
  • 보통 루트경로(path=/)로 지정을 한다.
    ex) path=/home

쿠키 보안 지정

  • Secure를 지정하면 기존 http, https 모두 전송되던 쿠키가 https인 경우에만 전송한다.
  • HttpOnly는 XSS 공격 방어 및 자바스크립트에서 접근이 불가능하게 막는 기능을 한다.
  • SameSite는 XSRF 공격 방어를 하고 요청도메인과 쿠키에 설정된 도메인이 동일한 경우에만 쿠키를 전송하게 한다.

🎈 아래는 보안과 관련된 내용

XSS(Cross-Site Scription)

관리자가 아닌 기타 사용자가 웹 사이트에 스크립트를 삽입(Injection)하는 공격 기법
해커가 웹페이지에 악의적인 스크립트를 삽입하여 일반 사용자가 해당 페이지에접근시 세션정보를 탈취하여 악의적으로 사용할 수 있게끔할 수 있다. (더 보기)
지속형(혹은 저장형) XSS 공격 (Persistent(or Stored) XSS)
: 해커가 XSS 취약점이 있는곳을 파악하여 악성 스크립트를 삽입하면, 해당 스크립트가 서버의 데이터베이스에 저장되고 이런 스크립트가 있는 게시글 등을 방문한 일반 사용자들은 악성 스크립트가 작동하며 쿠키정보를 탈취당하거나 타 사이트로 리다이렉션되는 공격을 받는다.
데이터베이스에 저장이되어 지속적 공격이 되기에 Persistent XSS or Stored XSS 공격이라 한다.
반사형 XSS 공격 (Refected XSS)
: 검색 플랫폼같은 사용자에게 입력받은 값을 서버에서 되돌려주는 곳에서 발생한다. 해커는 악의적인 스크립트와 함께 URL을 사용자에게 누르도록 유도한 뒤, URL을 누른 사용자는 스크립트가 실행되며 공격을 받는다.
DOM 기반 XSS 공격(DOM Based XSS)
:악의적인 스크립트가 포함된 URL을 사용자가 요청하게 하여 브라우저를 해석하는 단계에서 발생하는 공격으로 다른 XSS 공격과는 다르게 서버측에서 감지하기가 힘들다는 문제가 있다.
예를들어 URL에 끝에 # 특수문자를 사용하면 이 뒤의 값들은 서버로 전송되지 않기 때문에 이를 이용해 공격이 가능하다.

XSRF(Cross-Site Request Forgery)

CSRF라고도 한다. 쿠키만으로 인증하는 서비스의 취약점을 이용해 서비스에 특정 명령을 요청하는 공격.

문제 시나리오)
1. A 사이트는 쿠키로 인증을한다. 출석 인증 경로는http://siteA.kr/api/attendance
2. A사이트에서 로그인 후 전혀 다른 도메인인 B 사이트로 이동
3. B사이트의 특정 이미지 태그가 다음과 같다면 A 사이트의 출석 체크가 된다.
⇒ <img src=”http://siteA.kr/api/attendance”/>

profile
Chooooo
back-end, 지속 성장 가능한 개발자를 향하여
이전 포스트

모든 개발자를 위한 HTTP 웹 기본지식 - 챕터 6

다음 포스트

모든 개발자를 위한 HTTP 웹 기본지식 - 챕터 8

0개의 댓글