CS | HTTP Method

Stellar·2021년 5월 2일

CS Theory

THEORY

목록 보기

1/1

메소드 취약점

🔶 HTTP 메소드

📌 개념

HTTP Method란?

클라이언트가 웹서버에게 요청하는 목적 및 그 종류를 알리는 수단 (사용이유)

※ 요청 메소드의 위치 : HTTP 요청 메세지의 첫째줄

HTTP 요청 메세지란?

HTTP란?

HTTP(HyperText Transfer Protocol) : 텍스트 기반의 *통신규약으로 "인터넷에서 데이터를 주고 받을 수 있는 *프로토콜"이다.

* Protocol(통신규약) = 통신관련규약
* 통신규약 : 통신 프로토콜 또는 통신 규약은 컴퓨터나 원거리 통신 장비 사이에서 메세지를 주고받는 양식과 규칙의 체계
* 프로토콜(Protocol) 
: 공통의 데이터 교환 방법 및 순서에 대해 정희한 의사소통 약속, 규약 혹은 규칙
: 컴퓨터와 컴퓨터 사이 또는 한 장치와 다른 장치 사이에서 데이터를 원활히 주고 받기 위해 약속한 여러가지 규약

메소드란?

행동할 동작을 정의한 지시어 또는 그들의 모음

📌 Method Type

. 요청 메소드

C.R.U.D : GET(R), POST(C), PUT(U), DELETE(D)

GET : 리소스(데이터) 취득 Read

초기엔 요청 파일이 HTML밖에 없어 서버로 부터 요청하는 페이지 요청 메소드 GET뿐이였다.
URL(URI) 형식으로 웹서버측 리소스를 요청.
GET을 사용하는 요청은 오직 데이터를 받기만 한다. 즉, 상세 페이지 로드등 서버에서 어떤 데이터를 가져와서 보여주기 위한 용도의 메서드이다.

HEAD : 메세지 헤더(문서 정보) 취득

GET과 비슷하나, 실제 문서를 요청하는 것이 아니라, 문서 정보를 요청

POST : 내용 전송 (파일 전송 가능) Create

클라이언트에서 서버에 데이터를 추가, 작성 함
. 요청 데이터를 HTTP 바디에 담아 웹서버로 전송함
새로 작성된 리소스인 경우, 서버는 HTTP 헤더의 'Location:'에 URI 주소를 포함시켜 응답
행동(입력, 생성 등)하는 행위에 사용됨

GET, POST 차이점
-  두 메서드 모두 서버에게 무엇인가를 요청할 때 사용하지만 GET 방식은 'URL ? 리소스' 형태로 서버에게 요청한다. 
-  GET 방식은 간단한 데이터를 빠르게 처리할 수 있는 장점이 있지만 전송할 수 있는 리소스의 크기가 제한된다. 그 이유는 항상 URL를 포함시켜야 하기 때문에 URL 크기만큼의 공간이 사라지기 때문이다. 또한 리소스가 URL에 그대로 노출되기 때문에 보안상으로도 문제가 있다. 
-  반면 POST 방식은 HTTP 헤더 뒤에 입력 스트림 형태로 리소스를 전송하는 방식으로 URL과 리소스를 별도로 전송하기 때문에 GET 방식보다 많은 데이터를 전송할 수 있으며, 최소한의 보안 유지에 효과가 있다. 최소한인 이유는 암호화를 하지 않는다면 보안이 거기서 거기이기 때문이다. 단점으로는 같은 리소스 양일 경우 get 방식보다 처리 속도가 느리다.

PUT : 내용 갱신 위주 (파일 전송 가능) Update

POST와 비슷한 방식이지만, PUT은 서버의 데이터를 갱신, 작성 함
리소스가 갱신되어도, 서버는 HTTP 헤더의 'Location:'를 보내지 않아도 됨.
서버는 클라이언트가 제시한 URI를 그대로 사용하는 것으로 간주 클라이언트서버 측 구현에 관여하는 것으로 POST를 더 많이 사용

POST, PUT 차이점
- POST와 PUT 모두 클라이언트 측에서 서버 측에게 리소스를 전송하는 방식이지만 
- POST는 보통 INSERT 개념으로 사용되고, PUT은 UPDATE 개념으로 사용된다. 
- 또한 POST는 멱등하지 않고 PUT은 멱등하다.

