CSRF 공격
CSRF 공격
개요
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 인증된 사용자의 세션을 악용하여 사용자의 의지와 무관하게 특정 웹 애플리케이션에 요청을 보내게 만드는 보안 공격 기법입니다. 이 공격은 사용자가 이미 로그인된 상태에서 악성 웹사이트를 방문함으로써 발생할 수 있으며, 공격자는 이를 통해 사용자의 권한으로 계정 정보 변경, 자금 이체, 게시물 삭제 등의 민감한 작업을 수행할 수 있습니다.
CSRF는 웹 애플리케이션의 인증 메커니즘에 의존하는 특성상, 사용자의 브라우저가 자동으로 쿠키를 포함하여 요청을 보내기 때문에 효과적으로 작동합니다. 이 공격은 특히 인증 상태를 유지하는 세션 기반 웹 서비스에서 위험성이 큽니다.
CSRF 공격의 원리
1. 기본 동작 방식
CSRF 공격은 다음과 같은 단계로 진행됩니다:
- 사용자 인증: 사용자가 정상적인 웹사이트(예:
bank.com)에 로그인하여 세션 쿠키를 획득합니다. - 악성 사이트 방문: 사용자가 공격자가 준비한 악성 웹사이트(예:
evil.com)를 방문합니다. - 자동 요청 전송: 악성 사이트는 숨겨진 폼, 이미지 태그(
<img>), 자바스크립트 등을 이용해bank.com으로 요청을 보냅니다. - 브라우저의 자동 쿠키 첨부: 브라우저는 동일한 도메인(
bank.com)에 대한 요청이므로 자동으로 세션 쿠키를 포함시켜 요청을 전송합니다. - 서버의 정상 처리: 서버는 인증된 사용자의 요청으로 간주하여 요청을 처리합니다.
예를 들어, 다음 HTML 코드는 사용자의 계좌에서 100만 원을 공격자 계좌로 이체하는 요청을 자동으로 전송할 수 있습니다:
<img src="https://bank.com/transfer?to=attacker&amount=1000000" width="0" height="0">
사용자가 이 페이지를 열면 브라우저는 자동으로 이미지를 로드하려 하며, 이 과정에서 은행 서버로 이체 요청이 전송됩니다.
CSRF 공격의 유형
1. GET 기반 CSRF
GET 요청을 통해 상태를 변경하는 경우 발생합니다. 예를 들어, https://example.com/delete?post=123과 같은 URL로 게시물을 삭제하는 기능이 있다면, 이 URL을 악성 사이트에서 로드하면 자동으로 삭제가 발생할 수 있습니다.
⚠️ 주의: HTTP 표준에 따르면 GET 요청은 읽기 전용이어야 하며, 상태 변경 작업은 POST, PUT, DELETE 등의 메서드를 사용해야 합니다.
2. POST 기반 CSRF
POST 요청도 공격이 가능합니다. 악성 사이트는 자동 제출되는 폼을 생성하여 POST 요청을 보낼 수 있습니다:
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="1000000">
</form>
<script>document.forms[0].submit();</script>
이 코드는 사용자가 별다른 조작 없이도 자동으로 폼을 제출하게 됩니다.
CSRF 공격의 예시 시나리오
- 소셜 미디어 계정 해킹: 사용자가 로그인된 상태에서 악성 링크를 클릭하면, 공격자가 사용자의 계정으로 특정 게시물을 자동으로 작성하거나 팔로우를 유도할 수 있습니다.
- 은행 계좌 이체: 인증된 사용자의 세션을 이용해 자금을 공격자 계좌로 이체합니다.
- 관리자 권한 악용: 관리자가 로그인된 상태에서 CSRF 공격을 받으면, 공격자가 전체 사용자 계정을 삭제하거나 시스템 설정을 변경할 수 있습니다.
CSRF 방어 기법
1. CSRF 토큰 (Synchronizer Token Pattern)
가장 일반적이고 효과적인 방어 방법입니다. 서버는 각 세션 또는 요청에 대해 고유한 토큰을 생성하고, 클라이언트가 폼 제출 시 이 토큰을 포함하도록 요구합니다. 서버는 요청 수신 시 토큰의 유효성을 검증합니다.
예시:
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="a1b2c3d4e5">
<input type="text" name="amount">
<button type="submit">이체</button>
</form>
2. SameSite 쿠키 속성
쿠키에 SameSite 속성을 설정하면, 다른 사이트에서의 요청 시 쿠키가 전송되지 않습니다. 다음과 같은 값이 있습니다:
[SameSite=Strict](/doc/%EA%B8%B0%EC%88%A0/%EC%9B%B9%EA%B8%B0%EC%88%A0/%EC%BF%A0%ED%82%A4%EB%B3%B4%EC%95%88/SameSite%3DStrict): 모든 크로스 사이트 요청에서 쿠키 미전송[SameSite=Lax](/doc/%EA%B8%B0%EC%88%A0/%EC%9B%B9%EA%B8%B0%EC%88%A0/%EC%BF%A0%ED%82%A4%EB%B3%B4%EC%95%88/SameSite%3DLax): 안전한 GET 요청(링크 이동 등)은 허용, POST 등은 차단[SameSite=None](/doc/%EA%B8%B0%EC%88%A0/%EC%9B%B9%EA%B8%B0%EC%88%A0/%EC%BF%A0%ED%82%A4%EB%B3%B4%EC%95%88/SameSite%3DNone): 명시적으로 크로스 사이트 허용 (HTTPS 필수)
Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
3. Referer / Origin 헤더 검증
서버는 요청의 Referer 또는 Origin 헤더를 검사하여 요청이 신뢰할 수 있는 도메인에서 왔는지 확인합니다. 다만, 프라이버시 설정이나 프록시로 인해 헤더가 누락될 수 있어 보조 수단으로 사용됩니다.
4. 사용자 재인증
민감한 작업(예: 비밀번호 변경, 자금 이체) 시 추가 인증(예: 비밀번호 재입력, 2FA)을 요구하여 공격의 영향을 줄입니다.
관련 보안 표준 및 프레임워크 지원
- OWASP Top 10: CSRF는 오랫동안 OWASP 웹 애플리케이션 보안 위협 상위 10개 중 하나로 분류되어 왔습니다.
- Spring Security:
CsrfFilter를 제공하여 자동으로 CSRF 토큰을 관리합니다. - Django: 기본적으로 CSRF 보호 미들웨어가 활성화되어 있습니다.
- Express.js:
csurf미들웨어(현재는 유지보수 중단) 또는csurf의 대체재인csrf-csrf등을 사용할 수 있습니다.
참고 자료
CSRF는 단순해 보이지만, 적절한 방어 조치가 없을 경우 심각한 피해를 초래할 수 있는 공격입니다. 개발자는 HTTP 메서드의 올바른 사용, CSRF 토큰 도입, SameSite 쿠키 설정 등을 통해 시스템의 보안성을 강화해야 합니다.
이 문서는 AI 모델(qwen-3-235b-a22b-instruct-2507)에 의해 생성된 콘텐츠입니다.
주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.