CSRF

 

 

 

CSRF(Cross-site request forgery)는 한 줄로 말하면:

사용자가 로그인된 상태를 악용해서,
원하지 않는 요청을 대신 보내게 만드는 공격

 

이다.

---

핵심 포인트

엄청 중요.

CSRF는:

"사용자를 해킹"

 

하는 게 아니라,

"브라우저가 자동으로 쿠키를 보내는 특성"

 

을 악용한다.

---

가장 쉬운 예시 은행 사이트

정상 상황

사용자 로그인 성공.

브라우저에는:

 

Cookie: SESSION=ABCD

 

저장됨.

이후 송금 요청

 

POST /transfer
Cookie: SESSION=ABCD

amount=100000

 

서버는:

"로그인된 사용자 요청이네"

 

라고 판단.

---

문제 상황

사용자가 로그인된 상태로:

악성 사이트

 

접속.

공격 페이지 안에

예:

<img src="https://bank.com/transfer?amount=1000000">

 

같은 코드 존재.

브라우저 동작

브라우저는 자동으로:

Cookie: SESSION=ABCD

 

를 bank.com 요청에 포함.

결과

서버 입장에서는:

"정상 로그인 사용자 요청"

 

처럼 보인다.

---

즉 핵심 문제

브라우저가 쿠키를 자동 전송

 

한다는 것.

---

그래서 이름이 CSRF

Cross-Site Request Forgery:

다른 사이트에서 요청 위조

 

 

---

조건 2개 필요

CSRF 성립하려면 보통:

조건	필요 여부
로그인 상태	필요
자동 인증정보 전송	필요

---

즉 주로 쿠키 기반 인증에서 발생

예:

• Session
• Cookie 기반 JWT

---

반대로 Authorization 헤더 기반 JWT는?

보통:

 

Authorization: Bearer TOKEN

 

은 브라우저 자동 전송 안 함.

그래서 일반적으로 CSRF 위험 낮다.

---

하지만 쿠키 저장 JWT는 가능

예:

HttpOnly Cookie JWT

 

구조면 CSRF 가능성 존재.

---

CSRF 방어 핵심

핵심은:

"이 요청이 진짜 우리 사이트에서 왔는가?"

 

검증하는 것.

---

대표 방어 1 — CSRF Token

가장 전통적.

---

흐름

서버가 랜덤 토큰 발급

예:

X9AF81...

 

---

페이지 안에 숨김 삽입

 

<input type="hidden" name="_csrf" value="X9AF81">

 

---

요청 시 같이 전송

 

POST /transfer

csrf_token=X9AF81

 

---

서버 검증

세션 안 값과 같은가?

 

검사.

---

왜 안전?

공격자는:

토큰 값을 읽을 수 없음

 

(동일 출처 정책 때문)

---

대표 방어 2 — SameSite Cookie

현대 브라우저 핵심.

쿠키 옵션:

 

Set-Cookie: SESSION=abc; SameSite=Lax

 

 

---

의미

다른 사이트 요청에는 쿠키 제한

 

---

현재 브라우저 기본값도 강화됨

Chrome 등 대부분:

SameSite=Lax

 

기본 적용.

---

대표 방어 3 — Origin/Referer 검사

서버가:

Origin
Referer

 

헤더 확인.

---

예시

 

Origin: https://myservice.com

 

---

다르면 차단.

---

실무에서 중요한 오해

GET 요청은 안전?

아니다.

중요 작업:

송금
삭제
수정

 

를 GET으로 만들면 위험.

---

그래서 REST 원칙 중요

메서드	용도
GET	조회
POST/PUT/DELETE	변경

---

Spring Security 기본

Spring Security는 기본적으로:

CSRF Protection 활성화

 

한다.

---

API 서버에서는 자주 끔

예:

 

http.csrf(csrf -> csrf.disable())

 

---

왜?

보통:

Authorization Header JWT

 

방식 사용해서.

---

하지만 쿠키 기반 JWT면?

다시 CSRF 고려해야 함.

---

실무 기준 정리

인증 방식CSRF 위험

Session Cookie	높음
Cookie JWT	가능
Authorization Header JWT	낮음

---

XSS와 차이

엄청 헷갈림.

---

CSRF

사용자 브라우저가 대신 요청

 

---

XSS

악성 JS 실행

 

---

CSRF는 읽기는 못함

보통:

요청만 보냄

 

이다.

---

핵심 한 줄

CSRF는:

브라우저의 자동 쿠키 전송 특성을 악용해,
로그인된 사용자의 권한으로 원치 않는 요청을 보내게 만드는 공격

 

이다.