HTTP(Hyper Text Transfer Protocol) 개념과 취약점

HTTP(Hyper Text Transfer Protocol) 개념과 취약점

 

 

HTTP(HyperText Transfer Protocol)는 인터넷을 통해 데이터를 송수신하는 데 사용되는 프로토콜이다.

 

-목차-
0. HTTP 역사
1. HTTP 개요
2. HTTP 요청(requests)
3. HTTP 응답(response)
4. HTTP 헤더(HEADER)
5. HTTP method
6. HTTP 상태코드

---

0. HTTP 역사

 

HTTP1.0

HTTP는 1990년 대기 시간이 짧은 요청을 위해 시작되었고, GET방식을 사용해 지정된 경로로 식별되는 하이퍼텍스트 문서의 전송을 요청했다. 웹이 성장함에 따라 HTTP는 메시지 내에 요청과 응답을 포함하게되고, 미디어 유형도 사용하여 다양한 데이터 형식을 전송하고, 리퀘스트 요청을 통해 라우팅하도록 확장되었다. 이게 HTTP1.0이다.

 

HTTP1.1

HTTP/1.1은 기존 텍스트 기반 메시징 구문과의 호환성을 유지하면서 프로토콜의 기능을 개선했다. 정적, 동적 모두를 길이 기반 데이터 구분 기호와 콘텐츠 협상을 위한 일관된 프레임워크, 조건부 요청에 대한 유효성 검사기, 캐시 일관성 향상을 위한 캐시 컨트롤, 부분 업데이트 요청 및 기본 영구 연결이 포함된다.

 

HTTP/2

HTTP/2는 효율적인 필드 압축 및 서버 푸시로 동시에 HTTP 메시지를 교환하기 위해 기존 TLS 및 TCP 프로토콜에다가 멀티플렉스 세션 계층을 도입했다.

 

HTTP/3

HTTP/3은 TCP 대신 UDP를 통한 보안 멀티플렉스 전송으로 QUIC를 사용함으로써 동시 메시지에 대해 더 큰 독립성을 제공한다.

 

---

1. HTTP 개요

HTTP의 목적은 클라이언트와 서버가 HTML 페이지, 이미지 및 기타 유형의 미디어와 같은 데이터를 요청하고 수신하는 표준화된 방법을 제공하는 것이다. HTTP는 Client에서 Server로 보내는 Requests와 Server에서 Client로 보내는 Response를 정의한다.

클라이언트가 HTTP 요청을 할 때 원하는 작업(예를들면 검색)과 페이지의 URL 같은 필요한 매개 변수를 지정한다. 요청에는 요청 중인 데이터 유형, 클라이언트의 언어 기본 설정 및 모든 인증 자격 증명과 같은 요청에 대한 추가 컨텍스트를 제공하는 헤더 정보도 포함된다.

서버는 요청을 처리하고 요청된 데이터(있는 경우)와 콘텐츠 유형 및 데이터 길이와 같은 응답에 대한 헤더 정보를 포함하는 HTTP 응답을 반환함. 응답에는 성공적인 요청의 경우 200 OK, 존재하지 않는 리소스에 대한 요청의 경우 404 Not Found와 같이 요청의 결과를 나타내는 상태 코드도 포함된다.

---

2. HTTP 요청(requests)

HTTP 요청은 클라이언트가 데이터를 검색하거나 전송하기 위해 서버에 요청하는 것이다. 요청중인 데이터 유형 및 반환 방법에 대한 정보를 서버에 제공하는 다양한 구성 요소가 포함되어 있다.

 

URL(Uniform Resource Locator)

 

요청되는 데이터의 위치를 지정하는 HTTP 요청의 가장 중요한 구성 요소.
URL은 프로토콜(HTTP 또는 HTTPS), 서버의 도메인 이름 및 서버 내 리소스의 특정 위치로 구성된다.

 

 

 

Method

 

클라이언트가 서버에 수행하도록 요청하는 작업 유형을 지정한다. 가장 일반적으로 사용되는 방법은 데이터를 검색할 때 사용되는 "GET"과 데이터를 보낼때 사용하는 "POST"(서버에 데이터 제출)다. 다른 메소드로는 "PUT"(데이터 업데이트), "DELETE"(데이터 삭제) 및 "HEAD"(응답의 헤더만 검색)이 있다.

 

 

 

