CSRF: 로그인된 브라우저의 요청 검증

01개념과 구성 요소

• 성립 원리브라우저가 자동 첨부하는 인증 정보와 사용자가 의도한 요청은 같지 않다.
• 필요 조건외부 출처에서 요청을 만들 수 있고 인증 상태가 전달되며 서버가 별도 의도 검증 없이 상태를 바꿀 때 문제가 생긴다.
• 보호 요소세션에 연결한 토큰, 출처 검사, 적절한 쿠키 정책을 사용하며 민감 작업에는 추가 인증을 적용할 수 있다.

02Synchronizer Token으로 설정 변경을 처리하는 순서

1. 정상 폼 발급서버가 인증된 세션에 연결된 예측하기 어려운 토큰을 정상 폼에 제공한다.
2. 변경 요청 전송브라우저가 폼 값·토큰과 쿠키 정책에 맞는 인증 쿠키를 보낸다.
3. 인증과 토큰 검증서버가 세션 유효성, 토큰 존재·일치·세션 연결을 확인한다. 쿠키에 토큰이 자동 첨부된다는 사실만으로는 충분하지 않다.
4. 인가와 입력 검증현재 사용자에게 변경 권한이 있고 값이 업무 규칙을 만족하는지 확인한다.
5. 상태 변경앞선 검증을 통과한 경우에만 변경한다. 오류 응답 전에 DB 변경을 먼저 수행하면 거부가 실제 보호가 되지 않는다.

03서버가 받은 요청과 사용자의 의도는 같지 않을 수 있다

• 자동 쿠키 전송로그인 후 브라우저는 대상 서비스에 맞는 쿠키를 자동으로 첨부한다. 다른 사이트에서 폼 제출·링크 이동·자원 로딩으로 그 서비스에 요청을 만들 수 있고 쿠키 정책상 인증 쿠키가 함께 전송되면 서버는 로그인한 사용자를 식별한다.
• 의도와 인증하지만 그 행동을 사용자가 의도했는지는 쿠키만으로 알 수 없다.
• 성립 조건CSRF는 이 자동 인증 상태를 이용하는 문제다. 공격자가 쿠키 값을 직접 훔쳐야만 성립하는 것은 아니고, 대상 사이트 안에 스크립트를 미리 저장할 필요도 없다.
• 응답 열람 없이 변경공격자가 응답 본문을 읽지 못해도 계정 설정이나 주문 상태가 서버에서 바뀌었다면 영향은 이미 발생했다.

04정상 폼이 상태를 바꾸는 순서

• 정상 폼일반적인 설정 변경에서는 사용자가 폼을 요청하고 서버가 현재 값을 보여 준 뒤 제출된 새 값을 처리한다. 서버 측 세션을 쓰는 synchronizer token 방식은 예측하기 어려운 값을 세션과 연결하고 정상 폼의 숨은 필드 등에 넣는다.
• 서버 검증제출 때는 인증 상태, 토큰의 존재·일치·세션 연결, 권한과 값의 유효성을 확인한 후 변경한다.
• 토큰의 비교 기준토큰이 단순히 요청에 있다는 사실보다 서버가 어떤 기준과 비교하는지가 중요하다. 토큰을 쿠키에만 넣고 브라우저가 자동 첨부하는지 보기만 하면 세션 쿠키와 같은 한계를 반복한다.
• 전송 위치또한 토큰은 사용자의 내심을 증명하는 것이 아니라 외부 사이트가 모르는 요청 문맥을 검증하는 보호 장치다.

<form action="/training/preferences" method="post">
  <input name="theme" value="dark">
  <input type="hidden" name="csrf_token" value="<가상 토큰>">
  <button type="submit">저장</button>
</form>

서버 흐름:
세션 확인 → 토큰 비교 → 권한·입력 검증 → 변경 → 결과 응답

비밀번호나 결제 대신 가상 화면 설정을 사용하는 정상 토큰 폼 예제다.

05One-click·자동 자원 요청·POST를 구분하기

• 링크·자원 요청링크를 클릭하면 대상 URL로 탐색하며 GET 요청이 발생할 수 있다. img 같은 요소는 사용자가 별도의 버튼을 누르지 않아도 문서를 표시하는 과정에서 자원을 요청한다.
• 상태 변경 메서드대상이 GET 요청으로 상태를 바꾸도록 설계되었다면 단순 자원 요청도 업무 변경에 연결될 수 있다. 이는 렌더링 엔진이 임의 코드를 몰래 실행해서가 아니라 정상적인 자원 요청의 부작용이다.
• POST의 한계POST로 바꾸는 것만으로 CSRF가 자동 해결되지는 않는다. 외부 사이트도 브라우저가 허용하는 폼 제출을 만들 수 있기 때문이다.
• 메서드 의미HTTP 메서드의 의미에 맞게 GET을 조회 중심으로 유지하는 것과 상태 변경 요청에 적절한 CSRF 검증을 적용하는 것은 함께 필요한 설계다.

06출처·사이트·CORS가 서로 다른 이유

