HTTP/HTTPS

https://learn.dreamhack.io/199

컴퓨터와 통신할 때는 비교적 엄격한 프로토콜을 사용해야 한다. 

 

많은 컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터(이하 메시지)를 명확히 해석할 수 있도록 문법(syntax)을 포함한다. 일반적으로 이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시된다. 

현재까지 제정된 표준 통신 프로토콜에는 네트워크 통신의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP 등 매우 많은 종류가 있다. 

 

HTTP

HTTP(Hyper Text Transfer Protocol)란 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜이다. 

HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면, 서버가 응답하는 것이다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환한다.

 

HTTP 메시지

HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있다.

기능과 세부 구조에서는 차이가 있지만, 크게 보면 이들은 공통적으로 HTTP 헤드와 바디로 구성된다.

HTTP 메시지의 시작 줄과 HTTP 헤더를 묶어서 '요청 헤드(head)' 라고 부르며,  HTTP 메시지의 페이로드는 '본문(body)'이라고 한다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

HTTP 요청

HTTP 요청은 서버에게 특정 동작을 요구하는 메시지이다.

 서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고, 적절할 때만 이를 처리한다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

시작 줄

HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성한다.

각각은 띄어쓰기로 구분한다.

• HTTP 전송 방법 (method)
  • ex. GET, PUT, POST, HEAD, OPTIONS
• 요청 URL
  • 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타남
  • 요청 포맷은 HTTP 메소드에 따라 달라짐
    • POST / HTTP/1.1
    • GET /background.png HTTP/1.0
    • HEAD /test.html?query=alibaba HTTP/1.1
    • OPTIONS /anypage.html HTTP/1.1
  • 'absolute 형식'으로 알려진 완전한 URL은 프록시에 연결하는 경우 대부분 GET과 함께 사용
    • GET http://developer.mozilla.org/ko/docs/Web/HTTP/Messages HTTP/1.1
  •  'authority 형식'으로 알려지고 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다)로 이루어진 URL의 인증 컴포넌트이다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있다. 
    • CONNECT developer.mozilla.org:80 HTTP/1.1
  •  OPTIONS와 함께 별표('*') 하나로 서버 전체를 나타내는 'asterisk 형식'이다. 
    • OPTIONS * HTTP/1.1
• HTTP 버전
  • ex. 1.0 또는 1.1
  • 클라이언트와 서버의 버전을 맞춰주기 위함

HTTP 요청 헤더

• 이름: 값
• 요청 헤더의 종류
  • General 헤더: HTTP/1.1 부터는 General header로 구체적으로 분류하지 않음 
  • Request 헤더: User-Agent (en-US), Accept와 같은 Request 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 주기도 하면서(If-None) 요청 내용을 수정다.
    • User-Agent 헤더: 소프트웨어에 관한 정보
    • 호스트(Host) 헤더: 호스트명
    • 쿠키(Cookie) 헤더
      • 쿠키: 세션에 대한 정보 (이게 어떤 세션인지 파악 가능)
      • XWS 공격으로 세션 정보 훔쳐올 수 있음
  •    Referer 헤더: 해당 요청이 시작된 URL 정보
    • 공격자가 해당 헤더를 변경할 수 있다.
  •  메시지 데이터의 원래 형식과 적용된 인코딩을 설명하는 Content-Type과 같은 Representation 헤더(메시지에 본문이 있는 경우에만 존재).

→ 보안적 관점에서는 쿠키 헤더와 Referer헤더가 가장 중요!

본문 (body)

본문은 요청의 마지막 부분에 들어간다.

모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없다.

일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇다.

body는 크게 두가지 종류로 나뉜다

• 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성되는 단일-리소스 본문(single-resource bodies)
• 각각 서로 다른 정보를 담고 있는 멀티파트 본문으로 구성되는 다중 리소스 본문
  •  보통 HTML 폼 (en-US)과 관련이 있음 

HTTP 응답 

시작줄

• HTTP 버전
  • ex. HTTP/1.1
•  요청에 대한 결과 코드
  • ex. 200. 404, 302
•  응답에 대한 상황을 설명해주고, 사람이 HTTP 메시지를 이해할 때 도움이 되는 상태 코드에 대한 짧고, 순전히 정보 제공 목적의 '상태 텍스트'
  • ex. OK

