SameSite 쿠키가 CSRF를 죽였습니까?

대폭 줄였으나 없애지는 못했습니다. SameSite=Lax(최신 기본값)는 최상위 탐색에서 사이트 간 쿠키를 허용합니다. SameSite=Strict는 이를 방지하지만 합법적인 흐름을 중단시킵니다. CSRF 토큰은 여전히 권장되는 방어 수단입니다. SameSite는 보완적인 레이어입니다.

CSRF는 XSS와 어떻게 다른가요?

XSS는 신뢰할 수 있는 사이트에 악성 코드를 주입하여 해당 권한을 실행합니다. CSRF는 아무것도 주입하지 않고 브라우저를 속여 신뢰할 수 있는 사이트에 요청을 보냅니다. XSS는 CSRF가 할 수 있는 모든 일과 그 이상을 할 수 있습니다. 그들은 다른 공격 메커니즘입니다.

내 애플리케이션에서 CSRF를 테스트할 수 있나요?

예. 토큰을 제거하거나 변경한 상태로 양식을 제출해 보세요. 작업이 진행되면 CSRF가 있는 것입니다. SameSite 시행을 통해 Chrome에서 테스트하세요. 일부 레거시 프레임워크에는 실제로 확인되지 않은 CSRF 토큰이 있습니다. 수동 검토는 간단합니다.

단일 페이지 앱에는 CSRF 보호가 필요합니까?

쿠키를 통해 인증한다면 그렇습니다. 클라이언트 측(localStorage)에 저장된 Bearer 토큰을 통해 인증하는 경우 CSRF에 덜 취약하지만 XSS에 더 많이 노출됩니다. 두 공격 표면 모두 중요합니다. 두 가지를 모두 염두에 두고 인증 메커니즘을 선택하세요.

CSRF가 여전히 OWASP Top 10에 있나요?

광범위한 프레임워크 수준 완화 및 SameSite 쿠키 기본값으로 인해 2021년 상위 10위에서 제외되었습니다. 이는 여전히 OWASP의 심각한 취약점 목록에 있습니다. 근본적인 메커니즘이 아니라 보급률이 떨어졌습니다.

CSRF 설명: 웹사이트가 브라우저를 속여 사용자를 대신하여 작동하도록 하는 경우

교차 사이트 요청 위조(Cross-Site Request Forgery)는 악성 페이지가 귀하의 브라우저가 귀하가 로그인한 사이트에 요청을 제출하게 하는 취약점입니다. 즉, 귀하의 자격 증명을 사용하여 귀하가 승인하지 않은 작업을 수행하게 되는 것입니다. SameSite 쿠키는 대부분의 과거 공격 표면을 닫았지만 쿠키가 상태 변경 작업을 인증할 때마다 기본 클래스는 여전히 중요합니다.

전체 기사 본문은 아래에 영어로 제공됩니다.

Cross-Site Request Forgery(CSRF, XSRF 또는 "sea-surf"라고도 함)는 사용자 브라우저에 대한 웹사이트의 신뢰를 악용합니다. 공격자는 귀하의 쿠키를 볼 수 없지만 브라우저는 모든 요청과 함께 해당 쿠키를 해당 쿠키가 속한 원본으로 자동으로 보냅니다. 공격자가 귀하가 로그인한 사이트에 요청을 하도록 브라우저를 실행할 수 있는 경우, 공격자가 요청을 시작했더라도 해당 사이트는 인증된 요청을 보게 됩니다.

고전적인 공격

간단한 GET 요청을 통해 이체를 처리하는 은행을 상상해 보십시오: https://bank.example/transfer?to=Bob&amount=1000. 은행에 로그인되어 있습니다. 공격자는 링크를 이메일로 보내거나 https://bank.example/transfer?to=Attacker&amount=10000를 가리키는 이미지 태그가 포함된 페이지를 호스팅합니다. 브라우저가 이미지를 로드합니다. 은행은 귀하의 세션에서 인증된 요청을 확인합니다. 이체는 진행됩니다.

이러한 특정 예는 대부분 역사적 사례입니다. 은행은 더 이상 GET을 통한 이체를 처리하지 않습니다. 그러나 패턴은 일반적입니다. 세션 쿠키를 통해서만 인증하는 모든 상태 변경 요청은 잠재적으로 CSRF에 취약합니다.

CSRF를 가능하게 만드는 요소

