API7:2023 Server Side Request Forgery
위협 요소/공격 경로 | 보안 취약점 | 영향 |
API 명세: 악용 용이함 | 확산성: 탐지 용이함 | 기술적 심각도: 특정 비지니스 |
악용하려면 공격자가 클라이언트가 제공한 URI에 액세스하는 API end-points를 찾아야 합니다. 일반적으로 기본 SSRF(공격자에게 응답이 반환될 때)는 공격 성공 여부에 대한 피드백이 없는 Blind SSRF보다 공격이 용이합니다. | 애플리케이션 개발의 최근 개념은 개발자가 클라이언트가 제공하는 URI에 액세스하도록 권장하는 것입니다. 그러한 URI들의 부족 또는 부적절한 유효성 검증은 흔한 문제입니다. 문제를 검출하기 위해 정기적인 API 요청과 응답 분석이 필요할 것입니다. 응답이 반환되지 않을 때 (Blind SSRF) 취약성을 검출하는 것은 더 많은 노력과 창의성을 요구합니다. | 공격이 성공하면 내부 서비스 스캐닝(예: 포트 스캔), 정보 노출, 방화벽 우회 또는 기타 보안 위협이 발생할 수 있습니다. 경우에 따라 DoS 또는 악의적인 활동을 숨기기 위해 프록시 서버로 사용될 수 있습니다. |
취약한 API
서버측 요청 위조(SSRF) 결함은 API가 사용자 제공 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생합니다. 이를 통해 공격자는 방화벽이나 VPN으로 보호되는 경우에도 응용 프로그램이 조작된 요청을 예상치 못한 대상으로 전송하도록 강제할 수 있습니다.
애플리케이션 개발의 최신 개념은 SSRF를 더욱 일반적이고 위험하게 만듭니다.
•
More common - 다음 개념은 개발자가 사용자 입력을 기반으로 외부 리소스에 액세스하도록 권장합니다. (Webhooks, URL에서 파일 가져오기, 사용자 정의 SSO 및 URL 미리보기)
•
More dangerous - 클라우드 공급자, Kubernetes, Docker와 같은 최신 기술은 예측 가능하고 잘 알려진 경로에서 HTTP를 통해 관리 및 제어 채널을 노출합니다. 이러한 채널은 SSRF 공격의 쉬운 대상입니다.
또한 최신 애플리케이션의 연결 특성으로 인해 애플리케이션에서 아웃바운드 트래픽을 제한하는 것이 더 어렵습니다.
SSRF 위험이 항상 완전히 제거될 수는 없습니다. 보호 메커니즘을 선택할 때 비즈니스 위험과 요구 사항을 고려하는 것이 중요합니다.
공격 시나리오
Scenario #1
소셜 네트워크를 통해 사용자는 프로필 사진을 업로드할 수 있습니다. 사용자는 자신의 컴퓨터에서 이미지 파일을 업로드하거나 이미지의 URL을 제공하도록 선택할 수 있습니다. 두 번째를 선택하면 다음 API 호출이 트리거됩니다:
POST /api/profile/upload_picture
{
"picture_url": "http://example.com/profile_pic.jpg"
}
JavaScript
복사
공격자는 API end-points를 사용하여 악의적인 URL을 전송하고 내부 네트워크 내에서 포트 검색을 시작할 수 있습니다.
{
"picture_url": "localhost:8080"
}
JavaScript
복사
공격자는 응답 시간을 기반으로 포트가 열려 있는지 여부를 파악할 수 있습니다.
Scenario #2
보안장비는 네트워크의 이상 징후를 감지하면 이벤트를 생성합니다. 일부 팀은 SIEM(보안 정보 및 이벤트 관리)과 같은 보다 광범위하고 일반적인 모니터링 시스템에서 이벤트를 검토하는 것을 선호합니다. 이를 위해 장비는 webhooks를 사용하여 다른 시스템과의 통합을 제공합니다.
새로운 webhook생성의 일부로 GraphQL 변형이 SIEM API의 URL과 함께 전송됩니다.
POST /graphql
[
{
"variables": {},
"query": "mutation {
createNotificationChannel(input: {
channelName: \"ch_piney\",
notificationChannelConfig: {
customWebhookChannelConfigs: [
{
url: \"http://www.siem-system.com/create_new_event\",
send_test_req: true
}
]
}
}){
channelId
}
}"
}
]
JavaScript
복사
생성 과정에서 API 백엔드는 제공된 webhook url에 테스트 요청을 전송하고 응답을 사용자에게 제공합니다.
공격자는 이 흐름을 활용하여 API 요청을 내부 클라우드 메타데이터 서비스에서 자격증명을 노출하는 민감한 리소스로 만들 수 있습니다:
POST /graphql
[
{
"variables": {},
"query": "mutation {
createNotificationChannel(input: {
channelName: \"ch_piney\",
notificationChannelConfig: {
customWebhookChannelConfigs: [
{
url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\",
send_test_req: true
}
]
}
}) {
channelId
}
}
}
]
JavaScript
복사
응용 프로그램이 테스트 요청의 응답을 표시하므로 공격자는 클라우드 환경의 자격 증명을 볼 수 있습니다.
예방 방법
•
네트워크에서 리소스를 가져오는 메커니즘을 분리합니다. 일반적으로 이러한 기능은 내부 리소스가 아닌 원격 리소스를 검색하는 것을 목표로 합니다.
•
가능하면 다음 허용 목록을 사용하세요:
◦
원격 출처 사용자는 (예: Google Drive, Gravatar 등)에서 리소스를 다운로드하도록 설정
◦
URL 구성표 및 포트
◦
특정 기능에 대해 허용되는 media types
◦
HTTP 리디렉션을 비활성화
◦
URL 구문 분석 불일치로 인해 발생하는 문제를 방지하려면 잘 테스트되고 유지 관리되는 URL 구문 분석기를 사용
◦
클라이언트가 제공한 모든 입력 데이터를 검증
◦
Row response는 클라이언트에 전송 금지