S3 Presigned URL PUT or POST

[w0uldy0u]

[kimhji]

주장

POST를 쓰는 게 좋다고 생각합니다.

근거

파일 크기 제한

PUT은 보안적으로 취약하다

post는 presigned url 서명 시 파일의 최대 크기를 제한해둘 수 있습니다! 이는 브라우저 단에서 저장할 수 있는 데이터의 크기를 제한해둠으로써 무방비하게 큰 데이터가 올라오는 것을 방지할 수 있습니다.

PUT으로도 브라우저에서 업로드할 데이터의 크기를 미리 전해줌으로써 제한을 둘 수 있느나, 이는 외부에서 들어오는 API의 content-length를 신뢰하겠다는 의미와 동일합니다. 만약 client가 “10KB 데이터를 줄 겁니다!”라고 업로드 데이터를 준다고 했을 때, 이후에 만들어진 presigned url은 응답으로 제공되기 때문에 사용자가 공격하고자 하면 어떤 데이터든 만료 시간 전까지 업로드가 가능합니다.

10KB를 업로드 할 것이라고 서명해두고 client가 100GB 짜리 데이터를 올리려고 하더라도, S3에서는 정확히 같은 크기의 데이터인지를 보기 위해서 그 모든 트래픽이 전송된 이후에나 알맞지 않은 데이터라는 것을 알게 됩니다!

https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOSTConstructPolicy.html

공식 문서에서도, POST에서는 max length를 policy로 지정할 수 있기 때문에 요청을 중간에 끊을 수 있다고 나와 있습니다.

아래 에러 코드에도 proposed라고 명시해두는 것을 보면 알 수 있습니다!

https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html

PUT은 정확한 데이터 크기를 고집한다

또한 put을 사용했을 때 정확히 같은 파일 크기를 제공해주어야 한다는 점도 하나의 단점이라고 보입니다.

PUT presigner를 사용하는 입장에서는 브라우저 단에서 동작하는 파일 데이터의 업로드가 반드시 정확한 데이터 크기를 받았다고 가정합니다. 데이터를 주고 받는 네트워크 환경에서는 중간에서 프록시에 의해 데이터를 chunked 방식으로 쪼갤 수도 있고, 저희가 통제할 수 없는 데이터의 미세한 변동이 주어졌을 때에도 서비스는 업로드 실패라는 결과를 내보냅니다!

정확한 데이터 크기가 설령 “Presigned url 생성 요청을 보냈을 때와 실제 보내는 파일이 일치함을 체크할 수 있는 하나의 방식”이라고 생각하실 수도 있지만, 데이터의 크기는 조작 가능한 데이터일 뿐더러 보안적인 측면에서 판별을 해야겠다면 checksum 등의 다른 방식을 사용하는 것이 더 목적성에 알맞을 것 같습니다.

추가 이야기

공식 sdk에서 제공하지 않는 기능이라 안정적이지 못하다는 우주님의 생각도 일리 있다고 생각합니다.
다만 저희는 이미 구현이 완료가 되었고, 아래와 같이 S3와 비슷한 환경을 제공하는 minIO로 테스트도 완료해둔 상황입니다!

POST로 진행하고, sdk에서 지원하지 않는 부분으로 인해 문제가 생긴다면 그때 바꾸는 방식이 어떨까요?

• 업로드된 데이터

• 큰 데이터를 넣었을 때의 응답

[w0uldy0u]

#215 에서 POST를 사용할 것을 요청드렸던건 순전히 파일 크기 제한을 위해서였습니다.
그런데 PUT 방식으로도 파일 크기 제한을 할 수 있다면

1. AWS SDK에서 공식으로 지원하여 코드가 간단해지고
2. SigV4 서명 로직을 SDK에 맡겨 실수의 여지도 줄일 수 있고
3. 프론트엔드에서도 multipart form에 여러 필드와 파일을 넣는 것에 비해 간편해지므로

