Server-Side Request Forgery(SSRF) 공격은 웹 애플리케이션의 결함을 악용하여 내부 리소스에 액세스하는 공격입니다. 앱과 API를 보호하는 방법을 알아보십시오.
SSRF는 공격자가 웹 애플리케이션 또는 API를 조작하여 내부 리소스에 요청할 때 발생하는 보안 결함의 한 유형으로, 무단 액세스, 데이터 노출, 시스템 손상 및 원격 코드 실행으로 이어질 수 있습니다. 공격자는 입력 유효성 검사를 우회하여 방화벽 또는 VPN(가상 사설망) 솔루션으로 보호되는 경우에도 애플리케이션이 악성 웹 대상에 액세스하도록 만듭니다.
SSRF 공격에서 공격자는 일반적으로 서버 측 HTTP 요청의 대상 URL을 지정하는 데 사용되는 입력을 조작합니다. 이 공격은 애플리케이션이 원격 리소스에서 데이터를 가져오기 전에 사용자가 입력한 URL의 유효성을 검사하거나 살균하지 않을 때 발생할 수 있습니다. 공격자는 표적이 된 서버가 임의의 대상으로 요청을 수행하게 하여 다양한 보안 위험을 초래할 수 있습니다.
이러한 공격은 표적이 된 리소스가 클라우드 메타데이터 서비스 또는 백엔드 API와 같은 다른 시스템과 신뢰 관계를 맺고 있는 경우에도 발생할 수 있으며, 공격자는 이러한 신뢰할 수 있는 서비스에 요청하여 민감한 정보를 추출하거나 무단 작업을 수행할 수 있습니다.
최신 웹 애플리케이션이 최종 사용자에게 편리한 기능을 제공하면서 URL을 가져오는 것은 일반적인 시나리오가 되었습니다. 그 결과 SSRF의 발생이 증가하고 있습니다. 또한 API와 클라우드 서비스가 더욱 보편화되고 컴퓨팅 아키텍처가 더욱 탈중앙화되고 복잡해지면서 SSRF의 심각성도 높아지고 있습니다.
SSRF는 가장 중요한 웹 애플리케이션 보안 위험 목록으로 널리 알려진 OWASP Top 10 애플리케이션 보안 위험 중 하나입니다. 또한 SSRF는 앱과 API 모두에 공통적으로 적용되는 OWASP Top 10 보안 위험 중 하나이며 보안 솔루션 구현 시 특별히 고려해야 할 사항이기도 합니다.
SSRF 공격의 원리는 다음과 같습니다.
실생활에서 SSRF 공격이 어떻게 발생하는지 알아보십시오.
사용자가 처리할 이미지의 URL을 제공할 수 있는 기능이 있는 보호되지 않은 웹 애플리케이션에서 사용자가 처리할 이미지를 업로드할 수 있다고 가정해 보겠습니다. 그러나 공격자는 정상적인 이미지 URL을 제공하는 대신 내부 파일 또는 백엔드 데이터베이스 등과 같은 애플리케이션 서버의 내부 리소스를 가리키는 악성 URL이 포함된 신중하게 조작된 입력을 제출합니다. 애플리케이션 서버는 악성 URL을 맹목적으로 처리하고 공격자의 입력에 따라 URL로 지정된 내부 리소스에 요청하여 민감한 데이터를 가져오거나 데이터베이스에 조회하고 공격자에게 데이터를 반환합니다.
또한 서버가 손상되면 공격자는 외부 시스템에 요청하거나 취약점을 조사하거나 해당 서버에 액세스 권한이 있는 서비스와 상호 작용할 수 있습니다. SSRF 공격의 영향은 시스템의 아키텍처와 손상된 서버의 권한에 따라 달라질 수 있습니다. 공격은 무단 데이터 액세스, 서비스 중단 또는 내부 시스템 손상으로 이어질 수 있습니다.
SSRF 공격은 공격자가 서버와 상호 작용하고 정보를 추출하는 방식에 따라 여러 유형으로 분류할 수 있습니다.
표준 SSRF 공격에서 공격자는 사용자 입력의 일부로 악성 URL을 주입하여 서버가 지정된 리소스에 대한 요청을 하도록 트리거합니다. 공격자는 서버의 응답을 직접 관찰하고 데이터를 검색하거나 액세스 가능한 서비스를 식별하는 방법 등과 같은 내부 네트워크에 대한 정보를 수집할 수 있습니다.
블라인드 SSRF 공격에서는 공격자가 서버로부터 직접 응답을 받지 않습니다. 대신 공격자는 애플리케이션의 동작 변화를 관찰하여 간접적으로 SSRF 공격의 성공 또는 실패를 확인합니다.
공격자는 조작된 입력을 제출하여 서버가 외부 또는 내부 리소스에 대한 요청을 하도록 합니다. 공격자는 오류 메시지, 응답 시간 또는 기타 부작용에서의 차이점 등과 같이 애플리케이션의 활동에서 관찰 가능한 변화를 찾습니다. 이 정보는 공격자가 직접 응답을 확인하지 않더라도 SSRF가 성공했는지 여부를 추론하는 데 도움이 됩니다.
시간 기반 블라인드 SSRF 공격은 서버의 응답 지연을 악용하여 응답을 직접 확인하지 않고도 SSRF의 성공 또는 실패를 유추하는 공격입니다.
다른 SSRF 공격과 마찬가지로 공격자는 악성 입력을 제출하여 서버가 외부 또는 내부 리소스에 대한 요청을 하도록 합니다. 공격자는 애플리케이션이 응답하는 데 걸리는 시간을 관찰합니다. 응답 시간이 지연되면 SSRF가 성공했음을 의미할 수 있습니다. 공격자는 페이로드를 반복적으로 조정하고 시간 지연을 모니터링하여 내부 네트워크 또는 리소스에 대한 정보를 추출합니다.
SSRF 공격으로부터 보호하려면 다음과 같은 예방적 사이버 보안 조치를 조합하여 구현하십시오.
이러한 예방 조치가 SSRF 공격을 방지하는 데 어떻게 도움이 될까요? 가상의 시나리오를 살펴보겠습니다.
온라인 콘텐츠 관리 시스템에서는 사용자가 URL을 입력하여 외부 이미지를 자신의 게시물에 삽입할 수 있습니다. 이 시스템은 적절한 입력 유효성 검사 없이 사용자가 제공한 URL을 처리합니다. 공격자는 입력 유효성 검사가 없다는 것을 알고 내부 API 엔드포인트 또는 데이터베이스 서버와 같은 내부 리소스를 가리키는 악성 URL을 제공하여 시스템을 악용하려고 시도합니다. 그러나 애플리케이션의 보안팀은 시스템의 입력 유효성 검사를 강화하여 허용되는 URL에 대해 엄격한 규칙을 적용합니다. 시스템은 사용자가 제공한 URL이 예상 패턴에 부합하는지 검증을 시작하고 팀은 외부 리소스에 대해 허용된 도메인의 화이트리스트를 구현합니다.
공격자는 SSRF 결함을 악용하기 위해 조작된 URL이 포함된 게시물을 제출하지만 이제 입력 유효성 검사에서 악성 URL을 탐지합니다. 입력 유효성 검사는 처리 중에 악성 URL을 거부하여 애플리케이션이 공격자가 지정한 내부 리소스에 대한 요청을 하지 못하도록 합니다. SSRF 공격이 향상된 입력 유효성 검사를 통해 차단됩니다. 시스템은 내부 리소스에 대한 무단 요청을 허용하지 않으며 내부 시스템의 무결성과 보안이 유지됩니다.
입력 유효성 검사를 구현함으로써 애플리케이션은 악성 입력을 거부하거나 살균하여 무단 요청을 방지하고 SSRF 공격의 위험을 완화할 수 있습니다.
SSRF 공격은 공격자가 방화벽 및 액세스 제어 등과 같은 기존 네트워크 보안 조치를 우회하여 일반적으로 조직의 내부 네트워크 내에서 보호되고 인터넷에서 직접 액세스할 수 없는 민감한 정보와 리소스에 액세스할 수 있기 때문에 위험합니다. SSRF 공격은 데이터와 시스템의 기밀성, 무결성 및 가용성에 상당한 위험을 초래하므로 조직에서는 WAF, 적절한 입력 유효성 검사, 액세스 제어 및 네트워크 세분화를 포함한 강력한 보안 조치와 모범 사례를 구현하여 SSRF 취약점의 위협을 완화하고 잠재적인 악용으로부터 보호해야 합니다.
F5 WAF 솔루션은 SSRF를 포함하여 OWASP Top 10에 기인한 광범위한 위험을 차단하고 완화합니다. F5 WAF 솔루션은 새로운 위협에 대응하기 위해 F5 Labs의 Threat Intelligence 및 머신 러닝(ML)을 통해 자동화된 보안을 포함한 서명 및 행동 보호 기능을 결합합니다. 클라우드, 온프레미스 및 엣지 환경에서 애플리케이션을 일관되게 보호하는 부담과 복잡성을 완화하며 다양한 배포 옵션으로 제공됩니다. BIG-IP Advanced WAF는 SSRF 공격으로부터 애플리케이션을 안전하게 지키고 소프트웨어 취약점에 중요한 임시방편을 제공하는 강력한 솔루션이며, F5 Distributed Cloud WAF는 사용하기 쉬운 서비스형 보안 플랫폼을 통해 운영을 획기적으로 간소화하여 어디에서나 앱을 보호할 수 있습니다.
F5 Web Application and API Protection(WAAP) 솔루션은 WAF, API Security, L3-L7 DDoS 완화, 악의적 자동화 및 자동화된 위협에 대한 Bot Defense를 포함한 포괄적인 보호 기능을 통해 최신 앱 공격 표면 전체를 방어합니다. 분산 플랫폼을 사용하면 호스팅 위치에 관계없이 쉽게 앱과 API 전체에 일관된 정책을 배포하고 보안을 확장하며 API 수명 주기 및 광범위한 생태계에 보안 기능을 통합할 수 있습니다.
구성 가이드
NGINX App Protect WAF ›