중학생도 이해하는 CSRF

🛡️ CSRF (Cross-Site Request Forgery) 쉽게 이해하기

CSRF는 해커가 '나인 척' 가장해서 웹사이트에 이상한 요청을 보내는 공격 방법입니다.
쉽게 말해, 내가 로그인되어 있다는 점을 악용해 내가 원하지 않은 행동(비밀번호 변경, 결제, 글 작성 등)을 나도 모르게 하게 만드는 것입니다.

---

🎡 1. 쉬운 비유: 놀이공원 자유이용권 사건

이 상황을 '놀이공원'에 비유하면 아주 쉽게 이해할 수 있습니다.

① 로그인 (자유이용권 발급)

여러분이 놀이공원에서 손목에 '자유이용권 밴드'를 찼습니다.

• 이 밴드만 보여주면 매점에서 밥을 외상으로 먹을 수 있습니다.
• (인터넷 상황): 웹사이트에 로그인해서 '쿠키/세션'을 받은 상태

② 함정 (사기꾼의 등장)

벤치에서 쉬고 있는데, 낯선 사람이 다가와 "이 상자 안에 뭐가 있는지 구경만 해볼래?"라고 합니다.

• (인터넷 상황): 해커가 보낸 이메일이나 링크를 클릭

③ 공격 (가짜 주문)

상자를 여는 순간, 상자 바닥에 숨겨진 무전기가 매점에 주문을 넣습니다.

📻 "지금 이 밴드를 찬 학생 앞으로 햄버거 100개 주문! 결제는 밴드로!"

④ 피해 발생

매점 직원은 무전기 신호와 함께 여러분의 '자유이용권 밴드'가 확인되니, 여러분이 직접 주문한 줄 알고 결제해 버립니다. 이것이 바로 CSRF입니다.

---

💻 2. 실제 인터넷에서는 어떻게 일어날까요?

1. 로그인 상태: 여러분이 은행 사이트에 로그인을 해둡니다. (브라우저가 로그인 증표를 기억함)
2. 미끼 클릭: 해커가 보낸 "경품 당첨" 링크를 클릭합니다.
3. 몰래 전송: 해커의 사이트에는 눈에 보이지 않는 명령어가 숨겨져 있습니다.

*"은행아, 지금 접속한 사람 계좌에서 내 계좌로 100만 원 보내줘."*

2. 자동 인증: 브라우저는 은행으로 명령을 보낼 때, 여러분이 이미 가지고 있던 로그인 증표(쿠키)를 자동으로 같이 보냅니다.
3. 공격 성공: 은행은 로그인된 사용자의 요청이라 믿고 돈을 송금합니다.

---

🛡️ 3. 어떻게 막을까요? (방어법)

개발자들은 이를 막기 위해 'CSRF 토큰'이라는 일회용 비밀 암호를 사용합니다.

• 기존 방식 (위험): "자유이용권 밴드만 보여주면 통과!"
• 방어 방식 (안전): "자유이용권 밴드와 함께, 지금 화면에 떠 있는 비밀 암호('바나나')를 같이 말해야 통과!"

해커는 여러분의 로그인 상태(밴드)는 몰래 이용할 수 있어도, 여러분 화면에만 떠 있는 순간의 비밀 암호(토큰)는 알 수 없어서 공격에 실패하게 됩니다.

---

✅ 요약

• CSRF란? 내 로그인 권한을 도용해 해커가 몰래 명령을 내리는 공격.
• 원인은? 브라우저가 로그인 증표(쿠키)를 자동으로 첨부하는 특성을 악용함.
• 해결책? CSRF 토큰 같은 추가 인증 수단을 사용해 방어함.

이전 내용과 이어지는 실전 적용 편입니다. 개념을 이해했다면, 실제 프로젝트 코드에 바로 적용할 수 있도록 정리했습니다.

---

🛠️ 개발자를 위한 CSRF 방어 가이드 (React/Next.js)

