ヒーロー背景（区切りなし）
ガイドライン

サーバー側のリクエスト偽造

서버 측 요청 위조 취약성은 사용자가 애플리케이션이 공격자가 결정한 도메인에 HTTP 요청을 하도록 할 수 있을 때 발생합니다.애플리케이션이 사설/내부 네트워크에 액세스할 수 있는 경우 공격자가 애플리케이션으로 하여금 내부 서버에 요청을 하도록 할 수도 있습니다.

실제로 어떻게 보이는지 더 잘 이해할 수 있도록 몇 가지 예제를 통해 자세히 살펴보겠습니다.

사용자로부터 URL을 가져와 사용자가 제공한 URL의 그림을 생성하는 API (예: 페이지 미리 보기 또는 내보내기) 를 예로 들어 보겠습니다.

ts
url = 요청.params.url로 설정;

응답 = http.get (url) 이라고 가정해 봅시다.
렌더 = 리스폰스.렌더 () 라고 하자;

반환 렌더링. 내보내기 ();

URL 매개변수는 사용자가 제어하므로 공격자는 원하는 모든 URL에 간단히 액세스할 수 있습니다.경우에 따라 URL에 액세스하는 데 사용되는 라이브러리에 따라 'file: //' 체계를 사용하는 로컬 파일일 수도 있습니다.

AWS에서 호스팅할 때 SSRF 취약성을 악용하는 일반적인 방법은 이를 사용하여 AWS API의 자격 증명을 포함할 수 있는 AWS 메타데이터 API에 액세스하는 것입니다.이로 인해 계정 내의 다른 AWS 리소스에 추가로 액세스할 수 있게 될 수 있는데, 이는 상상할 수 있듯이 이상적이지 않습니다.

완화

SSRF 취약성을 완화하는 것은 때때로 매우 까다로울 수 있으며 해당 코드가 달성하려는 목표에 크게 좌우됩니다.요구 사항에 따라 다양한 완화 조치를 취할 수 있습니다.

사용자가 지정한 URL은 사용하지 마세요.

경우에 따라 임의의 URL을 제공하는 사용자에게 의존하지 않는 방식으로 기능을 구현할 수 있습니다.이것이 가능하다면 SSRF의 위험을 완화하는 가장 효과적인 방법입니다.

기능 최소화

PDF 내보내기 기능을 구현하는 경우 헤드리스 브라우저를 사용하여 페이지의 스크린샷을 찍는 경향이 있을 수 있습니다.브라우저의 복잡성과 브라우저가 노출하는 기능 및 공격 표면의 수가 엄청나다는 점을 고려할 때 항상 권장되는 것은 아닙니다.

당면한 작업에 적합한 도구를 사용하는 것이 중요합니다.경우에 따라 간단한 HTTP 클라이언트로도 충분할 수 있습니다.기능을 최소화하기 위해 할 수 있는 일은 항상 있기 때문에 공격 영역/벡터를 최소화할 수 있습니다.예를 들어, HTTP 클라이언트의 경우:

  • 다음 리디렉션 비활성화
  • HTTPS를 제외한 모든 스킴 비활성화

몇 가지 함정이 있습니다.

리다이렉트 및 아이프레임

프라이빗 리소스 (IP 주소 또는 내부 호스트 이름) 에서 SSRF를 방지하는 일반적인 방법은 사용자가 제공한 URL을 구문 분석하고 '거부 목록'을 사용하여 민감한 리소스에 대한 액세스를 방지하는 것입니다.

이 방법은 클라이언트가 HTTP 리디렉션, HTML/JavaScript 리디렉션을 따르거나 iframe과 같은 복잡한 요소를 렌더링할 수 있는 시나리오에서는 우회될 수 있으므로 대부분의 경우 효과적이지 않다는 점에 유의할 필요가 있습니다.

공격자는 HTTP 301/302, HTML 메타 리디렉션, 로드 시 Javascript로 현재 URL을 설정하거나 내부 리소스를 보여주는 iframe을 임베드하여 민감한 리소스로 리디렉션하는 페이지를 호스팅하는 취약한 애플리케이션에 URL을 제공할 수 있습니다.이렇게 하면 원래 URL의 유효성을 검사하려는 모든 시도를 효과적으로 우회할 수 있습니다.

DNS 리바인딩
또 다른 “유형”의 리디렉션도 DNS를 통해 수행할 수 있습니다.SSRF 공격을 방지하는 일반적인 방법 중 하나는 다음을 수행하는 것입니다.

  1. 제공된 URL을 분석합니다.
  2. 호스트 이름을 가져와 DNS 조회 수행
  3. 내부/사설 IP로 확인되는 경우 URL을 거부하고, 공용 IP인 경우 URL을 수락합니다.

이 방법은 “DNS 리바인딩”에 취약하기 때문에 그다지 효과적이지 않습니다.DNS 리바인딩은 원격 호스트가 TCP 연결을 닫을 때 대부분의 네트워크 스택 (예: Linux 및 Windows 스택) 의 표준 동작 때문에 작동합니다.
원격 호스트가 강제로 연결을 종료하면 IP 주소를 다시 확인하기 위해 다른 DNS 쿼리를 수행한 후 다시 연결을 시도합니다.

이를 통해 공격자는 다음을 수행할 수 있습니다.

  1. 공개 IP 주소로 'rebinding.attacker.com'에 대한 DNS 항목을 생성하고, 공개 HTTP 포트와 함께 TTL (TTL) 이 매우 짧습니다 (TTL).
  2. URL (예: https://rebinding.attacker.com/) 을 취약한 애플리케이션에 제출하십시오.확인된 IP가 비공개가 아닌지 (비공개 IP가 아닌지) 확인한 다음 안전하다는 믿음 하에 요청된 작업을 진행합니다.
  3. HTTP 연결이 설정되면 “rebinding.attacker.com”의 DNS 항목이 내부 IP 주소로 변경됩니다.
  4. HTTP 연결이 강제로 종료되었습니다
  5. 이제 애플리케이션은 내부 IP 주소를 가리키는 “rebinding.attacker.com”의 IP 주소를 다시 확인합니다.
  6. IP 확인 보호가 이미 수행되었고 DNS 항목의 재확인 및 재연결이 모두 커널에서 이루어지기 때문에 응용 프로그램은 IP가 변경되었다는 사실을 인식하지 못합니다.

이렇게 하면 프라이빗 IP 주소로 확인되는 URL 제공에 대한 보호 기능을 효과적으로 우회할 수 있습니다.

IPv4 대 IPv6

'거부 목록'을 우회하는 또 다른 일반적인 방법은 IPv6을 사용하는 것입니다.모든 IPv4 주소는 IPv6 주소로 표현될 수 있으므로 액세스하려는 IPv4 주소에도 매핑되는 IPv6 주소를 사용하여 거부 목록을 우회할 수 있는 경우가 많습니다.