POST를 사용하는 것에 비해 장점이 많습니다.
결국 논점은 PUT으로도 파일 크기 제한을 할 수 있는지가 되어야 하는데, 이 부분에서 일부 오해가 있으신듯 하여 얘기 해보고자 합니다.

길어질 것 같아서 결론부터 말씀드리면 아래 적을 내용에도 불구하고,
POST 사용하는 것에 동의한다는 사실을 먼저 알려드립니다...

---

PUT은 정말 보안상 취약한가

PUT 방식은 외부의 content-length를 신뢰하겠다는 의미여서

10KB를 업로드 할 것이라고 서명해두고 client가 100GB 짜리 데이터를 올리려고 하더라도, S3에서는 정확히 같은 크기의 데이터인지를 보기 위해서 그 모든 트래픽이 전송된 이후에나 알맞지 않은 데이터라는 것을 알게 됩니다!

라고 해주셨는데
이 부분은 사실과 다릅니다.

HTTP 표준에 따라 서버는 헤더의 content-length에 적혀있는 만큼만 읽어들입니다.
그리고 PUT 방식에서 크기를 제한하고자 할때는 SignedHeaders에 API 서버와 클라이언트가 사전 합의한 content-length를 넣어두기 때문에
API 서버와 합의된 content-length만을 사용할 수 있습니다.

content-length에 10KB라고 적고 body를 100GB 보내면 서버는 10KB만 읽고 멈출 것이고,
10KB를 올리겠다고 서명했는데 content-length에 100GB를 보낸다면
S3는 파일을 받기 전에 SigV4에 따라 헤더부터 검증하고 에러를 응답하기 때문에 공격이 성립하지 않습니다.

추가로.. 이 부분은 논점에서 좀 벗어난 내용인거 같지만 그냥 지나치기 아쉬워 아는척 좀 해보자면(ㅎㅎ;)

보안적인 측면에서 판별을 해야겠다면 checksum 등의 다른 방식을 사용

checksum은 충돌 내성이 작아 이러한 목적으로 사용하기엔 부적합 합니다.
사전 합의된 데이터와 같은 데이터인지를 확인하려면 해시를 사용해야합니다..!

근데 사실 이건 PUT을 쓰냐 POST를 쓰냐에서 중요하지 않은 얘긴거 같아요
뭐가 업로드 되든 우리는 파일 크기 제한만을 달성하면 되니까요

---

그래도 POST를 사용해야한다

PUT presigner를 사용하는 입장에서는 브라우저 단에서 동작하는 파일 데이터의 업로드가 반드시 정확한 데이터 크기를 받았다고 가정합니다. 데이터를 주고 받는 네트워크 환경에서는 중간에서 프록시에 의해 데이터를 chunked 방식으로 쪼갤 수도 있고, 저희가 통제할 수 없는 데이터의 미세한 변동이 주어졌을 때에도 서비스는 업로드 실패라는 결과를 내보냅니다!

말씀해주신 이 부분이 치명적으로 작용하는거 같아요
이 이유로 결국 POST를 사용해야할거 같다고 생각하게 됐습니다.

얼마나 자주 저런 일이 일어날진 모르겠지만
우리가 통제할 수 없는 부분(content-length 계산 로직, 네트워크 환경 등)에서 장애 가능성이 생기는게,
서명 로직을 직접 구현해서 실수로 장애가 생기는 문제보다 더 큰 단점인거 같아요.

서명 로직은 잘 테스트해보고 확인하면 되는 문제니까요

또, AWS 공식 문서에서도 SignedHeader에 content-length를 넣는 방식을 알려주진 않더라고요.
아마 저런 문제가 있을 수 있으니 안내하지 않는거 아닐까요

결과적으로 PUT은 파일 크기 제한을 거는데 큰 단점이 따라오니, POST 방식 사용하는게 좋을거 같아요