앞서 살펴본 개념을 실제 코드로 구현하는 3단계 방어 전략입니다. **1차 방어선(쿠키 설정)**만 잘해도 대부분의 공격을 막을 수 있으며, **2차 방어선(토큰)**까지 구축하면 금융권 수준의 보안을 갖출 수 있습니다.

---

🍪 1. [필수] 1차 방어선: SameSite 쿠키 설정

가장 가성비가 좋고 강력한 방법입니다. 브라우저에게 **"이 쿠키는 우리 사이트에서만 써!"**라고 강제하는 옵션입니다.

Backend 설정 예시 (Node.js / Next.js API)

로그인 성공 시 쿠키를 발급하는 코드에 sameSite 옵션을 추가하세요.

// res.setHeader 또는 쿠키 설정 라이브러리 사용 시
res.setHeader('Set-Cookie', serialize('auth_token', token, {
  httpOnly: true, // 자바스크립트로 탈취 불가 (XSS 방어)
  secure: process.env.NODE_ENV === 'production', // HTTPS에서만 전송
  sameSite: 'lax', // ✅ 핵심! (Lax 또는 Strict 사용)
  path: '/',
}));

• Strict: 오직 같은 도메인 내에서만 쿠키 전송 (가장 안전하지만, 외부 링크 타고 들어올 때 로그인 풀릴 수 있음)
• Lax: 안전한 이동(링크 클릭 등)은 허용하되, 공격 가능성이 있는 요청(POST, Form 전송 등)은 차단. (권장)

---

🔐 2. [권장] 2차 방어선: CSRF Token (Double Submit Cookie)

중요한 데이터 변경(계정 수정, 결제)이 일어나는 서비스라면 토큰 검증을 추가해야 합니다.

Frontend 구현 예시 (React + Axios)

매번 수동으로 토큰을 넣지 않고, Axios Interceptor를 사용해 모든 요청 헤더에 토큰을 자동으로 심어줍니다.

import axios from 'axios';

// 1. 쿠키에서 CSRF 토큰 값 추출 함수
function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}

const api = axios.create({
  baseURL: '/api',
  withCredentials: true, // ✅ 쿠키(토큰)를 주고받으려면 필수 설정
});

// 2. 요청 가로채기 (Interceptor)
api.interceptors.request.use((config) => {
  // 보통 서버가 'XSRF-TOKEN'이라는 이름으로 쿠키를 내려줍니다.
  const csrfToken = getCookie('XSRF-TOKEN'); 

  if (csrfToken) {
    // 헤더에 토큰을 실어 보냅니다. (백엔드 설정에 따라 키 이름 확인 필요)
    config.headers['X-XSRF-TOKEN'] = csrfToken; 
  }
  return config;
});

export default api;

---

🚀 3. [최신] Next.js 사용자라면? (Server Actions)

Next.js App Router를 사용 중이라면 훨씬 편합니다. Server Actions는 기본적으로 CSRF 공격을 방어하도록 설계되어 있습니다.

Server Action 예시 (자동 방어)

별도의 토큰 설정 없이, 폼 태그의 action에 서버 함수를 바로 연결하면 됩니다. Next.js가 내부적으로 해시 ID와 출처(Origin)를 검증합니다.

// app/actions.ts (Server)
'use server'

export async function updateProfile(formData: FormData) {
  // 🛡️ Next.js가 이미 CSRF 검증을 마친 상태입니다.
  const name = formData.get('name');
  await db.user.update({ where: { id: 1 }, data: { name } });
}

// app/page.tsx (Client)
'use client'
import { updateProfile } from './actions';

export default function Page() {
  return (
    <form action={updateProfile}>
      <input name="name" placeholder="새 이름 입력" />
      <button type="submit">저장</button>
    </form>
  );
}

---

📝 요약 체크리스트

1. 백엔드: 쿠키 옵션에 SameSite: 'Lax'가 설정되어 있는가?
2. 프론트엔드: withCredentials: true 설정이 되어 있는가?
3. 프론트엔드: (필요시) 헤더에 X-CSRF-TOKEN을 실어 보내는가?