세 가지 기반:

쿠키가 자동으로 전송됩니다. 브라우저는 권한을 요청하지 않습니다. 쿠키는 원본에 속하며 요청이 시작된 위치에 관계없이 모든 요청과 함께 해당 원본으로 이동합니다.
HTML은 원본 간 요청을 트리거할 수 있습니다. 이미지 태그, 양식 제출, 스크립트 태그 및 기타 다양한 요소는 모두 모든 URL을 겨냥할 수 있습니다.
서버는 의도를 확인하지 않고 요청에 대해 작동합니다. 서버는 인증된 요청을 확인합니다. 명시적인 CSRF 보호 없이 작업을 처리합니다.

표준 방어

CSRF 토큰(동기화 장치 토큰). 서버에는 모든 형식의 임의 토큰이 포함됩니다. 제출물에는 토큰이 포함되어야 합니다. 공격자의 악성 페이지는 토큰(동일 출처 정책)을 읽을 수 없으므로 위조된 요청은 실패합니다. 최신 웹 프레임워크는 자동으로 토큰을 생성하고 확인합니다.
SameSite 쿠키. SameSite=Lax(2020년 이후 최신 브라우저의 기본값)로 표시된 쿠키는 최상위 탐색을 제외하고 교차 사이트 요청 시 전송되지 않습니다. SameSite=Strict는 더욱 엄격합니다. 이는 지난 5년 동안 CSRF 위험을 줄인 가장 큰 변화입니다.
Origin 및 Referer 헤더 유효성 검사. 서버는 Origin 헤더가 예상 원본과 일치하는지 확인할 수 있습니다. 교차 사이트 요청에는 다른 출처가 있어 거부가 허용됩니다.
이중 제출 쿠키. 서버는 쿠키와 별도의 요청 매개변수 모두에 값을 설정합니다. 검증자는 일치하는지 확인합니다. 서버 측 세션 상태 없이 작동합니다.
민감한 작업에 대한 재인증. 비밀번호 확인, MFA 챌린지 또는 중요한 작업에 대한 단계별 인증. CSRF 및 기타 여러 공격 클래스를 동시에 물리칩니다.

SameSite 쿠키 혁명

2020년 이전에는 악성 페이지의 상태 변경 요청을 포함하여 모든 교차 사이트 요청이 대상 사이트의 쿠키를 전달했습니다. SameSite=Lax는 교차 사이트 쿠키를 규칙이 아닌 예외로 만들었습니다. 주요 브라우저는 2020~2021년에 Lax로 기본 설정되었으며 그 영향은 극적이었습니다. 대부분의 일반적인 CSRF 취약점은 하룻밤 사이에 악용할 수 없게 되었습니다.

문제점: SameSite=Lax는 여전히 최상위 탐색(전체 페이지 리디렉션)에서 쿠키를 허용합니다. 링크를 클릭하여 실행되는 상태 변경 작업은 여전히 쿠키를 전달할 수 있습니다. 방어는 훌륭하지만 완전하지는 않습니다.

SameSite=Strict는 이를 완전히 방지합니다. 단점: 사이트 간 탐색(Single Sign-On, 사후 OAuth 리디렉션)에 의존하는 로그인 흐름이 중단됩니다. 대부분의 주요 사이트에서는 Lax를 기본값으로 사용하고 가장 민감한 쿠키에만 Strict를 사용합니다.

CSRF 및 API

최신 API는 쿠키 대신 승인 헤더(Bearer 토큰)를 통해 인증하는 경우가 많습니다. 브라우저가 원본 간 요청에 임의의 헤더를 자동으로 포함하지 않기 때문에 CSRF는 적용되지 않습니다. CSRF 문제는 주로 쿠키 인증 시스템에 속합니다.

그러나 일부 흐름에는 쿠키를 혼합하고 다른 흐름에는 토큰을 혼합하는 API는 미묘한 CSRF 표면을 가질 수 있습니다. 둘 중 하나를 일관되게 사용하십시오.

CSRF 및 CORS

CORS(Cross-Origin Resource Sharing)는 브라우저가 JavaScript에서 Cross-Origin 요청을 읽을 수 있도록 허용하는 시기를 정의합니다. CSRF는 요청이 쿠키와 함께 sent인지 여부에 관한 것입니다. 서로 관련되어 있지만 서로 다릅니다.