Headers

 

요청에 대한추가 정보이며 요청 및 클라이언트에 대한 추가 정보를 제공하는 키-값이고, 요청 중인 데이터 유형, 데이터 인코딩, 클라이언트의 기본 언어 및 모든 인증 자격 증명에 대한 정보가 포함된다. 대표 헤더로 "Accept"(클라이언트가 처리할 수 있는 MIME 유형 지정), "User-Agent"(클라이언트 소프트웨어 식별) 및 "Referer"(클라이언트를 참조한 페이지의 URL)가 있다.

 

 

 

Body

 

서버로 전송되는 실제 데이터다. 서버에 제출할 데이터를 포함하는 요청의 페이로드가 된다. "POST" 및 "PUT" 요청에만 존재한다. 일반적으로 POST 요청과 함께 사용되지만 PUT 메소드랑도 사용될 수 있다. 본문은 JSON 또는 XML과 같은 특정 형식으로 인코딩되며 텍스트, 이미지 및 이진 데이터를 비롯한 다양한 유형의 데이터를 포함한다.

 

 

---

 

3. HTTP 응답(response)

 

클라이언트가 서버에 HTTP 요청을 보내면 서버는 요청을 처리하고 HTTP 응답을 반환한다. 응답에는 요청된 데이터와 요청 결과를 나타내는 상태 코드가 포함된다. 헤더는 응답에 대한 추가 정보를 제공하고 본문에는 데이터가 포함된다. 클라이언트는 이 정보를 사용하여 요청된 데이터를 사용자에게 표시한다.

 

Status Code

 

요청 결과를 나타내는 3자리 코드다. 보통 200번대는 정상, 400번대는 찾을수 없음, 500번대는 내부 서버 오류를 나타낸다.

 

 

헤더

 

콘텐츠 유형, 날짜 및 콘텐츠 길이와 같은 응답에 대한 추가 정보를 제공한다.

 

 

 

Body

 

요청에 대한 응답으로 반환되는 데이터를 포함한다. 본문에는 HTML, 이미지 또는 기타 유형의 데이터가 포함될 수 있다.

 

 

 

---

 

4. HTTP 헤더(HEADER)

 

HTTP 헤더는 요청 또는 응답을 처리하는 방법을 결정하기 위해 클라이언트 또는 서버에서 사용할 수 있는 추가 정보를 제공한다.또한 콘텐츠 협상, 인증 및 캐싱과 같은 다양한 용도로 사용할 수 있는 클라이언트와 서버 간에 메타데이터 및 추가 정보를 전달하는 방법을 제공한다.
리퀘스트에서 사용되는 요청헤더와 리스폰에서 사용되는 응답헤더 두 가지 유형이 있다.

 

 

 

요청 헤더(requests header)

요청 헤더에는 가져올 리소스에 대한 정보와 리소스를 요청하는 클라이언트에 대한 정보가 포함된다.

 

Accept: 요청 또는 응답에서 허용되는 MIME 타입을 지정한다.
Accept-Language : 응답의 기본 언어를 지정한다.
Accept-Encoding: 요청 또는 응답에서 허용되는 압축 형식을 지정한다.
Authorization: 클라이언트의 인증 정보를 전송한다.
Cache-Control: 캐시 동작을 제어하는 캐시 명령을 지정한다.
Connection: 현재 요청의 연결 옵션을 지정한다.
Content-Length: 요청 또는 응답 본문의 길이 (바이트)를 지정한다.
Content-Type: 요청 또는 응답 본문의 MIME 타입을 지정한다.
Cookie: 클라이언트의 쿠키를 전송한다.
Date: 요청 또는 응답의 날짜와 시간을 지정한다.
Host: 요청되는 서버의 도메인 이름을 지정한다.
Referer: 클라이언트가 현재 페이지로 연결된 페이지의 URL을 지정한다.
User-Agent: 클라이언트 소프트웨어에 대한 정보를 지정한다.

 

 

 

HTTP 응답 헤더 (response header)

HTTP 응답 헤더는 클라이언트 및 서버의 요구 사항과 전송되는 데이터 유형에 따라 다르다.

 

