[주요정보통신기반시설 웹 애플리케이션 취약점 분석·평가 21일 완성 코스] 8강 — [Day 8] 서버사이드 요청 위조 (SSRF)

⚡ 정다은 · 2026-09-28 14:00 · 조회 32

[Day 8] 서버사이드 요청 위조 (SSRF, Server-Side Request Forgery)

안녕하세요! Hackerstory 공부방의 IT/보안 튜터 정다은입니다. 👋

지난 시간까지 우리는 사용자의 브라우저를 이용해 악의적인 행위를 수행하게 만드는 클라이언트 사이드 공격(XSS, CSRF)에 대해 배웠습니다.

오늘 배울 8강에서는 관점을 바꾸어 웹 서버 자체를 공격자의 '대리인(Proxy)'으로 만드는 무서운 공격, 바로 **서버사이드 요청 위조(SSRF)**를 다룹니다. Cloud 환경이 보편화된 요즘, 클라우드 인프라 전체를 마비시킬 수 있어 최신 웹 보안 분야에서 매우 비중 있게 다뤄지는 항목입니다.

차근차근 원리부터 방어 대책까지 알아봅시다!

1. 서버사이드 요청 위조(SSRF)란?

개념 설명

**SSRF(Server-Side Request Forgery)**는 공격자가 웹 애플리케이션의 취약점을 이용해 웹 서버가 내부 네트워크, 루프백 주소(127.0.0.1) 또는 제3의 외부 시스템으로 악의적인 HTTP/HTTPS 요청을 보내도록 조작하는 공격입니다.

보통 방화벽이나 ACL(접근 제어 목록)에 의해 외부 인터넷에서는 내부 망(Internal Network)으로 직접 접근할 수 없습니다. 하지만 외부에 열려 있는 웹 서버가 내부 망과 통신할 수 있는 위치에 있다면 어떻게 될까요?

공격자는 이 웹 서버에게 "내부망에 있는 A 서버로 요청을 보내줘!"라고 시킵니다. 웹 서버는 공격자의 조종을 받아 신뢰된 내부망 시스템에 요청을 전달하고, 그 결과를 다시 공격자에게 반환합니다.

💡 CSRF vs SSRF 한눈에 비교하기

CSRF (Client-Side): 공격자가 사용자의 브라우저를 조종하여 웹 서버로 위조된 요청을 보냄.

SSRF (Server-Side): 공격자가 웹 서버를 조종하여 다른 내부 서버, DB, Cloud Metadata 등으로 위조된 요청을 보냄.

2. SSRF 동작 원리 및 주요 타깃 시나리오

웹 애플리케이션이 외부 URL의 자원을 가져오는 기능(예: 프로필 이미지 URL 불러오기, 웹훅 테스트, Open Graph 메타데이터 수집, PDF 변환 기능 등)을 제공할 때 SSRF 취약점이 자주 발생합니다.

취약한 코드 예시 (Node.js / Express 예시)

const express = require('express');
const axios = require('axios');
const app = express();

// 사용자가 입력한 URL의 이미지를 가져와 보여주는 기능
app.get('/fetch-image', async (req, res) => {
    const imageUrl = req.query.url; // 사용자의 입력을 검증 없이 수신
    
    try {
        // 서버가 직접 해당 URL로 HTTP 요청을 보냄!
        const response = await axios.get(imageUrl);
        res.send(response.data);
    } catch (error) {
        res.status(500).send('이미지 로딩 실패');
    }
});

위 코드는 url 파라미터로 넘겨받은 주소가 정당한 이미지 주소인지, 내부망 IP인지 전혀 검증하지 않습니다.

공격 시나리오 3가지

시나리오 1: 내부 루프백(127.0.0.1) 및 관리자 페이지 접근

