Background: HTTP/HTTPS
# 들어가며
1. 언어에서의 약속
- 문장의 의미는 문장을 구성하는 단어의 의미, 문법 구조, 맥락, 독자의 배경 지식 등으로 결정됨
- 단어의 의미와 문법은 사회적으로 합의되어 있음
ex) 만약 사람들이 "사과"로 바나나를 가리키기로 약속했다면 우리는 바나나를 보고 "사과"라고 부를 것임
- 언어에서의 약속이란, 문장의 의미를 결정하는 매우 중요한 요소로 컴퓨터에서도 마찬가지로 적용됨
2. 인코딩
- 컴퓨터의 모든 데이터는 0과 1로 구성됨
- 0과 1로 우리의 문자를 표현하는 것도 일종의 약속 덕분인데, 이런 약속들을 인코딩(Encoding) 표준이라고 부름
ex) 아스키(Ascii)와 유니코드(Unicode)
- 아스키는 7비트 데이터에 대한 인코딩 표준으로 이를 이용하면 알파벳과 특수 문자 등을 표현할 수 있음
ex) 1000001 = "A" : "1000001"이라는 데이터는 아스키로 변환하면 "A"가 됨
- 컴퓨터가 개발된 초기에는 각 문자권마다 고유의 인코딩 표준을 사용함
but, 호환성 측면에서, 국제 소프트웨어를 개발하려는 회사에 큰 부담이 됨
because, 인코딩이 호환되지 않았기 때문
- 위와 같은 어려움을 해결하고자 만들어진 표준이 유니코드
- 유니코드: 모든 언어의 문자를 하나의 표준에 담겠다는 목표를 가짐
> 32개의 비트로 표현됨
> 표현할 수 있는 정보의 가짓수: 2^32 = 42억개
> 최근 한글, 한자, 히라가나, 가타카나, 알파벳과 같은 문자 외에 각종 이모지들도 유니코드에 포함됨
- 인코딩을 이용하면 우리의 문장을 컴퓨터에 저장하고, 표현할 수 있음
- 네트워크를 이용하면 인코딩한 정보를 다른 사람들과 쉽게 교환할 수 있음
3. 통신 프로토콜
- 웹 서버에 있는 리소스를 클라이언트가 받아 보려면
① 클라이언트는 웹에게 특정 리소스를 지정하여 제공해달라고 요청해야 함
② 서버가 해당 요청을 이해하고, 대응되는 동작을 통해 클라이언트에게 리소스를 반환
- 클라이언트의 행위: 요청(request), 서버의 행위: 응답(response)
- 프로토콜: 규격화된 상호작용에 적용되는 약속
> 일상에서 사람과 사람이 통신할 때는 관습을 따르되 약간의 융통성을 발휘해도 정보를 교환하는데 문제 X
> 컴퓨터와 통신할 때는 비교적 엄격한 프로토콜을 사용 → 컴퓨터가 해석의 융통성을 발휘하게 되는 것은 어렵고,
그 과정에서 오히려 통신 오류가 발생할 가능성이 높아지기 때문
- 컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터를 명확히 해석할 수 있도록 문법(syntax)를 포함
- 문법에 어긋나는 메시지는 절못 전송된 것으로 취급하여 무시됨
# HTTP
1. HTTP
- HTTP(Hyper Text Transfer Protocol): 서버와 클라이언트의 데이터 교환을 요청과 응답 형식으로 정의한 프로토콜
- 기본 메커니즘: 클라이언트가 서버에게 요청하면, 서버가 응답하는 것
① 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킴.
> 이 포트는 일반적으로 TCP/80 또는 TCP/8080임
② 클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환
- Request
| GET | HTTP Method |
| /index.html | Request URL |
| HTTP/1.1 | HTTP version |
| Host, Connection, User-Agent | Request Header |
- Response
| HTTP/1.1 | HTTP version |
| 200 OK | Return Code |
| Server, Content-Length, Connection, Content-Type | Response Header |
| <!doctype html><html></html> | Response Body |
💡 네트워크 포트와 서비스 포트
- 포트: 항구라는 의미를 가짐. 클라이언트가 서버의 포트에 접근하여 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보내는 장면을 연상할 수 있음
- 네트워크 포트(Network Port): 네트워크에서 서버와 클라이언트가 정보를 교환하고 추상화된 장소를 의미
- 서비스 포트(Service Port): 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트를 말함
ex) HTTP가 80번 포트를 점유하고 있다면 HTTP의 서비스 포트는 80번 포트가 됨
- 포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따름
ex) TCP, UDP
- TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 않음
> 반대의 경우도 마찬가지
- 서비스 포트를 표기할 때는 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 함
ex) HTTP의 서비스 포트가 TCP/80이라고하면, HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 의미
2. HTTP 메시지
- HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있음
- 기능과 세부 구조에서는 차이가 있지만, 크게 보면 이들은 HTTP 헤드와 바디로 구성된다는 공통점이 있음
- HTTP 헤드
> HTTP 헤드의 각 줄은 CRLF로 구분되며, 첫 줄은 시작 줄(start-line), 나머지 줄은(Header)라고 부름
> 헤드의 끝은 CRLF 한 줄로 나타냄
> 헤드는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타냄
> 하나의 HTTP 메시지에는 0개 이상의 헤드가 있을 수 있음
* 시작 줄의 역할은 요청과 응답에서 큰 차이가 있음
- HTTP 바디
> HTTP 바디는 헤드의 끝을 나타내는 CRLF뒤, 모든 줄을 말함
> 클라이언트나 서버에게 전송하려는 데이터가 바디에 담김
3. HTTP 요청
- HTTP 요청은 서버에게 특정 동작을 요구하는 메시지
- 서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고, 적절할 때만 이를 처리함
- 시작 줄
> HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성
> 각각은 띄어쓰기로 구분
> 메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작으로 나타냄
> HTTP 표준에 정의된 메소드는 8개가 있음 ex) GET, POST
> 요청 URI: 메소드 대상을 나타냄
> HTTP 버전: 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타냄
- 헤더와 바디
> 시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같음
① GET
> 리소스를 가져오라는 메소드
> 이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면,
새로운 페이지를 랜더링하기 위해 리소스가 필요함
> 이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아옴
② POST
> 리소스로 데이터를 보내라는 메소드
> 전송할 데이터는 보통 HTTP 바디에 포함됨
> 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내짐
4. HTTP 응답
- HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지
- 요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함됨
- 시작 줄
> HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성
> 각각은 띄어쓰기로 구분
> HTTP 버전: 서버에서 사용하는 HTTP 프로토콜의 버전을 나타냄
> 상태 코드: 요청에 대한 처리 결과를 세 자릿수로 나타냄
> HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데,
각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류됨
> 처리 사유: 상태 코드가 발생한 이유를 짧게 기술한 것
| 상태 코드 | 설명 | 대표 예시 |
| 1xx | 요청을 제대로 받았고, 처리가 진행 중임 | |
| 2xx | 요청이 제대로 처리됨 | - 200: 성공 |
| 3xx | 요청을 처리하려면, 클라이언트가 추가 동작을 취야야 함 | - 302: 다른 URL로 갈 것 |
| 4xx | 클라이언트가 잘못된 요청을 보내어 처리에 실패했습니다 | - 400: 요청이 문법에 맞지 않음 - 403: 클라이너트가 리소스에 요청할 권한이 없음 - 404: 리소스가 없음 |
| 5xx | 클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패했습니다 | - 500: 요청을 처리하다가 에러가 발생함 - 503: 서버가 과부하로 인해 요청을 처리할 수 없음 |
5. HTTP Request & Response
1) HEAD
- 요청 전송
- request
- response
2) GET
- 요청 전송
- request
- response
3) POST
- 요청 전송
- request
- response
4) PUT
- 요청 전송
- request
- response
5) PATCH
- 요청 전송
- request
- response
6) DELETE
- 요청 전송
- request
- response
7) TRACE
- 요청 전송
- request
- response
# HTTPS
- HTTP의 응답과 요청은 평문으로 전달됨
> 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있음
ex) 로그인할 때 POST 요청에는 이용자의 ID와 비밀번호가 포함되는데
공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있음
- HTTPS(HTTP over Secure socket layer): TLS(Transport Layer Security) 프로토콜을 도입하여 위와 같은 문제점을 보완
- TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화함
> 공격자가 중간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능하며,
결과적으로 HTTP 통신이 도청과 변조로부터 보호됨
- Wireshark로 웹 서버와 오가는 메시지 확인하기
> 빨간 글자: 요청 | 파란 글자: 응답
① HTTP
HTTP 메시지는 쉽게 읽을 수 있음
② HTTPS
HTTPS의 메시지는 해석할 수 없음
- HTTPS가 제정된 초기에는 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들 위주로 HTTPS가 사용되었음
> 현재 개발되는 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세
- 웹 서버의 URL이 http://로 시작되면 HTTP, https://로 시작되면 HTTPS 프로토콜을 사용
💡 TLS 표준
- TLS의 기반이 되는 공개 키 암호 시스템 및 대칭 키 암호 시스템을 알아야 함
# 마치며
- 우리는 웹 페이지를 방문하기 위해 HTTP 요청을 보낸적도, 응답을 받아 해석한 적도 없음
> 이는 크롬, 사파리, 파이어폭스로 대표되는 웹 브라우저(Web browser) 덕분임
- 키워드
① HTTP(HyperText Transfer Protocol): 웹 서버와 클라이언트가 리소스를 교환하기 위해 사용하는 프로토콜
- 클라이언트가 요청하면, 서버가 응답하는 방식
② HTTP 메시지: HTTP 서버와 클라이언트가 교환하는 데이터
- 헤드와 바디로 구성되며, 각 줄은 CRLF로 구분됨
> 헤드: 메시지에 대한 정보. 헤드의 끝에는 CRLF가 한 줄 있음
> 바디: 클라이언트가 서버에게, 또는 서버가 클라이언트에게 전달할 데이터
③ HTTP 요청(Request): 클라이언트가 서버에게 특정 동작을 요청하는 메시지
- 메소드(Method): 요청 URI가 가리키는 리소스에 대해, 서버가 수행했으면 하는 동작을 지정
- 요청 URI(Request-URI): 메소드의 대상이 되는 리소스를 지정
④ HTTP 응답(Response): 요청을 처리한 결과 및 이유, 그리고 클라이언트에 전송할 웹 리소스를 포함하는 메시지
- 상태 코드(Status Code): 요청을 처리한 결과
- 처리 사유(Reason Phrase): 상태 코드가 발생한 이유
⑤ HTTPS(HTTP on Secure socket layer): TLS를 이용하여 HTTP의 약점을 보완한 프로토콜
'Hacking Tech > Web hacking' 카테고리의 다른 글
| [Dreamhack] Mitigation: Same Origin Policy (0) | 2022.01.26 |
|---|---|
| [Dreamhack] Background: Cookie & Session (0) | 2022.01.24 |
| [Dreamhack] Tools: Browser DevTools (0) | 2022.01.23 |
| [Dreamhack] Background: Web Browser (0) | 2022.01.22 |
| [Dreamhack] Background: Web (0) | 2022.01.17 |