Content-Type: text/html, application/json 또는 image/jpeg와 같은 응답 본문의 MIME 유형을 지정한다.
Date: 서버에서 응답을 생성한 날짜와 시간을 지정한다.
Server: 응답을 생성한 웹 서버 소프트웨어의 종류와 버전을 지정한다.
Content-Length: 응답 바디의 길이를 바이트 단위로 지정한다.
Connection: 응답을 전송하는 데 사용된 연결의 종류를 지정한다. 예를 들어 Keep-Alive 또는 Close가 있다. Location: 요청 결과로 이동하거나 생성된 리소스의 URL을 지정한다.
Set-Cookie: 서버가 클라이언트의 브라우저에 설정하려는 쿠키를 지정한다.
Cache-Control: 공개, 비공개 또는 캐시 없음과 같은 캐싱 메커니즘의 동작을 제어하는 캐시 제어 지시문을 지정한다.
ETag: 리소스의 특정 버전을 식별하는 문자열인 엔터티 태그를 지정한다.
Expires: 응답이 부실한 것으로 간주되어 서버에 새 요청을 해야 하는 날짜와 시간을 지정한다.
Last-Modified: 리소스가 마지막으로 수정된 날짜와 시간을 지정한다.

 

 

HTTP 헤더 파이썬코드

 

import requests //requests 요청
url = "https://www.url.com"
response = requests.get(url) //get method

 

 

---

5. HTTP method

HTTP 요청(requests)에서 서버의 리소스와 상호작용 사용되는 방법을 정의한다. 다양한 방식으로 서버의 리소스와 상호작용한다.

 

GET

 

GET 메서드는 서버에서 리소스를 검색하는 데 사용된다. 가장 널리 사용되는 방법이며 서버에서 정보나 데이터를 검색하는 데 사용된다. 서버의 상태 또는 리소스를 수정하지 않고 데이터를 가져오기만 한다. 여러 번 반복할 수 있다.

 

취약점: URL을 통해서 서버 로그, 브라우저 기록 및 네트워크 트래픽에서 볼 수 있는 정보가 노출되는거.

 

 

 

POST

 

POST 메서드는 양식을 제출하거나 서버에 파일을 업로드할때 처리를 위해 데이터를 서버에 제출하는 데 사용된다.
동일한 요청을 반복하면 여러 작업이 수행될 수 있다.

 

취약점: 클라이언트가 악의적인 데이터를 서버에 제출하고 서버의 보안을 손상시킬 수 있다. 그래서 XSS(크로스 사이트 스크립팅) 및 CSRF(크로스 사이트 요청 위조) 공격에 취약하다. 악의적인 웹 사이트가 사용자를 속여 다른 웹 사이트에 대한 POST 요청을 하도록 유도해서 원하지 않는 작업을 수행시킬 수 있다.

 

 

 

PUT

 

PUT 메서드는 서버의 기존 리소스를 업데이트하는 데 사용한다. POST와 유사하지만 클라이언트가 업데이트할 정확한 리소스를 지정해야 한다. 그리고 요청을 여러 번 반복해도 한 번 실행한 것과 같음.

 

취약점: 데이터가 암호화되지 않은 경우 요청 본문의 민감한 정보 노출과 잠재적인 XSS 및 CSRF 공격위험이 있다. 또, 인젝션 위험이 있다. 사용자 제공 데이터가 PUT 요청에 포함되어 공격자가 악의적인 코드나 데이터를 서버 리소스에 주입해서 서버를 무단으로 변경할 수 있다.

 

 

 

DELETE

 

서버에서 리소스를 삭제하는 데 사용된다. 소스를 영구적으로 제거하기 때문에 위험한 방법이다.

 

취약점: 데이터가 암호화되지 않은 경우 요청 본문의 민감한 정보 노출과 잠재적인 XSS 및 CSRF 공격위험이 있다. 서버를 무단으로 변경할 수 있다.

 

 

 

HEAD

 

본문 없이 응답의 헤더 정보만 검색한다. 같은 검색이지만 GET이랑 다른점은 본문이 아닌 헤더만 반환한단 점이다. 리소스가 마지막으로 검색된 이후 수정되었는지 확인하는 데사용된다.

 