• Origin과 SiteOrigin은 스킴·호스트·포트로 구분한다. 쿠키 SameSite의 사이트 판단은 이와 같지 않아 하위 도메인이나 포트 차이가 있더라도 두 판단이 같은 결과라고 단정할 수 없다.
• SameSiteSameSite=Strict, Lax, None은 교차 사이트 조건에서의 쿠키 전송을 서로 다르게 제한한다. 실제 브라우저의 쿠키 정책과 사용 흐름도 영향을 준다.
• CORS의 범위CORS는 브라우저 자바스크립트가 다른 출처의 응답에 접근하는 조건과 관련된다. 단순 요청처럼 서버에 먼저 도달할 수 있는 경로가 있어 CORS 오류가 뜬 사실만으로 서버가 요청을 받지 않았다고 결론 내릴 수 없다.
• Preflight미리 확인하는 preflight가 필요한 요청과 그렇지 않은 요청도 구분해야 한다. CSRF에서는 응답 열람보다 상태 변경이 핵심일 수 있다.

07세션 토큰 방식과 Double Submit의 차이

• Synchronizer TokenSynchronizer token은 서버 측 세션에 연결된 값을 요청의 별도 위치로 되돌려 받아 비교한다. 요청별 토큰은 재사용 범위를 줄일 수 있지만 여러 탭이나 뒤로 가기와의 상호작용이 생길 수 있다.
• 세션 연결세션 단위 토큰도 예측 불가능성과 올바른 연결·검증이 핵심이다.
• Double SubmitDouble Submit은 쿠키와 요청의 별도 필드에 실린 값을 비교하는 계열이다. 단순 동일값 비교를 아무 조건 없이 안전하다고 일반화하면 쿠키 주입 같은 문제가 남을 수 있다.
• 서명된 토큰서명과 세션 연결을 포함한 검토된 패턴을 사용해야 하며, 프레임워크가 제공하는 보호를 임의로 약화시키지 않는 것이 중요하다. API가 헤더 기반 인증을 사용하는 경우에도 어떤 값이 자동 전송되고 외부 출처가 그 헤더를 만들 수 있는지 위협 모델을 다시 읽는다.

1. 검증값 발급Double Submit 방식은 쿠키의 값과 별도로 요청에 제출될 값을 마련한다.
2. 명시적 제출정상 페이지가 폼 필드 또는 요청 헤더에 값을 넣어 보낸다. 자동 첨부 쿠키만 존재하는 요청과 구분한다.
3. 서버 대조서버가 제출값과 쿠키값 및 설계한 서명·세션 연결을 검증한다.
4. 변경 허용일치와 연결 조건을 통과한 뒤에만 인가·입력 검증을 거쳐 상태를 변경한다. 쿠키 주입이 가능한 환경의 단순 값 비교는 충분하지 않을 수 있다.

08Origin·Referer와 쿠키 속성의 역할

• 출처 헤더서버는 요청의 Origin 또는 정책에 맞는 Referer 정보를 대상 서비스와 비교하여 외부 출처 요청을 제한할 수 있다. 값의 부분 문자열만 비교하면 신뢰하지 않는 이름이 허용된 이름을 포함하는 경우를 잘못 받아들일 수 있으므로 정확한 출처 해석이 필요하다.
• 누락·프록시 정책헤더 누락·프록시의 외부 주소와 내부 주소 차이는 명시적인 정책으로 다뤄야 한다.
• SecureSecure는 안전한 전송 조건을, HttpOnly는 스크립트의 쿠키 읽기를 제한한다. 둘 자체는 브라우저가 정상적으로 인증 쿠키를 붙인 요청을 서버가 처리하는 문제를 해결하지 않는다.
• 쿠키 전송 조건SameSite도 추가 방어 층이지만 모든 동작과 환경의 CSRF 토큰을 무조건 대체하는 스위치는 아니다.

12XSS와 결합되면 보호의 전제가 달라진다

• CSRF와 XSSCSRF는 일반적으로 다른 사이트에서 인증된 브라우저를 이용해 요청을 만든다. XSS는 대상 출처에서 코드가 실행되는 경계를 침해한다.
• 토큰 노출같은 출처의 XSS 코드가 정상 페이지의 토큰을 읽고 요청을 보낼 수 있다면 외부 출처가 토큰을 모른다는 CSRF 보호의 전제가 약해진다.
• 원인에 따른 분류둘의 결과가 모두 설정 변경일 수 있어도 취약점 분류는 요청을 만든 원인과 실행 문맥을 기준으로 한다. 강제 로그아웃도 단순 외부 자원 요청으로 가능한지, 주입된 자바스크립트가 실행되어 발생했는지에 따라 설명이 달라진다.
• 보호 경계의 결합XSS 방어와 CSRF 방어를 함께 다뤄야 하는 이유는 같은 이름의 공격이어서가 아니라 서로의 경계를 침해할 수 있기 때문이다.

13토큰 오류가 났을 때 실제로 멈춰야 하는 단계

• 토큰 대조군학습 비교에서는 정상 토큰, 누락 토큰, 다른 세션 토큰, 만료된 세션을 나누고 상태 변경 여부를 본다. 토큰 오류 응답을 내면서 DB 변경을 먼저 수행했다면 화면상 거부와 서버 상태가 다르다.
• 검증 전 변경 금지변경은 인증·토큰·권한 검증 뒤에 있어야 하며 내부 로그에는 판단 단계와 요청 ID를 연결한다.
• 민감 기능로그인 요청, 파일 업로드, 비밀번호 재설정과 연동 해제처럼 일반 게시물 폼과 다른 경로도 상태 변화를 만든다. 민감한 작업은 재인증 등 추가 조건이 필요할 수 있다.
• 발급·검증 연결학습의 목적은 토큰 문자열을 암기하는 것이 아니라 정상 페이지 발급→요청 반환→서버 검증→변경이라는 순서가 어떻게 요청 위조를 제한하는지 설명하는 데 있다.