CSRF

정의

Cross Site Request Forgery(이하 CSRF)는 공격자가 사용자의 세션 쿠키나 인증 정보를 이용해, 사용자가 의도하지 않은 HTTP 요청을 피해자의 브라우저에서 실행하게 만드는 취약점입니다. 예를 들어, 공격자는 <img> 태그나 <form> 자동 전송 스크립트 등을 이용해 피해자의 쿠키가 포함된 요청을 임의의 엔드포인트로 전송할 수 있습니다.

XSS와 CSRF의 차이

• 공통점
  • 둘 다 클라이언트를 겨냥한 공격이며, 피해자가 악성 페이지에 접속해야 실행됩니다.
• 차이점
  • XSS: 공격 스크립트를 피해 사이트의 오리진에서 실행시켜 세션 탈취 등 직접적인 코드 실행을 목적으로 합니다.
  • CSRF: 피해 브라우저가 이미 갖고 있는 인증 정보를 이용해, 서버 측의 임의 기능(비밀번호 변경, 자금 이체 등)을 수행시키는 것이 목적입니다. 

공격 조건 및 기법

1. 유효한 인증 상태
   피해자가 공격 대상 사이트에 로그인되어 있어야 합니다.
2. 예측 가능한 요청 파라미터
   공격자가 값(예: 폼 토큰, 기존 비밀번호 등)을 알 수 없으면 공격이 실패합니다.
3. 관련 액션
   공격자가 유도하려는 ‘상태 변경(state-changing)’ 기능이 존재해야 합니다.
4. 주요 기법
   • <img src="…">, <iframe src="…"> 등을 이용한 GET 요청 유도
   • <form> + onload="submit()" 스크립트를 이용한 POST 요청 자동 전송
   • <script> 태그로 동적 XHR/Fetch 요청 삽입
     

전통적 방어 기법

1. Referer/Origin 헤더 검증
   • Referer 헤더가 애플리케이션 도메인과 일치하는지 확인
   • 보다 엄밀하게는 Origin 헤더를 활용 (단, 일부 브라우저·프록시에 의해 생략될 수 있음) 
2. Synchronizer Token Pattern (CSRF 토큰)
   • 서버가 세션별 난수 토큰을 발급해 폼에 숨겨두고, 제출 시 매번 검증
   • 대부분 프레임워크에서 기본 지원
3. Double Submit Cookie
   • 클라이언트에 CSRF 토큰을 쿠키와 폼 파라미터 두 곳에 저장
   • 서버는 쿠키 값과 폼 값을 비교해 일치하면 요청 승인 

최신 동향: SameSite 쿠키와 브라우저 단 대응

구글·모질라 등 주요 브라우저 벤더가 도메인 간 쿠키 전송을 제어하는 SameSite 속성을 도입하면서, 공격 성공 조건이 크게 까다로워졌습니다.

• SameSite=Lax (기본값)
  대부분의 ‘상태 변경’(POST) 요청에서 외부 출처의 쿠키 전송을 차단
• SameSite=Strict
  외부 모든 출처에서의 쿠키 전송을 차단
• SameSite=None; Secure
  쿠키 전송 허용, 단 HTTPS에서만 가능
• 결과
  • CSRF 토큰·Referer 검증이 없어도 기본적인 공격이 실패하는 사례 증가
  • 기존 대비 보안 설정이 훨씬 강화됨

종합 방어 전략

1. 기본 방어(서버 측)
   • CSRF 토큰 + Referer/Origin 검증
   • Double Submit Cookie
2. 브라우저 단 강화
   • 인증 쿠키에 SameSite=Lax/Strict 적용
   • 중요한 API는 CORS와 커스텀 헤더(X-CSRF-Token)로 분리
3. 보완책
   • Content Security Policy(CSP)로 외부 스크립트 로딩 제어
   • 주요 민감 동작은 추가 인증(2차 OTP, CAPTCHA) 요구