일반적으로 웹 서버 내부에서만 접근 가능한 관리자 콘솔(http://127.0.0.1:8080/admin)이 존재할 수 있습니다. 외부 사용자는 접근할 수 없지만, SSRF를 이용하면 접근이 가능해집니다.

공격 요청: GET /fetch-image?url=http://127.0.0.1:8080/admin/deleteUser?id=admin
결과: 웹 서버 입장에서 요청 주체가 자기 자신(127.0.0.1)이므로, 방화벽을 우회하고 관리자 명령을 실행합니다.

시나리오 2: Cloud Instance Metadata 서비스(IMDS) 침해 (치명적!)

AWS, GCP, Azure 등 클라우드 환경에서 가상 머신(EC2 등)은 내부 전용 IP(169.254.169.254)를 통해 인스턴스 메타데이터를 제공합니다. 이 메타데이터에는 **IAM Role의 임시 인증 자격 증명(AccessKey, SecretKey)**이 포함되어 있습니다.

공격 요청 (AWS IMDSv1 예시): GET /fetch-image?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role
결과: 공격자는 탈취한 IAM Key를 이용하여 클라우드 인프라 전체에 대한 권한을 획득할 수 있습니다. (실제 대규모 클라우드 해킹 사고의 단골 원인입니다.)

시나리오 3: 내부 네트워크 포트 스캐닝 및 데이터 탈취

공격자는 사설 IP 대역(10.0.0.0/8, 192.168.0.0/16 등)으로 요청을 지속적으로 보내 내부망에 어떤 서버(Redis, DB, ElasticSearch 등)가 살아있는지, 포트가 열려있는지 탐색(Port Scanning)할 수 있습니다.

3. SSRF 진단 및 분석 방법

실무에서 SSRF 취약점을 진단할 때는 다음과 같은 지점을 점검합니다.

입력 파라미터 탐색: URL 형식의 값을 입력받는 모든 파라미터(url=, file=, path=, site=, src= 등)를 식별합니다.
루프백 주소 테스트: http://127.0.0.1, http://localhost를 전달하여 서버 내부 리소스가 응답하는지 확인합니다.
Out-of-Band (OAST) 테스트: 공격 대상 서버가 사용자가 제어하는 외부 서버(예: Burp Collaborator, Interactionsh)로 DNS/HTTP 요청을 보내는지 확인합니다.
블랙리스트 우회 기법 검증:
- IP 변형: http://2130706433 (127.0.0.1의 10진수 표현)
- Hex 표현: http://0x7f.0x0.0x0.0x1
- DNS Rebinding 기법 또는 URL Shortener 활용

4. SSRF 보안 대책 (실무 대응 방안)

SSRF를 막기 위해서는 단순 블랙리스트(127.0.0.1, localhost 차단) 방식만으로는 부족합니다. 다층 방어(Defense in Depth) 전략이 필수적입니다.

1) 엄격한 URL 화이트리스트(Whitelist) 검증

허용할 도메인이나 IP의 목록을 미리 정의하고, 오직 화이트리스트에 등록된 목적지로만 요청을 송신하도록 제한합니다.

import re
from urllib.parse import urlparse

ALLOWED_DOMAINS = ["api.example.com", "cdn.example.com"]

def validate_url(input_url):
    parsed = urlparse(input_url)
    
    # 1. 프로토콜 검증 (http, https만 허용)
    if parsed.scheme not in ["http", "https"]:
        raise ValueError("허용되지 않는 프로토콜입니다.")
        
    # 2. 도메인 화이트리스트 검증
    if parsed.hostname not in ALLOWED_DOMAINS:
        raise ValueError("허용되지 않은 대상 도메인입니다.")
        
    return True

2) 위험한 프로토콜 및 스키마 비활성화

HTTP/HTTPS 이외에, 서버의 지역 파일을 읽을 수 있는 file://, 내부 서비스와 상호작용할 수 있는 gopher://, dict://, ftp:// 등의 프로토콜 사용을 서버 라이브러리 설정 수준에서 완전히 비활성화합니다.

3) 네트워크 차원 접근 제어 (Egress Filtering)

내부 망 접근 차단: 웹 서버가 위치한 DMZ 구간에서 내부 사설망(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8)으로 나가는 outbound 요청을 방화벽으로 차단합니다.
Cloud Metadata 접근 제한:
- AWS 환경이라면 세션 토큰 검증이 필수인 IMDSv2 사용을 강제합니다.
- 서버 내에서 메타데이터 IP(169.254.169.254)로 가는 트래픽을 iptables 등으로 Drop 처리합니다.

5. 오늘 강의 요약

SSRF 개념: 웹 서버를 이용해 내부 시스템, 루프백 주소, 클라우드 메타데이터 등으로 공격자가 위조된 요청을 송신하게 만드는 취약점.
주요 위협: 방화벽 우회, 내부 망 포트 스캐닝, 클라우드 IAM 자격 증명(AccessKey) 탈취, 내부 관리자 콘솔 제어.
핵심 방어책:
- 입력 검증: 도메인 및 IP 기반의 화이트리스트 방식 적용.
- 프로토콜 제한: HTTP/HTTPS만 허용 (file://, gopher:// 등 차단).
- 인프라 보안: 사설 IP 대역 및 Cloud Metadata(169.254.169.254)로 향하는 Outbound 트래픽 차단 (IMDSv2 적용).

공부하시느라 수고 많으셨습니다! SSRF는 원리를 이해하고 나면 웹 애플리케이션과 네트워크/클라우드 보안이 어떻게 연결되어 있는지 시야를 넓히기에 아주 좋은 주제입니다.

다음 시간에는 인증/인가 보안의 시작이자 가장 기본이 되는 [Day 9] 약한 비밀번호 정책에 대해 배워보겠습니다.

질문이 있으시다면 언제든 댓글로 남겨주세요. 다음 챕터에서 만나요! 🫡

♥ 추천 0