it-gundan.com

사용자 제공 URL을 가져올 때의 보안 위험

웹 응용 프로그램 (중요한 경우 온라인 제품 데이터베이스)에 다음 기능을 추가하려고합니다.

  • 사용자는 이미지를 업로드하는 대신 이미지의 자체 호스팅 URL을 제공 할 수 있습니다. 이미지 대신 URL을 저장합니다.

여태까지는 그런대로 잘됐다. 그러나 때로는 웹 응용 프로그램에서 (외부 사용자 제공) URL에서 이미지를 가져 와서 페치 해야합니다 (예 : PDF 제품 데이터 시트)에 이미지를 포함 시키십시오.

이것은 웹 서버가 사용자 제공 URL에 HTTP 요청을 전송한다는 것을 의미하기 때문에 저와 관련이 있습니다. 예를 들어 http://192.168.1.1/...를 URL로 사용하고 일반적인 라우터 웹 인터페이스 악용 시도). Cross-Site Request Forgery 와 비슷해 보이지만 웹 서버는 사용자가 웹 요청을 제출하도록 속이는 것이 아니라 웹 서버를 속이는 사용자입니다.

분명히, 나는이 문제에 직면 한 첫 번째 사람이 아닙니다. 따라서 내 질문 :

  • 이 공격 경로는 이름이 있습니까? (추가 연구를 할 수 있도록 ...)
  • 알고 있어야하는 사용자 제공 URL 가져 오기와 관련된 다른 위험이 있습니까?
  • 이러한 위험을 완화하기 위해 잘 확립 된 모범 사례 기술이 있습니까?
62
Heinzi

이 특정 취약점에는 실제로 이름이 있습니다. 이를 SSRF (Server-Side Request Forgery)라고합니다. SSRF는 사용자가 서버 측 응용 프로그램이 내부 네트워크의 다른 웹 페이지, 루프백에서 액세스 할 때만 사용할 수있는 기타 서비스 (다른 웹 서비스 및 API, 때로는 데이터베이스)와 같이 응용 프로그램 개발자가 의도하지 않은 리소스를 검색하도록 할 수있는 시점입니다. 서버) 및 서버의 파일 (file:///etc/passwd). 악용 될 수있는 방법에 대한 예는 SSRF BiblePayloadsAllTheThings 를 참조하십시오. 이미지 태그이므로 대부분 표시되지 않지만 여전히 해결해야 할 문제입니다.

어떻게해야합니까? OWASP SSRF 치트 시트 를 참조 할 수 있습니다. 요청을 POST로 변경하거나 고유 한 토큰을 추가하는 등) 모든 완화를 수행 할 수는 없지만 상황은 두 번째 경우와 일치합니다.

  1. 화이트리스트 허용 프로토콜 : HTTP 및 HTTPS를 허용하고 다른 모든 것을 허용하지 마십시오 (예 : ^https?://).
  2. 제공된 호스트 이름이 공개인지 확인하십시오 : 많은 언어가 IP 주소 라이브러리와 함께 제공됩니다. 대상 호스트 이름이 비공개 및 예약되지 않은 IPv4 또는 IPv6 주소 *로 확인되는지 확인하십시오.
  3. 내 자신의 추가, 사용자 지정 방화벽 규칙 : 웹 응용 프로그램을 실행하는 시스템 사용자는 모든 내부 네트워크 요청 및 로컬 서비스를 차단하는 제한적인 방화벽 규칙에 바인딩 될 수 있습니다. iptables/nftables를 사용하여 Linux에서 가능합니다. 또는 응용 프로그램의이 부분을 컨테이너화/분리하여 잠그십시오.

검색시 파일의 MIME 유형을 검증하여 이미지인지 확인할 수도 있습니다. 또한 이미지를 가져올 때 리디렉션을 허용하지 않거나 이미지를 가져올 때 동일한 유효성 검사를 모두 수행하십시오. 악의적 인 웹 서버는 내부 리소스로 리디렉션하는 3xx 응답 만 보낼 수 있습니다.

또한 사용자가 입력 한 데이터에서 PDF를 생성한다고 언급했습니다. 이미지 URL을 제외하고 PDF 생성기는 역사적으로 XXE (XML eXternal Entity injection) 및 SSRF 취약점의 번식지였습니다. 따라서 사용자 지정 URL을 수정하더라도 PDF 생성 라이브러리는 이러한 문제를 피하거나 직접 검증을 수행합니다. DEFCON 대화는 문제를 간략하게 설명합니다 ( PDF 다운로드 ).

* 주석에서 언급했듯이 DNS 응답에는 여러 결과가 포함될 수 있으며 요청간에 응답이 변경되어 TOCTOU (Time-of-Check-Time-Use-Use) 문제가 발생할 수 있습니다. 완화하고 한 번 해결하고 유효성을 검사 한 후 원래 검증 된 IP 주소를 사용하여 요청을하고 올바른 가상 호스트에 도달 할 수 있도록 호스트 헤더를 첨부하십시오.

69
multithr3at3d

사용자는 이미지를 업로드하는 대신 이미지의 (자체 호스팅 된) URL을 제공 할 수 있습니다. 이미지 대신 URL을 저장합니다.

이러한 JPEG 종류 ?

나쁜 생각입니다. 우선, 이미지를 사용할 때마다 이미지의 유효성을 확인해야합니다. 시간이 걸립니다. 나는 다른 사용자가 데이터베이스를 사용한다고 가정하고 데이터베이스 사용자가 어떤 종류의 악성 JPEG를 제공하는지 제어 할 수는 없다. 당신은 당신이 악성 이미지를 얻는 것에 대해 걱정하고 있지만 데이터베이스를 사용하는 다른 사람들이 그러한 악성 이미지를 얻도록 기꺼이 허용합니다.

그래서 지금까지는 좋지 않습니다.

신뢰할 수없는 출처의 입력을 처리하는 것처럼 이미지를 직접 처리하십시오. 즉, 이미지가 올바른지 확인하십시오. 표준 형식으로 변환 할 수도 있습니다. 확실하게 다시 인코딩 할 수 있습니다.

28
Ljm Dullaart