[Web_hacking] stage2_HTTP/HTTPS

*인코딩

인코딩 표준에는 아스키와 유니코드가 있다. 아스키는 7비트 데이터에 대한 인코딩 표준으로, 알파벳과 특수 문자 등을 표현할 수 있다.

 

컴퓨터 개발 초기에는 문자권에 따라 사용하는 인코딩 표준도 상이했지만 이는 호환성 문제로 이어져 유니코드라는 새로운 표준을 이용하게 되었다. 

 

유니코드에서 한 문자는 최대 32비트로 표현되며, 32비트로 표현 가능한 정보의 가짓수는 2^32 (약 42억 개)이므로 전 세계의 문자를 표현하고도 남는다.

 

이와 같은 인코딩을 통해 데이터를 컴퓨터에 저장하고, 웹 서버를 통해 공유할 수 있다.

 

 

 

*통신 프로토콜

클라이언트가 웹 서버에 존재하는 리소스를 받아 보기 위해서는 웹에 해당 리소스 제공을 요청하는 과정이 필요하다. 이 과정에서 클라이언트가 서버에 하는 행위를 요청(Request), 서버가 클라이언트에 리소스를 반환하는 것을 응답(Response)이라고 한다. 

 

프로토콜은 위와 같이 규격화된 상호작용에 적용되는 약속을 말한다.(규약) HTTP도 다양한 통신 프로토콜의 일종이다. 

 

 

 

*HTTP

Hyper Text Transfer Protocol은 서버와 클라이언트의 데이터 교환을 요청-응답 형식으로 정의한 프로토콜이다. 기본 매커니즘은 클라이언트 -> 서버 요청, 서버 -> 클라이언트 응답으로 이루어진다. 

 

웹 서버는 HTTP서버를 HTTP서비스 포트에 대기시킨다. (이 포트는 보통 TCP/80이나 TCP/8080이다.) 클라이언트가 서비스 포트에 HTTP요청을 전송하면, 이를 해석해 적절한 응답을 반환한다. 

 

->네트워크 포트: 서버와 클라이언트가 정보를 교환하는 추상화된 장소.

 

->서비스 포트: 네트워크 포트 중 특정 서비스가 점유하고 있는 포트. (HTTP가 80번 포트를 점유하고 있다면, HTTP의 서비스 포트는 80번 포트인 것이다.)

 

포트를 통한 데이터 교환은 전송 계층(Transpor  Layer) 프로토콜을 따른다. -> TCP와 UDP가 있음.

 

TCP로 데이터를 전송하려는 서비스에 UDP클라이언트가 접근하면 데이터 교환이 이루어지지 않는다. -> 서비스 포트 표기 시 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 한다. -> HTTP의 서비스 포트가 TCP/80이라는 건 HTTP서비스를 80번 포트에서 TCP로 제공하고 있다는 뜻.

 

포트 개수는 운영체제에서 정의하기 나름 -> 윈도우, 리눅스, 맥 운영체제는 0 ~ 65535번 포트를 사용한다.

 

이 포트들 중 0 ~ 1023번 포트는 Well-known port(잘 알려진 포트) 혹은 Privileged port(특권 포트)라고 한다. -> 잘 알려진 서비스가 등록되어 있음. 

 

ex: 22번 포트에는 SSH, 80번에는 HTTP, 443번에는 HTTPS 등

 

이처럼 잘 알려진 포트에 서비스를 실행하기 위해서는 관리자 권한이 필요 -> 클라이언트는 이 포트 범위에서 실행중인 서비스는 관리자의 것이라고 신뢰 가능.

 

 

 

*HTTP메시지

HTTP메시지에는 클라이언트가 전송하는 HTTP요청과 서버가 반환하는 HTTP응답이 있다. -> 이 둘은 모두 HTTP 헤드와 바디로 구성된다.

 

HTTP헤드: 각 줄이 CRLF로 구분되며, 첫 줄은 시작 줄(Start-line), 나머지 줄은 헤더(Header)라고 부른다. 헤드의 끝은 CRLF 한 줄로 나타낸다.

 

