CSRF (Cross-Site Request Forgery): 단순 방어법으로 충분할까?

1. CSRF란 무엇인가?

CSRF(Cross-Site Request Forgery)는 공격자가 피해자의 세션을 이용해 의도치 않은 요청을 보내도록 유도하는 웹 보안 취약점이다. 이 공격이 성공하면 사용자의 인증된 상태를 악용해 비밀번호 변경, 송금, 게시물 작성 등 중요 액션이 수행될 수 있다.

하지만 CSRF를 단순히 '토큰 추가'로 해결할 수 있다고 생각한다면 큰 오산이다. 이 글에서는 CSRF의 근본 원인과 기존 해결책의 한계를 분석하고, 보다 견고한 방어 전략을 제시한다.

---

2. 왜 CSRF가 발생하는가?

CSRF는 웹의 기본적인 인증 방식에서 비롯된다. 대부분의 웹사이트는 사용자의 로그인 상태를 유지하기 위해 세션 쿠키를 사용한다. 문제는 브라우저가 같은 도메인의 요청이라면 자동으로 쿠키를 포함시킨다는 점이다.

2.1 공격 시나리오

1. 사용자가 bank.com에 로그인한 상태로 세션을 유지하고 있다.
2. 공격자는 evil.com에 CSRF 공격용 HTML을 삽입한다.
3. 사용자가 evil.com을 방문하면, 브라우저는 자동으로 bank.com에 요청을 보낸다.
4. 사용자는 의도치 않게 계좌이체 등의 액션을 수행하게 된다.

이처럼 브라우저의 기본 동작을 악용하는 것이 CSRF의 본질이다.

---

3. 흔한 CSRF 방어법과 그 한계

3.1 CSRF 토큰 (CSRF Token)

대부분의 웹 애플리케이션은 CSRF 토큰을 사용하여 방어한다. 이는 폼 요청 시 난수를 포함하고, 서버에서 이를 검증하는 방식이다.

✅ 장점: 요청이 악의적인지 식별할 수 있다. ❌ 한계: 일부 CSRF 공격 (특히 JSON 요청 기반) 방어가 어렵다.

 

3.2 SameSite 쿠키 속성

SameSite 쿠키는 브라우저가 다른 사이트에서 쿠키를 전송하지 않도록 제한하는 기능이다.

✅ 장점: CSRF 공격 자체를 원천 차단할 수 있다. ❌ 한계: 일부 브라우저에서 지원이 제한적이거나, SameSite=None 속성이 설정된 경우 무력화될 수 있다.

 

3.3 Referrer / Origin 헤더 검사

서버가 요청의 Origin 혹은 Referer 헤더를 검사하여 신뢰할 수 있는 도메인에서 왔는지 확인하는 방식이다.

✅ 장점: 간단한 구현으로 방어 가능. ❌ 한계: 일부 브라우저 환경에서는 Referer 헤더가 비어 있을 수 있어 신뢰할 수 없다.

---

4. 근본적인 해결책: 더 강력한 CSRF 방어 전략

CSRF를 보다 철저히 방어하려면, 단순 토큰을 넘어선 여러 가지 보안 레이어를 적용해야 한다.

4.1 SameSite=Strict 설정 + CORS 정책 강화

• 쿠키의 SameSite=Strict 설정을 기본값으로 하고, 필요 시 Lax로 설정.
• CORS(Cross-Origin Resource Sharing) 정책을 강화하여 불필요한 도메인의 요청 차단.
  

4.2 JWT 기반 인증 활용

세션 기반 인증 대신 JWT(JSON Web Token)를 사용하면 CSRF 위험을 원천적으로 차단할 수 있다.

✅ 이유: JWT는 쿠키가 아닌 Authorization 헤더를 사용하기 때문에, 브라우저가 자동으로 요청에 포함시키지 않는다.

 

4.3 Content-Type 제한

서버에서 application/json 등의 Content-Type이 포함된 요청만 허용하도록 설정하면, CSRF 공격에 사용될 가능성이 낮아진다.

 

4.4 사용자 행동 분석 적용

• 중요한 요청(예: 결제, 비밀번호 변경) 전에 추가 인증(OTP, WebAuthn 등) 요구.
• 사용자의 행동 패턴을 분석하여 비정상적인 요청 감지.

---

5. 결론: 다층 방어 전략이 필수적

CSRF는 단순한 보안 취약점이 아니다. 기본적인 웹 인증 방식의 허점을 악용하는 공격이므로, 단순한 CSRF Token으로 모든 공격을 막을 수 없다.

 

✅ CSRF 방어를 위한 최적의 조합:

1. SameSite=Strict 쿠키 설정
2. 적절한 CORS 정책 적용
3. Origin 및 Referer 헤더 검사
4. JWT 기반 인증으로 전환 고려
5. 중요 액션에 대해 추가 인증 요구

이제 CSRF 방어를 단순한 토큰 검증이 아닌, 다층 보안 전략으로 접근해야 한다. 여러분의 애플리케이션에서는 어떤 방식으로 CSRF를 방어하고 있는가?