CSRF (Cross-Site Request Forgery)

by

CSRF (Cross-Site Request Forgery)란?

CSRF (크로스 사이트 요청 위조)는 공격자가 사용자를 속여 원하지 않는 요청을 특정 웹사이트에 보내도록 하는 웹 보안 취약점입니다. 사용자가 이미 로그인된 상태에서 악성 요청이 자동으로 실행되면 공격자가 사용자 권한으로 임의의 작업을 수행할 수 있습니다.

🛑 CSRF 공격 방식

  1. 자동 요청 유도
    • 공격자가 CSRF 공격을 포함한 악성 웹페이지(또는 이메일)를 만들어 사용자가 클릭하도록 유도합니다.
    • 사용자가 로그인된 상태라면, 해당 사이트의 세션/쿠키가 자동으로 포함되어 요청이 서버에서 유효한 것으로 처리됩니다.
  2. GET 요청을 이용한 CSRFhtml복사편집<img src="https://victim.com/transfer?amount=10000&to=hacker" />
    • 사용자가 공격자의 페이지를 방문하면 자동으로 요청이 실행됩니다.
    • 피해자의 계정에서 돈이 전송될 수도 있음.
  3. POST 요청을 이용한 CSRFhtml복사편집<form action="https://victim.com/transfer" method="POST"> <input type="hidden" name="amount" value="10000"> <input type="hidden" name="to" value="hacker"> <input type="submit"> </form> <script>document.forms[0].submit();</script>
    • 자동으로 폼이 제출되어 서버에서 요청이 실행됨.

🛡️ CSRF 방어 방법

1. CSRF 토큰 사용 (최고의 방법)

  • 서버에서 요청할 때 CSRF 토큰을 함께 전송하도록 요구.
  • 예제 (Django처럼 csrf_token을 사용하는 방식):html복사편집<form action="/transfer" method="POST"> <input type="hidden" name="csrf_token" value="abcdef123456"> <input type="text" name="amount"> <input type="submit" value="Transfer"> </form>
  • 서버는 받은 CSRF 토큰이 유효한지 검증해야 함.

2. SameSite 속성 설정 (쿠키 보호)

  • 쿠키에 SameSite=Strict 또는 SameSite=Lax 설정.
  • SameSite=Strict: 완전히 다른 도메인에서의 요청은 쿠키가 포함되지 않음.
  • SameSite=Lax: GET 요청에서는 쿠키를 포함하지 않지만, 사용자 인터랙션이 있는 경우에는 포함됨.
  • 예제 (Set-Cookie 응답 헤더):vbnet복사편집Set-Cookie: sessionid=xyz123; Secure; HttpOnly; SameSite=Strict

3. CORS 정책 강화

  • 서버에서 Access-Control-Allow-Origin을 신중하게 설정.
  • Access-Control-Allow-Methods를 필요한 요청만 허용.

4. Referer / Origin 검사

  • 요청의 Referer 또는 Origin을 확인하여 신뢰할 수 있는 출처에서 온 요청만 처리.
  • 하지만 일부 브라우저에서는 Referer를 비워서 보낼 수도 있음.

📌 CSRF vs XSS (차이점)

항목CSRFXSS
공격 방식사용자가 원하지 않는 요청을 실행하도록 유도악성 스크립트를 실행하여 데이터를 탈취
주 대상사용자의 세션/권한클라이언트 브라우저
해결 방법CSRF 토큰, SameSite 쿠키 설정입력값 검증, Content Security Policy (CSP) 적용
CSRF vs XSS (차이점 비교표 상세버전)
항목CSRF (Cross-Site Request Forgery)XSS (Cross-Site Scripting)
공격 방식사용자가 원치 않는 요청을 자동 실행하도록 유도악성 스크립트를 삽입하여 실행
공격 목표사용자의 인증된 세션을 악용하여 특정 사이트에서 동작 수행클라이언트(브라우저)에서 악성 스크립트 실행을 유도
공격자의 조작 위치공격자가 피해자의 브라우저를 통해 서버로 요청을 전송공격자가 악성 스크립트를 클라이언트(브라우저)에서 실행
서버/클라이언트 여부서버 사이드 공격 (사용자의 권한을 악용해 서버에 영향을 줌)클라이언트 사이드 공격 (브라우저에서 직접 실행됨)
요구되는 전제 조건피해자가 로그인된 상태여야 하며, 해당 사이트에 대한 유효한 세션 쿠키를 보유로그인 필요 없음, 단순히 웹 페이지 방문만으로 공격 가능
공격 성공 시 결과– 비밀번호 변경, 계좌이체, 게시글 작성 등 사용자의 권한으로 원하지 않는 요청 실행
– 서버 로그에는 정상적인 사용자의 요청처럼 보임		– 쿠키 탈취, 세션 하이재킹
– 키로깅, 피싱 페이지 삽입
– DOM 조작 (예: 가짜 로그인 폼 표시)
공격 예시html <img src="https://victim.com/transfer?amount=10000&to=hacker">html <script>document.cookie="session=attacker"</script>
주 대상서버: 사용자의 권한을 악용하여 서버에서 동작 수행클라이언트(브라우저): 사용자의 브라우저에서 직접 코드 실행
해결 방법– CSRF 토큰 사용
– SameSite 쿠키 설정
– Referer/Origin 검사
– CORS 정책 강화		– 입력값 검증 및 이스케이프 처리 (<, >, " 등 특수문자 인코딩)
– Content Security Policy (CSP) 설정
– HTTPOnly 및 Secure 쿠키 설정
공격이 가능한 HTTP 메서드주로 GET, POST, PUT, DELETE 등 모든 요청에 적용 가능주로 GET 요청에서 발생 (사용자가 웹사이트를 방문하는 것만으로 감염될 수 있음)
대표적인 예방 기술CSRF 토큰, SameSite 쿠키, 인증된 API 요청XSS 필터링, CSP(Content Security Policy), Input Sanitization
취약한 환경로그인 기반 웹 애플리케이션 (특히 세션 쿠키를 사용하는 사이트)사용자 입력을 필터링하지 않는 모든 웹 애플리케이션

📢 결론

  • CSRF 토큰 사용이 가장 확실한 해결책
  • SameSite 쿠키 적용하여 CSRF 위험 감소 가능
  • CORS, Referer 검사 등 추가적인 보안 강화 필요

👉 CSRF는 세션 기반 인증 시스템에서 특히 위험하므로, 보안 조치를 철저히 해야 합니다! 🔒

Leave a Comment