CSRF는 악성 페이지가 요청을 유발하는 것을 방지합니다.
CORS는 악성 페이지가 응답을 읽지 못하도록 방지합니다.

A CSRF 공격은 응답을 읽을 필요가 없으며 서버가 작업을 실행하기만 하면 됩니다. 브라우저는 충실하게 요청을 실행하고 응답을 받습니다. 악성 페이지에서는 보이지 않을 수도 있지만 피해가 발생했습니다. CORS는 CSRF를 수정하지 않습니다.

유명한 CSRF 사건

Netflix 대기열 조작(2006). 연구원들은 조작된 IMG 태그가 사용자의 개입 없이 Netflix 대기열에 영화를 추가할 수 있다는 사실을 발견했습니다. 수정 사항은 널리 사용되는 최초의 CSRF 토큰이었습니다.
YouTube 계정 탈취 변형 2000년대 후반.
GitHub 저장소 삭제 2012년 CSRF를 통해(신속하게 수정됨)
수많은 WordPress 플러그인 CSRF 취약점가 매년 보고됩니다. 플러그인 생태계는 여전히 이를 대규모로 생성합니다.

2026년 개발자용

내장 CSRF 보호 기능이 있는 프레임워크 사용(Django, Rails, Spring, Laravel 모두 포함)
상태 변경 요청마다 CSRF 토큰 확인
Set SameSite=Lax (또는 Strict) 세션 쿠키
API의 경우 가능하면 쿠키 대신 전달자 토큰을 사용하십시오
고위험 작업에 대한 재인증 필요
오리진/리퍼러에만 의존하지 마십시오. 일부 클라이언트는 이러한 헤더를 생략합니다

For users

CSRF를 직접 방어할 수는 없습니다. 이는 서버측 버그입니다. 최신 브라우저 기본값(SameSite=Lax)은 상당한 도움이 되지만 로그인하는 모든 사이트에 보호 기능이 구현되어 있는지 의존하게 됩니다. 필요한 동안에만 로그인 상태를 유지하세요. 사용하지 않을 때는 민감한 계정에서 로그아웃하세요. 현대의 주요 사이트를 신뢰합니다. 그들은 모두 위협 모델에서 CSRF를 처리했습니다.

자주 묻는 질문

SameSite 쿠키가 CSRF를 죽였습니까?: 대폭 줄였으나 없애지는 못했습니다. SameSite=Lax(최신 기본값)는 최상위 탐색에서 사이트 간 쿠키를 허용합니다. SameSite=Strict는 이를 방지하지만 합법적인 흐름을 중단시킵니다. CSRF 토큰은 여전히 권장되는 방어 수단입니다. SameSite는 보완적인 레이어입니다.
CSRF는 XSS와 어떻게 다른가요?: XSS는 신뢰할 수 있는 사이트에 악성 코드를 주입하여 해당 권한을 실행합니다. CSRF는 아무것도 주입하지 않고 브라우저를 속여 신뢰할 수 있는 사이트에 요청을 보냅니다. XSS는 CSRF가 할 수 있는 모든 일과 그 이상을 할 수 있습니다. 그들은 다른 공격 메커니즘입니다.
내 애플리케이션에서 CSRF를 테스트할 수 있나요?: 예. 토큰을 제거하거나 변경한 상태로 양식을 제출해 보세요. 작업이 진행되면 CSRF가 있는 것입니다. SameSite 시행을 통해 Chrome에서 테스트하세요. 일부 레거시 프레임워크에는 실제로 확인되지 않은 CSRF 토큰이 있습니다. 수동 검토는 간단합니다.
단일 페이지 앱에는 CSRF 보호가 필요합니까?: 쿠키를 통해 인증한다면 그렇습니다. 클라이언트 측(localStorage)에 저장된 Bearer 토큰을 통해 인증하는 경우 CSRF에 덜 취약하지만 XSS에 더 많이 노출됩니다. 두 공격 표면 모두 중요합니다. 두 가지를 모두 염두에 두고 인증 메커니즘을 선택하세요.
CSRF가 여전히 OWASP Top 10에 있나요?: 광범위한 프레임워크 수준 완화 및 SameSite 쿠키 기본값으로 인해 2021년 상위 10위에서 제외되었습니다. 이는 여전히 OWASP의 심각한 취약점 목록에 있습니다. 근본적인 메커니즘이 아니라 보급률이 떨어졌습니다.