웹 보안 기초: SSRF, CSRF, CORS 완벽 이해하기

현대 웹 환경에서 보안은 단순한 기능이 아니라 필수적인 토대입니다. 애플리케이션이 점점 더 서로 연결됨에 따라, 서로 다른 출처(Origin)와 서버 간에 요청이 어떻게 처리되는지 이해하는 것은 모든 개발자에게 매우 중요합니다.

오늘은 모든 웹 개발자가 숙지해야 할 세 가지 핵심 개념인 SSRF, CSRF, 그리고 CORS에 대해 자세히 알아보겠습니다. 이름은 생소할 수 있지만, 이는 웹 애플리케이션 보안의 최전선을 담당하는 개념들입니다.

1. SSRF (Server-Side Request Forgery)

SSRF는 공격자가 서버 측 애플리케이션을 조작하여 공격자가 선택한 임의의 도메인으로 HTTP 요청을 보내도록 만드는 취약점입니다.

작동 원리

사용자로부터 URL을 입력받아(예: 프로필 사진 가져오기 또는 링크 미리보기) 서버에서 해당 URL로 요청을 보내는 웹 애플리케이션을 상상해 보세요. 애플리케이션이 이 URL을 제대로 검증하지 않으면, 공격자는 내부 IP 주소나 루프백 주소(127.0.0.1)를 입력할 수 있습니다.

서버는 프록시 역할을 수행하며 다음과 같이 외부로 노출되지 않은 내부 서비스의 민감한 데이터를 가져올 수 있습니다:

• 클라우드 메타데이터: AWS/GCP의 169.254.169.254에 접속하여 IAM 자격 증명 탈취.
• 내부 관리자 패널: Jenkins 또는 Kubernetes 대시보드와 같은 내부 도구 접근.
• 포트 스캐닝: 내부 네트워크에서 실행 중인 다른 서비스 탐색.

방어 방법

• 허용 목록(Allowlisting): 신뢰할 수 있는 도메인 목록으로만 요청을 제한합니다.
• 입력값 검증: URL이 허용된 프로토콜(예: https:// 전용)을 사용하는지 확인하고 내부 IP 대역을 가리키지 않도록 합니다.
• 네트워크 격리: 웹 서버가 내부 리소스에 접근할 수 있는 권한을 최소화합니다.

2. CSRF (Cross-Site Request Forgery)

CSRF는 사용자의 의지와 상관없이 사용자가 현재 로그인되어 있는 다른 웹사이트에 대해 원치 않는 동작을 수행하도록 속이는 공격입니다.

작동 원리

이 공격은 브라우저가 특정 도메인으로 요청을 보낼 때 세션 쿠키와 같은 인증 정보를 자동으로 포함한다는 점을 악용합니다.

1. 사용자가 bank.com에 로그인합니다.
2. 사용자가 다른 탭에서 악성 사이트 evil.com을 방문합니다.
3. evil.com에는 bank.com/transfer?amount=1000&to=attacker로 POST 요청을 보내는 숨겨진 폼이 있습니다.
4. 브라우저는 사용자의 bank.com 세션 쿠키와 함께 요청을 보냅니다.
5. bank.com은 유효한 세션으로 인식하고 송금을 처리합니다.

방어 방법

• Anti-CSRF 토큰: 상태를 변경하는 모든 요청에 고유하고 예측 불가능한 비밀 토큰을 포함합니다. 서버는 처리 전 이 토큰을 검증합니다.
• SameSite 쿠키: 쿠키의 SameSite 속성을 Strict 또는 Lax로 설정하여 타사 사이트의 요청에서 쿠키가 전송되지 않도록 합니다.
• 커스텀 헤더: AJAX 요청 시 표준 HTML 폼으로는 설정할 수 없는 커스텀 헤더(예: X-Requested-With)를 요구합니다.

3. CORS (Cross-Origin Resource Sharing)

SSRF나 CSRF와 달리 CORS는 그 자체로 취약점이 아니라 보안 메커니즘입니다. 서버가 브라우저에게 *“특정 외부 출처가 내 리소스에 접근하는 것을 허용한다”*고 알려주는 방법입니다.

존재 이유

기본적으로 브라우저는 **동일 출처 정책(SOP)**을 강제하여 한 사이트의 스크립트가 다른 사이트의 데이터를 읽지 못하도록 차단합니다. 이는 evil.com이 gmail.com의 이메일을 읽는 것을 방지합니다.

CORS는 서버가 이 정책을 안전하게 완화할 수 있게 해줍니다. 웹 앱이 교차 출처 요청을 보내면 브라우저는 Origin 헤더를 보냅니다. 서버는 Access-Control-Allow-Origin 헤더로 응답합니다.

흔한 설정 오류

• 와일드카드 출처 (*): 모든 출처를 허용합니다. 공개 API에는 괜찮을 수 있지만, Access-Control-Allow-Credentials: true와 함께 사용하면 매우 위험합니다.
• 출처 반영: 검증 없이 Origin 헤더를 그대로 허용된 출처로 설정합니다. 이는 사실상 SOP를 완전히 무력화합니다.

베스트 프랙티스

• 구체적으로 지정: 접근이 필요한 특정 도메인만 허용합니다.
• 가능한 경우 자격 증명 피하기: API에 쿠키나 인증 헤더가 필요하지 않다면 허용하지 마세요.
• 보안 미들웨어 사용: 헤더를 수동으로 관리하는 대신 검증된 라이브러리를 사용하여 CORS 설정을 처리하세요.

요약 비교

웹 보안의 이 세 가지 기둥을 이해하는 것은 견고한 현대 애플리케이션을 구축하는 데 필수적입니다. 심층 방어 전략을 구현함으로써 서버의 내부 인프라와 사용자의 개인 데이터 모두를 보호할 수 있습니다.

안전하게 개발하시길 바랍니다!