취약점: 공격자가 서버 모르게 리소스를 열거하고 서버에 대한 정보를 얻기 위해 사용할 수 있다.

 

 

 

PATCH

 

서버의 리소스중 일부를 업데이트한다. PUT과 다른점은 클라이언트가 업데이트해야 하는 리소스 부분만 지정할 수 있는 것이다.

 

취약점: 리소스의 일부만 업데이트해서 보안 조치를 우회하거나 데이터를 조작하는 데 사용할 수 있다.

 

 

 

OPTIONS

 

OPTIONS 메서드는 리소스와 통신하기 위한 옵션 및 요구 사항을 결정한다.

 

취약점: 정보를 검색하기만 하고 서버의 데이터를 수정하지 않기 때문에 안전한 편이지만 GET과 마찬가지로 요청의 URL 또는 본문에 정보가 노출되지 않도록 해야한다.

 

---

6. HTTP 상태코드

 

 

HTTP 상태 코드는 클라이언트의 요청에 대한 응답으로 서버에서 반환하는 3자리 코드다. 요청이 성공했는지, 오류가 있었는지 또는 서버에 추가 정보가 필요한지와 같은 요청 결과를 알 수 있다.

 

 

1xx Informational

 

이 상태 코드 클래스는 클라이언트의 요청이 수신되어 이해되었지만 서버에서 여전히 처리 중임을 나타낸다.

 

 

2xx Success

 

클라이언트의 요청이 성공적으로 수신, 이해 및 수락되었음을 나타낸. 이 클래스에서 가장 일반적인 상태 코드는 클라이언트의 요청이 성공적으로 처리되었음을 의미하는 200 OK다.

 

200 OK: 요청이 성공했고 요청된 리소스가 클라이언트에 반환됨
201 생성됨: 요청이 성공했고 그 결과 서버에 새 리소스가 생성됨
204 콘텐츠 없음: 요청이 성공했지만 반환할 표시가 없음

 

 

 

3xx Redirection

 

요청을 완료하기 위해 클라이언트 측에서 추가 작업이 필요할때 나타난다.

 

301 영구적으로 이동됨: 요청된 리소스가 새 위치로 영구적으로 이동되었음
302 찾음: 요청된 리소스가 일시적으로 다른 URI에 있음
304 수정되지 않음: 클라이언트의 캐시된 리소스 복사본이 최신 상태이며 추가 작업이 필요하지 않음

 

 

 

4xx Client Error

 

클라이언트 요청에 오류가 있을때 나타난다.

 

400 잘못된 요청: 요청이 잘못되었거나 서버에서 이해할 수 없음
401 권한 없음: 클라이언트가 요청된 리소스에 액세스하려면 자체 인증을 받아야 함을 의미
403 금지됨: 클라이언트가 요청된 리소스에 액세스할 수 있는 권한이 없음
404 찾을 수 없음: 요청한 리소스를 서버에서 찾을 수 없음
429 너무 많은 요청: 클라이언트가 지정된 시간에 너무 많은 요청을 했음을 나타낸다.

 

 

 

5xx Server Error

 

클라이언트 요청을 처리하는 동안 서버에 오류가 발생한 것이다.

 

500 내부 서버 오류: 서버에서 오류가 발생함

 

 

 

취약점

이러한 상태 코드는 성공 또는 실패여부뿐 아니라공격자가 요청의 특성 및 리소스 상태에 대한 추가 정보를 제공하는 데에도 사용될 수 있다.
예를 들어 상태 코드 201 Created는 POST 요청의 결과로 새 리소스가 생성되었으며 새로 생성된 리소스는 Location 헤더에 제공된 URL에서 액세스할 수 있음을 나타낸다.

또, 웹 애플리케이션의 잠재적인 취약점을 식별하는 데 사용될 수 있다.
예를 들어 400 잘못된 요청 응답은 서버가 사용자 입력의 유효성을 제대로 검사하지 않아 XSS(교차 사이트 스크립팅) 또는 SQL 주입과 같은 여러 공격에 취약할 수 있음을 나타낼 수 있다.
500 내부 서버 오류 응답은 서버가 추가 공격을 시작하는 데 사용할 수 있는 오류 메시지에 중요한 정보를 공개하고 있음을 의미할 수 있다.