헤더는 필드 + 값으로 구성되고, HTTP메시지나 바디의 속성을 나타낸다. HTTP메시지 한 개에는 0개 이상의 헤더가 존재한다.

 

 

HTTP바디: 헤드의 끝을 나타내는 CRLF뒤의 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 이곳에 담긴다.

HTTP메시지

 

 

 

*HTTP요청

서버에게 특정 동작을 요구하는 메시지이다. 서버는 그 동작이 실현 가능한지, 클라이언트에게 해당 동작을 요청할 권한이 있는지 등을 검토한 뒤, 적절하다고 판단하면 이를 처리한다. 

 

시작 줄: HTTP요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), HTTP버전으로 구성된다. -> 띄어쓰기로 구분

 

메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타낸다. HTTP표준에 정의된 메소드는 8개가 있다. (GET, POST, OPTIONS, HEAD, PUT, PATCH, DELETE, TRACE)

 

GET은 리소스를 가져오라는 메소드이다. 이용자가 브라우저에 웹 서버의 주소를 입력하거나, 하이퍼링크를 클릭하면 새로운 페이지를 렌더링하기 위해 리소스가 필요함 -> 브라우저는 GET요청을 서버에 전송해 리소스를 받아온다.

GET

녹색 -> 메소드 / 하늘색 -> 요청 URI / 적색 -> HTTP버전 / 갈색 -> 요청 헤더

(GET은 바디가 필요하지 않다.)

 

 

 

POST는 리소스로 데이터를 보내라는 메소드이다. 전송할 데이터는 HTTP바디에 포함된다. (로그인할 때 입력하는 ID, 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내진다.)

POST

녹색 -> 메소드 / 하늘색 -> 요청 URI / 적색 -> HTTP버전 / 갈색 -> 요청 헤더 / 보라색 -> 요청 바디

 

 

(헤더와 바디는 HTTP메시지와 동일한 구조이다. )

 

 

 

*HTTP응답

HTTP요청에 대한 결과를 반환하는 메시지이다. 요청 수행 여부, 요청 거부 이유와 같은 상태 정보(Status), 클라이언트에게 전송할 리소스가 응답에 포함된다. 

 

시작 줄: HTTP버전, 상태 코드(Status Code), 처리 사유(Reason Phrase)가 있다. -> 띄어쓰기로 구분

 

HTTP버전: 서버에서 사용하는 HTTP프로토콜의 버전을 말한다. 

 

상태 코드: 요청에 대한 처리 결과를 세 자리 수로 나타낸 것이다. -> HTTP표준인 RFC 2616은 40여개의 상태 코드를 정의하고 있고, 각 상태 코드는 첫 번째 자릿수에 따라 5개의 클래스로 구분된다.

 

-> 1XX : 요청을 제대로 받았고, 처리 진행 중

-> 2XX : 요청이 제대로 처리됨

-> 3XX : 요청을 처리하려면 클라이언트의 추가 동작 필요

-> 4XX : 클라이언트의 유효하지 않은 요청으로 인한 처리 실패

-> 5XX : 클라이언트의 요청은 유효하지만 서버 에러로 인해 처리 실패 

 

처리 사유: 상태 코드의 발생 이유를 짧게 서술한 것이다. 

 

(헤더와 바디는 HTTP메시지와 동일한 구조이다. )

 

HTTP 응답

적색 -> HTTP버전 / 보라색 -> 상태 코드 / 주황색 -> 응답 헤더 / 녹색 -> 응답 바디

 

 

 

*HTTPS

HTTP의 응답-요청은 평문으로 전달됨 -> 중요 정보의 유출 가능성 존재 -> EX: 로그인 시 POST요청에는 id와 비밀번호가 포함됨.

 

HTTP over Secure socket layer는 TLS(Transport Layer Security) 프로토콜을 도입해 HTTP의 문제점을 보완한다. TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP메시지들을 암호화한다. -> 공격자가 탈취해도 해독은 불가능

 

HTTP메시지

 

HTTPS 메시지

 

 

위 메시지에서 빨간색 글자는 요청, 파란색 글자는 응답인데, HTTPS의 메시지 내용은 알아볼 수 없다.