'PUT', 'DELETE' 메서드는 보안상 취약한가

'PUT', 'DELETE' 메서드는 위험하다?

가끔 연차가 오래된 개발자나 보안팀 직원 분들께서 'PUT' 이나 'DELETE' 메서드 사용을 자제하고 'GET', 'POST'만 써야한다고 주장하는 경우가 있다.

 

'PUT' 메서드가 파일 변조나 해킹 파일 업로드 등의 보안 취약점이 있는 '취약한 메서드'라는 것이다.

 

이는 정말 사실일까?

 

'PUT', 'DELETE'의 보안 취약점

1) 리소스 생성 또는 완전 대체

HTTP 표준(RFC 7231)은 PUT을 대상 리소스의 상태를 클라이언트가 보내는 표현으로 생성하거나(만들거나), 완전히 대체(replace) 하는 메서드로 규정한다. 즉, PUT은 부분 업데이트가 아니라 전체 대체(또는 새 리소스 생성) 의미를 갖는다. 이 “전체 덮어쓰기” 성격이 잘못 사용되면 기존 데이터를 잃게 될 수 있다. 

 

2)  익명/비인증 파일 업로드 문제

WebDAV(HTTP 확장)는 PUT/DELETE 등으로 웹 서버에 파일을 올리게 해주는 기능을 포함했는데, 서버가 적절히 구성되지 않거나 인증/권한 통제가 없을 때 외부에서 임의 파일을 웹 루트에 업로드하거나 기존 파일을 덮어쓸 수 있게 있었다. 이런 설정 실수로 인해 ‘PUT을 통한 무인증 파일 업로드’ 취약점이 빈번힌 발생하였다.

 

WebDAV 기능은 IIS 서버에서 모든 HTTP 메서드를 허용하면 자동으로 설정된다. 이때 이 보안 취약점을 방지하기 위해 PUT/DELETE 메서드를 사용하지 못하게 막던 임시 조치가 어느새 서버 보안 권고사항으로 자리잡았던 것으로 추정된다. 

 

3) 웹셸 업로드 · 원격 코드 실행 가능성

파일 업로드 취약점(검증 부족 등)은 공격자가 서버에 스크립트(웹셸)를 올려서 임의 명령 실행·서버 장악으로 이어질 수 있다. PUT이 열려 있으면 사용자 제시 URL에 파일을 생성할 수 있으므로, 서버측 스크립트를 업로드해 웹셸을 설치하는 공격 시나리오가 가능하다. 

 

 

그럼 진짜 위험한 거 아니야?

맞다. PUT/DELETE 메서드는 확실히 보안적으로 위험한 부분이 존재한다.

 

https://developer.mozilla.org/ko/docs/Glossary/Safe/HTTP

안전함 (HTTP 메서드) - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

 

MDN에서도 'PUT' 과 'DELETE' 메서드는 안전하지 않은(not safe) 메서드로 분류되어 있다.

하지만 RFC에서 안전함(safe)의 정의는 HTTP 메서드가 서버의 상태를 바꾸지 않고 오직 읽기(read-only)만은 수행할 때 안전하다고 정의한다. 

 

즉, PUT/DELETE 뿐만 아니라 POST 메서드도 안전하지 않은 메서드로 분류된다.

 

그렇다면, PUT/POST/DELETE 메서드를 모두 제외하고 웹 개발이 가능할까?

현실적으로 불가능하다. 오직 GET 메서드만 사용해서 웹 개발을 하는 것은 거의 불가능에 가까울 것이다.

 

PUT이 보안적 위험성이 존재한다고 사용하지 않아야 한다면, POST 메서드도 사용하지 않아야한다.

그러니, PUT 메서드 대신 POST를 사용하라는 주장은 벌써 합리적이지 않은 주장이 된다.

 

그에 더해 REST API의 등장으로 PUT은 필수적인 메서드가 되었다.

 

REST API의 등장

최근 웹 개발의 트렌드는 REST API이다. 

RESTFul 한 개발을 하는게 트렌드가 되었고, 많은 웹 프로젝트가 REST API로 개발되고 있다.

 

참고)

[Web] API란? REST API란? RESTful 이란? REST 구성 요소, 특징, 장단점

[Web] API란? REST API란? RESTful 이란? REST 구성 요소, 특징, 장단점

 

이 REST API의 등장으로 PUT 메서드는 필수적인 메서드가 되었다.

1) RESTful 한 개발

RESTful한 개발을 위해서는 HTTP 메서드 그 자체로 의미가 중요해졌다.

 

GET : 리소스 조회

POST : 리소스 생성

PUT : 리소스 수정

DELETE : 리소스 삭제

 

과거에 POST로 모든 리소스 처리를 했을 때 어떤 자원을 업데이트 하려면 URL에 액션을 넣곤 했다.

ex) POST, /v1/employee/update

 

하지만 REST API에서는 메서드 자체로 의미를 내포해야한다.

ex) PUT, /v1/employee

 

PUT 메서드를 사용함으로써 RESTful한 개발이 가능해지고 더 효율적인 개발이 가능해진 것이다.

 

2) PUT 메서드의 멱등성

PUT 메서드는 POST 메서드와 다르게 멱등성(idempotency)를 가진다.

여기서 멱등성이란 어떤 요청을 반복해도 동일한 결과를 가짐을 뜻한다.

 

