[인코딩(Encoding)]
♣ 인코딩(Encoding) : 데이터를 컴퓨터가 이해할 수 있는 바이너리 형식으로 변환하는 과정을 말한다. 인코딩 표준에는 대표적으로 아스키(ASCII)와 유니코드(Unicode)가 있다.
♣ 아스키(ASCII) : 7비트 데이터에 대한 인코딩 표준이다. 이를 이용해 알파벳과 특수 문자 등을 표현할 수 있다.
예를 들어, '1000001'은 'A'로 해석된다.
♣ 컴퓨터 개발 초기, 영어는 아스키, 한글은 CP-949, EUC-KR 등 각 문자권마다 고유의 인코딩 표준을 사용했다. 그런데 이런 방식은 다른 나라 문자를 사용할 때, 글자가 깨지거나 다른 문자가 출력되는 등 인코딩이 호환되지 않아 문제가 발생하였다. 그렇게 해서 만들어진 표준이 유니코드(Unicode)이다.
♣ 유니코드(Unicode) : 모든 언어의 문자를 하나의 표준에 담겠다는 목표롤 제정된 인코딩 표준 방식이다. 유니코드에서 한 문자는 최대 32비트로 표현된다. 32트로 표현할 수 있는 정보의 개수는 2^32개, 약 42억개를 나타낼 수 있어 전 세계의 문자를 표현하고도 남는다. 최근에는 문자 외에 각종 이모지(Emoji)들도 유니코드에 포함시켜 사용하고 있다. 😀😁😂🤣😄😍
[프로토콜(Protocol)]
♣ 웹 서버에 있는 리소스를 클라이언트가 받아 보기 위해서는 웹에세 특정 리소스를 지정해 제공 요청해야한다. 그러면 서버가 해당 요청을 이해하고, 대응되는 동작을 통해 클라이언트에게 리소스를 반환한다.
♣ 위 과정에서 클라이언트의 행위를 요청(Request), 서버의 행위를 응답(Response)이라고 한다.
♣ 프로토콜(Protocol) : 요청과 응답같은 규격화된 상호작용에 적용되는 약속 및 규약을 말한다. 많은 컴퓨터 통신 프로토코은 각 통신 주체가 교환하는 메시지를 명확하게 해석할 수 있도록 문법(Syntax)을 포함하고 있다.
♣ 현재까지 제정된 표준 프로토콜에는 네트워크의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP 등 다양한 프로토콜이 존재하고 있다.
[HTTP(Hyper Text Transfer Protocol)]
♣ HTTP(Hyper Text Transfer Protocol) : 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜이다. 팀 버너스 리(Team Berners-Lee)와 그의 팀원들이 제정한 이후, 현대 웹 서비스의 바탕이 되는 프로토콜로 자리 잡게 되었다.
♣ HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면 서버가 응답하는 것이다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트를 열어 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. HTTPS의 경우 TCP/443번을 이용한다.
♣ 네트워크 포트(Network Port) : 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소를 의미한다. 클라이언트가 서버의 포트에 접근하여 요청을 전송하고, 서버가 클라리언트에 보낼 데이터를 담아 전송하는 과정이 마치 항구(Port)에서 이용자가 보낼 짐을 항구에 내려놓고 배에 짐을 실어서 보내는 이미지를 연상하게 한다. 편의상 네트워크를 설명하는 맥락에서는 '네트워크'를 생략하고 '포트'라고 부른다.
♣ 서비스 포트(Service Port) : 네트워크 포트 중 특정 서비스가 점유하고 있는 포트를 의미한다. HTTP의 80번 포트를 예로 들 수 있다. 포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer, L4)의 프로토콜을 따른다.
대표적으로 전송계층의 프로토콜로는 TCP와 UDP가 있다. TCP와 UDP는 데이터를 전송해준다는 목적은 동일하지만 신뢰성 유무라는 가장 큰 차이점이 존재한다. 그래서 TCP와 UDP는 서로 데이터를 교환할 수 없기 때문에 서비스 포트를 표기할 때 서비스가 사용하는 전송 계층의 프로토콜을 앞에 표시해주어야 한다.
예를 들어, HTTP의 서비스 포트가 TCP/80이라고 표기되어 있으면 HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 것으로 해석한다.
♣ 포트의 개수는 운영체제마다 다르다. 현대의 윈도우나 유닉스/리눅스, 맥 운영체제는 0~65535번까지의 네트워크 포트를 사용한다.
그 중 0~1023번 포트는 잘 알려진 포트(Well-known port) 또는 특권 포트(Privieged port)라고 하며, 각 포트 번호에 자주 사용되는 서비스가 등록되어 있다.
대표적으로 22번 포트에는 SSH, 23번에는 Telnet, 80번에는 HTTP, 443번에는 HTTPS가 할당되어 있다. 잘 알려진 포트에 서비스를 실행하기 위해서는 관리자 권한이 필요하다. 따라서 클라이언트는 이 대역에서 실행중인 서비스들은 관리자의 소유임을 신뢰할 수 있게 되는 것이다.
[HTTP 메시지]
♣ HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청과 서버가 반환하는 HTTP 응답이 있다. 두 메시지는 HTTP 헤더와 바디로 구성되어 있고, 기능과 세부 구조는 다르다는 특징이 있다.
♣ CRLF(Carriage Return / Line Feed) : CRLF는 Carriage Return(CR)과 Line Feed(LF)의 조합을 나타낸다.
CR는 커서를 현재 줄의 맨 앞으로 이동시키는 문자이고, LF는 커서를 다음 줄로 이동시키는 문자이다. 이것들은 주로 텍스트 파일에서 줄 바꿈을 나타내는 데 사용되는 제어 물자열이다. 윈도우 운영체제에서는 줄을 종결하기 위해 CRLF를 사용하고, 리눅스같은 유닉스 기반 운영체제에서는 LF만을 사용한다.
♣ HTTP 헤더(Headers) : 각 줄은 CRLF로 구분되며, 첫 줄은 시작 줄(Start Line), 나머지 줄은 헤더(Header)라고 부른다. 그리고 헤더의 끝은 빈 줄(공백 줄)로 나타낸다.
헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타낸다. 하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있다.
시작줄 | GET / HTTP/1.1 |
헤더 (HTTP 헤드) | Connection : keep-alive User-Agent : Mozilla/5.0 (Macintosh: Intel Mac Os X 10_14_6) ... Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 ... Accept-Encoding : gzip, deflate, br, zstd Content-longth: 2025 Content-type: application/json |
빈 줄(공백 줄) | |
HTTP 바디 | {email: odong@odong.study, password: "odongpassword"} |
♣ HTTP 바디(Body) : HTTP 바디는 헤더의 끝을 나타내는 CRLF 뒤 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 바디에 담기게 된다.
[HTTP 요청 메시지]
♣ HTTP 요청은 서버에게 특정 동작을 요구하는 메시지이다. 서버는 해당 동작이 실현 가능한지, 클라이언트가 해당 동작을 요청할 권한이 있는지 등을 검토하고, 적합하면 이를 처리한다.
♣ HTTP 요청의 시작 줄은 메소드(Method), 요청 대상(Request target)인 URI, HTTP 버전으로 구성된다. 각각은 띄어쓰기로 구분한다.
♣ 메소드(Method) : 요청 대상에 서버가 수행하기를 바라는 동작을 나타낸다. HTTP 표준에 정의된 메소드는 8개로 구성되어 있고, 자주 사용되는 메소드에는 GET과 POST가 있다.
♣ GET 메소드 : 리소스를 전달해 달라고 요청하는 메소드이다. 이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하게 되면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이 때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아온다.
♣ POST 메소드 : 요청 대상에게 데이터를 보내는 메소드이다. 전송할 데이터는 대부분 HTTP 바디에 포함된다. 로그인시 입력하는 아이디와 패스워드, 게시판에 작성하는 글 등이 POST로 서버에 보내진다.
♣ 이 외에 요청 URI는 메소드의 대상을, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타낸다.
[HTTP 응답 메시지]
♣ HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지이다. 요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status)와 클라이언트에게 전송할 리소스가 응답에 포함된다.
♣ HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 처리 사유(Reason Phrase)로 구성된다. 이것 역시 띄어쓰기로 구분 되어진다.
♣ HTTP 버전은 서버에서 사용하는 HTTP 프로토콜의 버전을 나타낸다. 그리고 상태 코드는 요청에 대한 처리 결과를 세 자릿수의 숫자로 나타낸다. HTTP 표준인 RFC 2616은 약 40개의 상태 코드를 정의하고 있는데, 각 첫 번째 자릿수에 따라 5개의 클래스로 분류된다. 처리 사유는 상태코드가 발생한 이유를 짧게 기술한 것이다.
상태 코드(Status Code) | 설명 | 예시 |
1XX | 요청을 제대로 받았고, 처리가 진행중임 | |
2XX | 요청이 제대로 처리됨 | - 200 OK : 성공 |
3XX | 요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함 | - 302 Found : 다른 URL로 갈 것 |
4XX | 클라이언트가 잘못된 요청을 보내어 처리에 실패함 | - 400 Bad Request : 요청이 문법에 맞지 않음 - 401 Unauthorized : 클라이언트가 요청한 리소스에 대한 인증이 실패함 - 403 Forbidden : 클라이언트가 리소스에 요청할 권한이 없음 - 404 Not Found : 요청한 리소스가 없음 |
5XX | 클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패함 | - 500 Internal Server Error : 서버가 요청을 처리하다가 에러가 발생함 - 503 Service Unavailable : 서버 과부하로 인해 요청을 처리할 수 없음 |
[HTTPS]
♣ HTTP의 응답/요청 메시지는 평문으로 전달된다. 만일 웹 프록시 도구 등을 사용해 가로챈다면 중요한 정보가 노출 될 수 있다. 특히, 로그인시 전송한 POST 요청에는 사용자의 아이디와 패스워드가 포함되어 전송되는데, 공격자가 중간에 이를 가로채면 이용자의 계정이 탈취될 수 있다.
♣ HTTPS(HTTP over Secure socket layer)는 TLS(Transport Layer Security) 프로토콜을 도입하여 HTTP의 문제점을 보완하였다. TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화한다. 공격자가 중간에 메시지를 탈취하더라도 이를 해석하지 못하게 하며, 결과적으로 HTTP 통신이 도청과 변조로부터 보호될 수 있게 된다.
♣ HTTPS 제정 초기에는 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들을 위주로 사용되었으나, 현재 대부분의 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세이다.
♣ 웹 서버의 URL이 http://로 시작된다면 HTTP이고, https://로 시작된다면 HTTPS 프로토콜을 사용하는 것이다.
'정보보안 > 모의해킹' 카테고리의 다른 글
[웹 해킹] 웹 해킹 (4)- 웹 기초 [개발자도구] (0) | 2025.01.17 |
---|---|
[웹 해킹] 웹 해킹 (3)- 웹 기초 [브라우저 / Domain Name / URL / 웹 렌더링] (0) | 2025.01.16 |
[웹 해킹] 웹 해킹 (1) - 웹 기초 [웹 / 프론트엔드 / 백엔드 / 웹 리소스 / HTML / CSS / JS / 웹 통신 ] (0) | 2025.01.15 |
[웹 해킹] Burp Suite의 기능 (0) | 2024.12.21 |