CSRF
로그인된 브라우저가 보내는 원치 않는 요청
발생 상황
비밀번호 변경, 관리자 권한 변경, 게시글 삭제 등 인증 쿠키로 처리되는 상태 변경 기능에 요청 출처 검증이 없을 때 발생합니다.
주요 유형
GET 기반 상태 변경, 폼 POST 기반 요청, 관리자에게 노출되는 콘텐츠를 통한 요청 유도가 있습니다. 로그인 CSRF처럼 사용자를 공격자가 정한 계정으로 로그인시키는 경우도 있습니다.
분석할 때 주의할 점
공격자가 응답을 읽지 못해도 상태 변경은 성공할 수 있습니다. CORS와 CSRF 방어를 혼동하지 마세요. 쿠키 SameSite 설정, 사이트 경계, 메서드, Content-Type에 따라 브라우저의 쿠키 전송 조건이 달라집니다.
대응 방안
프레임워크의 CSRF 보호를 사용하고 토큰을 서버에서 검증합니다. Origin·Referer 검증과 SameSite 쿠키를 함께 적용합니다. GET은 조회에만 쓰고 중요한 변경은 재인증을 요구합니다.
자주 놓치는 부분과 특이사항
XSS가 있으면 같은 사이트에서 토큰을 읽거나 정상 요청을 만들 수 있어 CSRF 방어가 무력화될 수 있습니다. 관리자 봇 문제는 봇의 로그인 상태와 방문 경로가 실제로 구현되어야 의미 있는 실습이 됩니다.
CSRF와 관리자 브라우저 더 알아보기
로그인된 브라우저가 쿠키를 자동으로 첨부하는 성질을 이용해 사용자가 의도하지 않은 상태 변경 요청을 보내게 합니다. XSS와 달리 공격자의 스크립트 실행이 반드시 필요한 것은 아닙니다.
img나 iframe이 요청을 만들 수 있어도 실제 성공 여부는 HTTP 메서드, 쿠키 SameSite, 인증 상태에 달려 있습니다. CSRF 토큰·Origin 검사·중요 작업 재인증을 적용하고 GET으로 상태를 변경하지 않습니다.
요청과 구현 비교
세 주체와 두 가지 경계
공격자가 페이지를 준비하고, 로그인된 피해자 브라우저가 방문하며, 대상 서버가 피해자의 쿠키로 변경 요청을 처리합니다. 공격자가 응답을 읽지 못해도 변경될 수 있습니다. same-origin은 스킴·호스트·포트가 모두 같아야 합니다. same-site는 스킴과 등록 가능 도메인을 기준으로 하므로 서로 다른 서브도메인은 same-site이면서 cross-origin일 수 있습니다. 브라우저에서 실제 쿠키 전송 조건을 확인해야 하며 Repeater 성공만으로 CSRF를 입증할 수 없습니다.
일반 CSRF와 17번 복합 문제
일반 CSRF는 공격자 출처의 페이지가 피해자 브라우저에 요청을 보내게 하며, 스크립트가 대상 출처에서 실행될 필요는 없습니다. 17번은 문의 HTML이 대상 출처에서 실행되는 XSS와 인증된 상태 변경 요청이 결합됩니다. CSRF 토큰만 추가하고 XSS를 남겨 두면 동일 출처 스크립트가 그 토큰을 사용할 수 있으므로 두 경계를 모두 고쳐야 합니다.
일반 CSRF: 외부 페이지 → 로그인된 브라우저 → 상태 변경 요청
17번 복합: 저장된 문의 HTML → 운영자 브라우저에서 실행 → 인증된 요청적용 조건과 재검증
토큰과 요청 출처
방어용 토큰은 세션에 연결되고 예측하기 어려워야 합니다. Origin이 없는 요청을 어떻게 처리할지 정책을 정하고, Fetch Metadata의 Sec-Fetch-Site 같은 정보도 보조 신호로 사용할 수 있습니다. CORS 허용 여부만으로 상태 변경 요청을 보호할 수는 없습니다.
17번의 결합 조건
17번은 운영자가 보는 문의 내용이 HTML로 렌더링되어 스크립트가 실행되고, 그 브라우저의 인증 쿠키를 이용한 상태 변경 요청이 처리되는 결합 실습입니다. 일반적인 CSRF는 스크립트 실행을 필수 조건으로 요구하지 않습니다.