CSRF (Cross-Site Request Forgery): 원리와 방어

CSRF는 로그인된 사용자의 브라우저가, 사용자 본인도 모르게 다른 사이트를 열었을 때 공격자가 원하는 상태 변경 요청을 보내게 만드는 공격이다. XSS와 달리 스크립트 실행 권한이 없어도 되고, "브라우저가 쿠키를 자동으로 붙여서 요청을 보낸다"는 성질만 이용한다.

원리

피해자가 로그인된 상태로 은행 사이트를 쓰고 있다고 하자. 공격자가 만든 페이지에 이런 폼이 있으면:

<form action="https://bank.example.com/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker-account">
  <input type="hidden" name="amount" value="1000000">
</form>
<script>document.getElementById('f').submit();</script>

피해자가 이 페이지를 여는 순간 브라우저가 bank.example.com으로 요청을 보내면서 저장된 세션 쿠키를 자동으로 첨부한다. 서버 입장에서는 정상 로그인 사용자가 보낸 요청과 구분이 안 된다.

GET 요청만으로 상태가 바뀌는 엔드포인트(예: /delete?id=1)는 <img src="..."> 태그 하나로도 트리거된다.

탐지 방법

1. 상태를 바꾸는 요청(POST/PUT/DELETE)에 CSRF 토큰이 있는지 확인
2. 토큰이 있다면: 요청에서 토큰을 제거하거나 다른 세션의 토큰으로 바꿔서 보내도 요청이 성공하는지 확인 (검증을 제대로 안 하는 구현이 의외로 많다)
3. SameSite 쿠키 속성 확인 (Strict/Lax/None) — 개발자 도구 Application 탭에서 확인 가능
4. GET으로 상태 변경이 가능한 엔드포인트가 있는지 확인 (그 자체로 문제)

방어

• CSRF 토큰: 폼/요청마다 예측 불가능한 토큰을 서버가 발급하고, 요청 시 세션에 저장된 값과 비교 검증.
• SameSite 쿠키: SameSite=Lax면 다른 사이트에서 발생하는 대부분의 자동 폼 제출/스크립트 요청에 쿠키가 안 붙는다. Strict가 더 안전하지만 정상적인 외부 링크 유입 시나리오에서 로그인이 풀린 것처럼 보일 수 있어 트레이드오프가 있다.
• 상태를 바꾸는 작업은 반드시 POST 이상으로만 처리 (GET으로 상태 변경 금지)
• 민감한 작업(비밀번호 변경, 결제)은 CSRF 토큰과 별개로 현재 비밀번호 재입력 등 추가 확인 단계를 둔다.