네트워크 보안에서 CSRF란 무엇인가?
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 사용자가 이미 인증을 마친 신뢰할 수 있는 사이트에 대해, 악성 웹사이트·블로그·이메일·메신저 또는 웹 애플리케이션이 사용자의 의지와 무관하게 요청을 전송하도록 만드는 공격 기법입니다. 공격자는 피해자가 로그인된 상태를 이용해 자신의 권한으로 원치 않는 작업을 수행하게 됩니다.
CSRF 공격의 작동 원리와 예시
CSRF는 XSRF, Sea Surf, Session Riding 등 여러 이름으로도 불립니다. 이 공격은 사용자가 로그인 자격 증명을 보유하고 있는 다른 애플리케이션에서 원치 않는 동작을 실행하도록 유도하는 방식으로 이루어집니다.
예를 들어, 사용자가 은행 사이트에 로그인한 상태에서 악성 이메일에 포함된 링크를 클릭하면, 그 링크가 몰래 송금 요청이나 비밀번호 변경 요청을 은행 서버로 전송할 수 있습니다. 서버는 해당 요청이 사용자 본인의 의도라고 판단하기 때문에 공격이 성공할 경우, 기업과 최종 사용자 모두 심각한 피해를 입을 수 있습니다.
공격자는 CSRF로 무엇을 하려 하는가?
CSRF 공격은 웹 애플리케이션의 인증 절차를 이용해 대상 서버로 악성 요청을 보내는 방식으로 진행됩니다. 흥미로운 점은 공격자가 위조된 요청의 결과(응답 데이터)를 직접 볼 수 없다는 것입니다. 따라서 CSRF 공격은 데이터 탈취보다는 상태 변경(state change), 즉 계정 정보 수정, 자금 이체, 설정 변경 같은 작업에 집중합니다.
CSRF는 어떤 취약점인가?
CSRF는 인증된 사용자를 속여 본인이 의도하지 않은 동작을 수행하게 만드는 웹 애플리케이션 취약점입니다. 이로 인해 클라이언트나 서버 데이터가 무단으로 노출되거나, 세션 상태가 변경되고, 사용자 계정이 조작되는 등의 피해가 발생할 수 있습니다.
CSRF 방어의 핵심: CSRF 토큰
토큰 기반 방어가 작동하는 이유
CSRF를 방지하는 대표적인 방법은 폼(form)에 고유한 토큰을 포함시키는 것입니다. 공격자가 피해자를 속여 요청을 보내게 하려면 이 토큰 값을 추측해야 하지만, 암호학적으로 안전하게 생성된 토큰은 예측이 사실상 불가능합니다. 이러한 암호학적 보안성이야말로 anti-CSRF 메커니즘이 효과를 발휘하는 근본적인 이유입니다.
CSRF 토큰이 보호해 주는 방식
CSRF 토큰은 공격자가 피해자에게 전달할 수 있는 HTTP 요청을 만드는 것 자체를 불가능하게 만듭니다. 일반적으로 공격자는 서버 헤더를 쉽게 조작할 수 있기 때문에, 기존 헤더 값만 비교하는 것으로는 CSRF를 막을 수 없습니다. 따라서 상태 변경을 유발하는 모든 작업에는 반드시 일치하는 CSRF 토큰을 함께 전송해야 합니다.
HTTPS만으로 CSRF를 막을 수 있을까?
결론부터 말하면 아니요. HTTPS는 브라우저와 서버 간 통신 내용을 암호화할 뿐, CSRF 공격을 방지하지 못합니다. CSRF 관점에서 보면 통신 구간의 암호화 여부는 아무런 의미가 없습니다. HTTPS는 전송 데이터의 기밀성을 지켜줄 뿐, 사용자가 위조된 요청을 보내는 행위 자체를 차단하지 못하기 때문입니다.
OWASP가 권장하는 CSRF 대응 방안
애플리케이션에서 CSRF를 완화하려면 토큰 기반 방어를 적용하는 것이 좋으며, 크게 두 가지 방식이 있습니다.
- 상태 기반(Stateful) 방식: Synchronizer Token 패턴을 사용하여 서버 측에서 토큰을 생성하고 검증합니다.
- 상태 비기반(Stateless) 방식: Double Submit Cookie 기법을 활용하여 서버에 세션 저장 없이 토큰을 검증합니다.
또한 매우 민감한 작업에는 사용자 재인증 단계나 일회용 토큰(one-time token)처럼 사용자 개입이 포함된 추가 방어를 적용하는 것이 권장됩니다.
CSRF 방지를 위한 모범 사례 정리
- 프레임워크 내장 CSRF 보호 기능 활용: Spring, Django, Rails 등 주요 프레임워크는 검증된 CSRF 방어 기능을 기본 제공합니다.
- 상태 기반 애플리케이션에는 Synchronizer Token 패턴 적용: 서버에서 토큰을 생성·검증하여 요청의 정당성을 확인합니다.
- 상태 비기반 애플리케이션에는 Double Submit Cookie 적용: 쿠키와 요청 파라미터의 토큰 일치 여부를 비교합니다.
- 상태 변경 작업에 항상 CSRF 토큰 요구: 정보 수정, 결제, 삭제 등 중요한 동작에는 반드시 토큰 검증을 거칩니다.
CSRF는 오랜 역사를 지닌 공격 기법이지만, 토큰 기반 방어와 프레임워크의 보안 기능을 올바르게 적용하면 충분히 예방할 수 있습니다. 보안은 기술적 조치와 함께 개발 단계부터의 꾸준한 관심으로 완성됩니다.