DELETE : 파일 삭제 D

클라이언트 측에서 웹 리소스를 삭제할 것을 요청하는 메서드.
안전성 문제로 대부분의 서버에서 비활성
delete는 body가 없어 한개의 데이터만 삭제가 가능함
여러개의 데이터 삭제 시 put 또는 patch 사용
body 대신 path 파라미터로 데이터 전달
path 파라미터/service/myresource/user/{user}/bicycles/{bicycleId}

OPTIONS : 웹서버측 제공 메소드에 대한 질의

서버에서 해당 리소스에 대해 지원되는 메서드의 종류를 확인

CONNECT : (거의 사용 안함)

동적으로 터널 모드를 교환하기 위해 사용하는 메서드.
프록시 기능을 요청 시 사용

TRACE : (거의 사용 안함)

원격지 서버에 루프 백 메시지를 호출하기 위해 테스트용으로 사용하는 메서드.
클라이언트가 방금 보낸 요청을 다시 달라고 서버에게 요청하는 것

PATCH

PUT과 유사하게 클라이언트 측에서 요청한 리소스를 갱신할 때 사용.
PUT은 리소스 전체를 갱신하지만, PATCH는 리소스의 일부를 교체

PUT, PATCH 차이점
- 두 가지 모두 클라이언트 측에서 요청한 리소스를 갱신할 때 사용하지만 PUT은 해당 리소스의 전체를 교체하는 방식이고, PATCH는 해당 리소스의 일부를 변경하는 방식이다. 
- 또한, PUT은 멱등하지만 PATCH는 멱등하지 않다. 
- PUT은 전체 내용을 업데이트하기 때문에 동일한 리소스에 대해 동일하게 PUT을 처리하는 경우 멱등하게 처리된다. 
- 반면 PATCH는 내용의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.

정리표

출처 - 위키백과

멱등성(Idempotent)이란?

멱등성이란 특정 메서드의 요청을 여러번 하더라도 한번 요청했을 때와 결과가 같다면 멱등하다라고 한다.
PUT, DELETE, TRACE 및 GET, HEAD, OPTIONS가 멱등성을 갖는다.

GET
- 안정성과 멱등성은 신뢰할 수 없는 네트워크 상의 HTTP를 신뢰할 수 있게 만들어준다. 만약, GET요청을 하고 응답을 못 받았을 경우 한 번 더 보내더라도 이 동작은 안전하다.
- 그러므로 GET은 Idempotent하며 safe하다. 먼저 보낸 요청이 벌써 처리되었다고 하더라도 서버에 다른 영향은 없다.
POST
- POST는 비멱등성을 갖는다. 같은 POST를 연속적으로 보낸다면 명령은 여러번 내린 것처럼 부가적인 결과를 가져온다.

캐시 가능성(Cachable)이란?

향후 재사용을 위해 이에 대한 응답을 저장할 수 있음을 나타낸다.
현재 시점의 응답이나 권한 있는 응답에 의존하지 않는 안전한 메서드는 캐시 가능한 것으로 정의한다

안정성 (Safe)이란?

읽기 전용인 경우 안전한 메서드로 간주하며, GET, HEAD, OPTIONS 메서드는 안전한 메서드로 정의되어 있다.
즉, 리소스를 수정하지 않는 메소드들을 Safe 하다고 말한다.

📌 메소드 사용법

언제 사용?

메소드 종류

📌 메소드 취약점

보안상의 이유로 대부분 'GET, POST, OPTIONS' 메서드들만 허용하도록 함

왜 취약함?

일반적으로 사용하는 GET, POST 메소드 이외의 PUT, DELETE, COPY, MOVE 등의 불필요한 메소드를 허용하였을 경우 공격자가 Options를 이용하여 메소드의 종류를 확인한 뒤 웹 서버에 파일 생성, 삭제 및 수정이 가능한 취약점

출처: https://psage.tistory.com/entry/HTTP-Method-제한 [IT Etc...]

참고 사이트

정보통신기술용어해설

빡기의 코딩노트_벨로그

surim014.log_벨로그

Kang Sang Woo님 블로그

정리를 하고 싶었을 뿐인데... 마인드맵으론 감당이 안 된다..

(정리가 안 됐는데도 이 정도라니.. 너무 방대해ㅜㅜ)

Stellar