POST 메서드는 그 자체로 멱등성을 가지고 있지 않기 때문에, 멱등성 있는 결과를 기대한다면

개발자가 따로 코드를 설계해야만 한다.

 

하지만 PUT 메서드는 멱등성을 가지고 있기 때문에 추가적인 개발이 필요하지 않다.

 

멱등성은 신뢰성 있는 API 설계에 매우 중요한 요소이다.

 

참고)

[Web] HTTP 메소드의 멱등성과 안정성이란? PUT 멱등성, PATCH 멱등성

[Web] HTTP 메소드의 멱등성과 안정성이란? PUT 멱등성, PATCH 멱등성

 

따라서 이 멱등성을 위해서도 'PUT' 메서드는 필수적이다.

 

3) OWASP의 주장

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods?utm_source=chatgpt.com

WSTG - Latest | OWASP Foundation

 

OWASP(오픈소스 웹 어플리케이션 보안 프로젝트)에서도 과거 레거시 웹 프로젝트에서는 PUT 메서드가 공격 파일을 서버에 심는 경우들이 있었지만, 최근에는 아주 희귀한 케이스가 되었으며 RESTFul 환경에서는 PUT을 쓰는게 더 자연스럽고 일반적이라고 주장했다.

 

또한 아래와 같이 주장했다.

 

Although it may be reported by automated scanning tools, the presence of these methods on a RESTful API is not a security issue(자동화된 스캐닝 도구에서 보고될 수 있지만 RESTful API에 이러한 메서드가 존재한다고 해서 보안 문제는 아닙니다)

 

 

보안적 강화

그럼에도 불구하고 흥선대원군 같은 개발자 분들은 "어쨌든, POST로 PUT을 대체할 수 있잖아? 굳이 위험을 감수해야돼?" 라고 하실지도 모르겠다.

 

하지만, 위에도 말했듯이 PUT의 위험성은 POST에도 존재한다. 

최신 웹 프레임워크(Spring, Node 등)에서는 POST 메서드로도 웹 변조 파일을 업로드 할 수 있고, 서버 자원을 변조할 수도 있다.

 

그럼으로 PUT대신 POST를 쓰라는 말은 어불성설이다.

 

거기에 더해 최근에는 PUT/DELETE 메서드를 안전하게 사용할 수 있는 상황이 많이 만들어졌다.

1) 인증/인가 강화

예전에는 인증/인가 받지 않은 사용자가 HTTP 요청을 보내 서버 자원에 접근할 수 있는 경우가 많았다.

하지만 최근 웹 개발 프로젝트에는 쉽게 인증/인가 서비스를 추가할 수 있다.

 

Spring Security나 Filter, Interceptor 등으로 인증 서비스를 쉽게 개발할 수 있게 되었고,

인증받지 못한 사용자는 HTTP 메서드를 사용하더라도 서버 자원에 쉽게 접근할 수 없게 되었다.

 

2) 메서드 제한

특정 서버 자원에 접근할 수 있는 메서드를 제한할 수 있게 되었다.

A라는 자원에 접근할때는 무조건 GET 메서드로 조회만 가능하게 한다거나,

PUT 메서드를 사용할 때는 인증 받은 사용자만 가능하게 화이트 리스트를 만들 수도 있다.

 

3) API의 엔드포인트화

과거엔 PUT 메서드 그 자체가 바로 서버에 작용해 웹 서버에 파일을 업로할 수 있었다.

 

하지만 최근 웹 프레임워크 환경에서 API는 라우터 레벨의 엔드포인트로 사용하고 있다.

즉, 메서드가 직접 서버에 접근한다기보다는 서버에 요청을 전달하는 방식으로 사용되고 있다.

 

이때 서버는 메서드의 전달을 받아 보안 프로토콜을 실행한 후 요청을 처리할 수 있다.

 

 

빅테크 기업들의 사례

세계 여러 빅테크 기업들의 최신 OPEN API를 살펴보아도 PUT/DELETE 메서드를 사용하는 것을 확인할 수 있다.

• 네이버 : https://api.ncloud-docs.com/docs/compute-cloudfunctions-putaction
• 카카오 : https://developers.kakao.com/docs/latest/ko/rest-api/reference
• 구글 : https://cloud.google.com/storage/docs/xml-api/put-object
• AWS : https://docs.aws.amazon.com/apigateway/latest/api/API_PutMethod.html
• Meta(구 Facebook) : https://developers.facebook.com/docs/graph-api/batch-requests/?utm_source=chatgpt.com

 

이처럼 유수한 빅테크 기업들조차 PUT/DELETE 메서드를 Open API로 제공하고 있다.

이는 최근 웹 개발 생태계에서 PUT/DELETE 메서드가 널리 사용되고 있으며, 보안적인 이슈가 없음을 뒷받침하는 증거라고 볼 수 있다.

 

결론

PUT/DELETE 메서드는 보안적인 위험성이 존재하지만, POST 또한 동일한 보안적 위험성이 존재한다.

결국엔 POST던, PUT/DELETE던, 개발자가 보안에 유의하여 개발한다면 RESTFul한 개발을 진행하며 효율적이고 안전한 개발을 할 수 있을 것이다.

 

만약 자신의 회사 혹은 팀에서 PUT/DELETE 메서드를 무조건 막겠다고 한다면,

구닥다리 보안 규정을 아직까지 놓고 있지 못하냐고 말해주자.