상태 코드	설명	대표 예시
1xx	요청을 제대로 받았고, 처리가 진행 중
2xx	요청이 제대로 처리됨	200(OK): 성공
3xx	요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함	302(Found): 다른 URL로 갈 것
4xx	클라이언트가 잘못된 요청을 보내어 처리에 실패했습니다.	- 400(Bad Request): 요청이 문법에 맞지 않음 - 401(Unauthorized): 클라이언트가 요청한 리소스에 대한 인증이 실패함  - 403(Forbidden): 클라이언트가 리소스에 요청할 권한이 없음 - 404(Not Found): 리소스 없음
5xx	클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패하였습니다.	- 500(Interval Server Error): 서버가 요청을 처리하다가 에러가 발생함  - 503(Service Unavailable): 서버가 과부하로 인해 요청을 처리할 수 없음

 

HTTP 응답 헤더 

응답에 들어가는 HTTP 헤더는 다른 헤더와 동일한 구조를 따른다.

• Via와 같은 General 헤더는 메시지 전체에 적용됩니다
• 응답 헤더: 원칙적으로는 서버에서 동작되는 소프트웨어의 정보를 보여줌
  ⇒ 따라서, 공격자의 관심사! BUT 높은 확률로 정보가 잘못됨
  • 이 정보를 통해 버전의 정보를 알아냄 → 만약 맞는 정보라면 공격자가 맞춤형 공격을 할 수 있기 때문에 매우 유리해짐
    ⇒ 공격자도 다른 방법 사
  • Set-Cookie 헤더: 쿠키를 브라우저(=클라이언트)에게 보낼 때 사용
  • www-Authenticate 헤더: 인증 관련 상세 정보를 담음

본문 (body)

본문은 응답의 마지막 부분에 들어갑니다. 모든 응답에 본문이 들어가지는 않는다.

해당 페이로드 없이도 요청에 충분히 응답하는 201 Created, 204 **No Content**과 같은 상태 코드를 가진 응답에는 보통 본문이 없다.

 

HTTP 클라이언트 메소드

⭐ GET과 POST의 차이점 → 어떤게 더 보안적으로 안전할까?
⇒ POST (URL 공개 X)
그러나 POST도 완전하게 안전하지 않다는 것을 주의해야 함 (상대적으로 더 안전하다는 것)
→ POST도 크롬 개발자 도구나 와이어샤크 등을 통해서 확인할 수 있기 때문

https://velog.io/@welchs1423/GET-POST-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EC%B0%A8%EC%9D%B4

 

먼저 GET은 리소스를 가져오라는 메소드이다. 이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아온다. 반대로, POST는 리소스로 데이터를 보내라는 메소드이다. 전송할 데이터는 보통 HTTP 바디에 포함되고, 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내진다.

•  GET⭐⭐⭐
  • 웹 서버에 있는 자원을 획득할 때 사용 → 요청
  • URL에 모든 정보가 나타남
  • URL이 한 번 입력되면 브라우저 히스토리나 웹 서버의 로그에 저장됨
  • 외부사이트와 링크되어 있는 경우에 다른 사이트들의 Referer 헤더에도 전달됨
  • 중요한 정보는 URL query를 통해 공개되면 안되기 때문에 GET 메서드를 통해 전달하면 안됨
• POST⭐⭐⭐
  • 요청 인자를 메시지 몸체를 통해서 보내질 수 있음
  • URL은 북마크 되지만, 메시지 몸체를 통해 보내어진 요청 인자는 URL을 기록하는 로그에 저장되지 않고, Referer 헤더에도 전달되지 않음
• HEAD
  • GET 요청을 하기 전에 리소스가 있는지 확인
    • 있으면 GET요청 보내고, 없으면 보내지 X
•  TRACE
  • 진단을 위한 목적으로 사용됨
  • 프록시 서버의 효과를 탐지하는데 사용
•  OPTIONS
  • 추가적으로 들어갈 수 있는 어떤 정보들을 서버에 요청할 때 사용
    • 일시적으로 사용되지 않는 특정 자원 등
  •  서버는 리스트를 갖는 allow 헤더를 통해 응답
•  PUT
  • 서버에 특정 자원을 올릴 때(업로드..) 사용하는 방식
    •  GET/POST: 자원을 가져올 때 사용
  •  공격자가 악의적인 스크립트를 서버에 올려서 실행할 때 사용될 수 있음