CSRF (Cross-Site Request Forgery)
- 정의:
사용자가 인증된 세션 상태에서 공격자가 의도한 요청을 사용자 몰래 실행하게 만드는 웹 공격 기법. - 간단 설명:
사용자가 이미 로그인해 둔 서비스에 대해, 공격자가 만든 외부 페이지/요청을 통해 브라우저가 자동으로 인증 정보를 포함한 요청을 보내게 하여 악의적 동작을 수행함.
공격 시나리오 (대표 예)
- 1) 사용자가
bank.com에 로그인하여 세션 쿠키를 보유함. - 2) 사용자가 공격자 페이지(
evil.com)에 방문함. - 3) 공격자 페이지에 다음과 같은 숨겨진 요소가 있음:
<img src="https://bank.com/transfer?to=hacker&amount=1000000" />- 4) 브라우저는
bank.com도메인에 대한 쿠키를 자동으로 포함하여 요청을 전송. - 5) 서버는 정상 사용자 요청으로 인식하여 송금 등 민감 동작 수행.
공격 원리 요약
- 브라우저가 도메인별 쿠키/세션을 자동으로 전송함.
- 서버가 요청의 '진짜 의도'나 '출처'를 검증하지 않으면 공격이 성공함.
- CSRF는 사용자의 권한(세션)을 악용하는 공격이며, 스크립트 삽입(XSS)과는 다른 방식임.
주요 방어 기법
-
CSRF Token (권장)
- 서버가 세션별 또는 폼별 고유 난수 토큰을 발급하고, 모든 상태 변경 요청(POST/PUT/DELETE 등)에 토큰 포함 요구.
- 서버는 수신 토큰과 세션 토큰을 비교해 불일치 시 요청 거부(예:
403 Forbidden). - 토큰은 예측 불가능해야 하며, 동일 출처에서만 유효하게 검증해야 함.
-
SameSite Cookie 속성 설정
SameSite=Strict: 원본 사이트 외의 요청에 쿠키 전송 금지(가장 안전).SameSite=Lax: 일부 안전한 네비게이션(예: GET 링크)만 쿠키 전송 허용.SameSite=None; Secure: 제3자 전송 허용(HTTPS 필요).- 가능한
Strict또는Lax사용 권장.
-
Referer / Origin 검증
- 서버에서
Origin또는Referer헤더를 확인해 허용된 출처만 처리. Origin이 있는 요청(특히 CORS 상황)에서 더 신뢰성 있음.- 헤더가 없는 일부 환경을 고려한 보완 로직 필요.
- 서버에서
-
사용자 재인증 (Step-up authentication)
- 송금, 비밀번호 변경 등 민감 작업은 추가 인증(비밀번호 재입력, OTP) 요구.
-
Double-submit Cookie (대체 기법)
- 쿠키와 폼 필드에 같은 CSRF 토큰을 넣어 비교하는 방식(서버 세션 저장 없이 사용 가능).
- 적절히 구현하면 유효하지만 토큰 보호와 HTTPS 필요.
-
CORS 정책으로 제한
- API 서버는 CORS 설정으로 허용 출처만 허용하고, 자격증명 전송 여부를 엄격히 제어.
프레임워크/실무 팁
-
대부분 프레임워크는 기본 CSRF 보호 기능 제공
- Django, Spring Security, Rails, Express(csrf 미들웨어) 등에서 기본 제공.
- 개발 중
@csrf_exempt또는 유사 예외 처리를 남용하지 않도록 주의.
-
GET 요청은 무상태(부작용 없는)로 유지
- 상태 변경(송금, 삭제 등)은 반드시 POST/PUT/DELETE 등 비-GET 메서드로 구현.
-
AJAX 요청 시
- JS에서 토큰을 읽어 헤더(
X-CSRF-Token)에 포함해 전송하고 서버에서 검증.
- JS에서 토큰을 읽어 헤더(
-
테스트/취약점 점검 시
- 자동화 스캐너/리플레이 시 CSRF 토큰이 누락되면 403 발생 → 정상 동작임을 확인.
- 반대로 토큰이 비활성화된 엔드포인트는 취약점으로 기록.
CSRF vs XSS (간단 비교)
| 구분 | CSRF | XSS |
|---|---|---|
| 공격 대상 | 서버 | 클라이언트(브라우저) |
| 공격 방식 | 인증된 사용자의 권한을 악용 | 악성 스크립트를 삽입·실행 |
| 목표 | 사용자의 권한으로 요청 수행 | 세션 탈취, 페이지 변조 |
| 방어법 | CSRF Token, SameSite Cookie, 출처 검증 | 입력값 검증, 출력 인코딩, CSP |
실무에서 자주 발생하는 실수
- CSRF 토큰을 모든 상태 변경 엔드포인트에 적용하지 않음.
SameSite=None또는SameSite설정 미흡으로 외부 요청에 쿠키가 전송됨.- 개발 편의를 위해 CSRF 검증을 우회(예:
csrf_exempt)하고 이를 제거하지 않음. - API 설계 시 토큰 검증 로직이 누락되어 노출됨.
요약(핵심 한 문장)
- CSRF 방어의 핵심은 “요청이 진짜 사용자의 의도인지 검증”하는 것 — 토큰, 출처 검증, 재인증을 적절히 조합해 적용하라.
