donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

10 KiB

Raw Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

official-doc / Spring Security — Cross Site Request Forgery (CSRF) Protection (Servlet)

Layer: raw/official-docs/ — Spring Security 공식 레퍼런스(Servlet 스택) "Cross Site Request Forgery (CSRF)" 페이지의 원문 발췌. feature-keycloak-bff-csrf-samesite-defense branch의 AP3(BFF, oauth2Login cookie-session 패턴) CSRF 방어 메커니즘 결정(D3) 및 defense-in-depth 결정(D4) 근거로 보관.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-bff-csrf-samesite-defense	AP3 BFF(Spring `oauth2Login` cookie-session) 패턴에서 CSRF 토큰 방어 메커니즘(D3: synchronizer token / `CookieCsrfTokenRepository` / BREACH 방어)의 공식 벤더 근거. D4(defense-in-depth: CSRF token + SameSite 조합)에 대해서는 이 문서가 SameSite를 전혀 언급하지 않으므로 부분 근거만 제공 — 아래 Usage Boundaries 참조

출처

원본 URL: https://docs.spring.io/spring-security/reference/servlet/exploits/csrf.html
아카이브 URL: (미수집)
저자 / 조직: Spring Security (VMware/Broadcom) — 공식 레퍼런스 문서
발행일: 고정 발행일 없음 (rolling reference doc). 확인 시점 페이지 하단 버전 배너: Stable 7.1.0 / 7.0.6 / 6.5.11, Snapshot 7.1.1-SNAPSHOT / 7.0.7-SNAPSHOT / 6.5.12-SNAPSHOT
마지막 확인일: 2026-07-23

왜 저장했는지

AP3(BFF) 패턴은 OAuth2/OIDC 토큰을 backend session에 두고 browser에는 session cookie만 노출한다(브랜치 상속 결정 DEC-KEYCLOAK-PATTERNS-OVERVIEW-BFF-SESSION-001@1). 이 쿠키 기반 세션은 CSRF에 노출되므로, branch는 Spring Security가 실제로 구현하는 CSRF 방어 메커니즘(synchronizer token pattern, CookieCsrfTokenRepository, BREACH 방어)을 공식 문서로 확인해야 한다. 단, 이 특정 페이지는 SameSite 쿠키 속성을 전혀 다루지 않아 D4(SameSite 결합) 근거로는 불충분함을 확인하기 위해서도 저장한다.

핵심 인용

[§Cross Site Request Forgery (CSRF), 개요] "Spring Security protects against CSRF attacks by default for unsafe HTTP methods, such as a POST request, so no additional code is necessary."

[§CSRF Considerations › Logging Out] "This ensures that logging out requires a CSRF token and that a malicious user cannot forcibly log your users out."

[§Integrating with CSRF Protection] "For the synchronizer token pattern to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request."

[§Persisting the CsrfToken › Using the CookieCsrfTokenRepository] "The CookieCsrfTokenRepository writes to a cookie named XSRF-TOKEN and reads it from an HTTP request header named X-XSRF-TOKEN or the request parameter _csrf by default."

[§Handling the CsrfToken › Using the XorCsrfTokenRequestAttributeHandler (BREACH)] "BREACH protection is provided by encoding randomness into the CSRF token value to ensure the returned CsrfToken changes on every request."

추출된 주장

Claim ID prefix: SPRINGSEC-CSRF.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SPRINGSEC-CSRF-C1	Spring Security는 POST 등 unsafe HTTP method 요청에 대해 기본적으로 CSRF 공격을 방어하며 별도 설정 코드가 필요 없다	[§개요] "Spring Security protects against CSRF attacks by default for unsafe HTTP methods, such as a POST request, so no additional code is necessary."	`official-vendor-doc`	`.csrf(Customizer.withDefaults())` 또는 미설정 시 Spring Security 6.x/7.x 기본 동작	어떤 매커니즘(synchronizer token / double-submit / SameSite)으로 방어하는지는 이 문장 자체는 규정하지 않음 — 메커니즘은 C3·C4에서 별도 확인
SPRINGSEC-CSRF-C2	CSRF 방어가 없으면 악의적 사용자가 피해자를 강제로 로그아웃(또는 다른 state-changing 요청)시키는 위조 요청(forged request)이 가능하다 — CSRF 토큰 요구가 이를 차단한다	[§Logging Out] "This ensures that logging out requires a CSRF token and that a malicious user cannot forcibly log your users out."	`official-vendor-doc`	인증된 세션(쿠키)을 가진 사용자를 대상으로 한 상태 변경(state-changing) 요청 위조 시나리오 일반	CSRF 공격의 전체 위협 모델(예: 쿠키가 자동 첨부되는 근본 원인, SameSite와의 관계)을 설명하지는 않음 — 이 문장은 logout 시나리오에 한정된 결과 진술
SPRINGSEC-CSRF-C3	Spring Security의 CSRF 방어는 synchronizer token pattern이며, 공격자가 자동으로 재현할 수 없는 실제 CSRF 토큰을 HTTP 요청에 포함시켜야 한다	[§Integrating with CSRF Protection] "For the synchronizer token pattern to protect against CSRF attacks, we must include the actual CSRF token in the HTTP request."	`official-vendor-doc`	통합 방식(HTML form / JS / mobile) 무관하게 적용되는 핵심 방어 원리	토큰이 세션에 저장되는지 쿠키에 저장되는지는 이 문장만으로 규정하지 않음 — 저장 위치는 `CsrfTokenRepository` 구현체 선택 문제(C4 참조)
SPRINGSEC-CSRF-C4	`CookieCsrfTokenRepository`는 `CsrfToken`을 `XSRF-TOKEN`이라는 이름의 쿠키에 쓰고, 기본적으로 `X-XSRF-TOKEN` 요청 헤더 또는 `_csrf` 요청 파라미터로부터 읽는다	[§Using the CookieCsrfTokenRepository] "The CookieCsrfTokenRepository writes to a cookie named XSRF-TOKEN and reads it from an HTTP request header named X-XSRF-TOKEN or the request parameter _csrf by default."	`official-vendor-doc`	`CsrfTokenRepository`를 `CookieCsrfTokenRepository`로 명시적으로 구성한 JavaScript 기반 애플리케이션(AP3처럼 세션 대신/추가로 쿠키 기반 토큰 노출이 필요한 경우)	이 쿠키(`XSRF-TOKEN`)의 `SameSite` 속성값(Lax/Strict/None)이 무엇인지는 이 문장이 전혀 규정하지 않음 — `CookieCsrfTokenRepository`의 `SameSite` 기본값/구성 옵션은 이 페이지 범위 밖
SPRINGSEC-CSRF-C5	BREACH 방어는 CSRF 토큰 값에 무작위성(randomness)을 인코딩하여 매 요청마다 반환되는 `CsrfToken` 값이 달라지게 함으로써 제공된다	[§Using the XorCsrfTokenRequestAttributeHandler (BREACH)] "BREACH protection is provided by encoding randomness into the CSRF token value to ensure the returned CsrfToken changes on every request."	`official-vendor-doc`	기본 활성화된 `XorCsrfTokenRequestAttributeHandler` 사용 시(Spring Security 6+ 기본값)	BREACH 방어가 `SameSite` 쿠키 속성과 결합되어 있다거나 이를 대체·보완한다는 명제는 이 문장이 증명하지 않음 — BREACH는 CSRF 토큰 값 자체의 압축 사이드채널(compression side-channel) 공격 방어이며, cross-site 요청 자체를 막는 메커니즘이 아님

적용 경계

이 자료가 직접 증명하는 것:
- SPRINGSEC-CSRF-C1: Spring Security의 CSRF 기본 방어 활성화 범위(unsafe HTTP method)
- SPRINGSEC-CSRF-C2: CSRF 방어 부재 시 위협 시나리오(강제 로그아웃 등 위조 요청) 예시
- SPRINGSEC-CSRF-C3: synchronizer token pattern이 Spring Security CSRF 방어의 핵심 원리라는 사실
- SPRINGSEC-CSRF-C4: CookieCsrfTokenRepository의 쿠키명(XSRF-TOKEN)·요청 헤더명(X-XSRF-TOKEN)·파라미터명(_csrf) 기본값
- SPRINGSEC-CSRF-C5: BREACH 방어의 원리(토큰 값 randomization)
이 자료가 증명하지 않는 것 (UNSUPPORTED_DECISION 후보 — branch D4로 그대로 인용 금지):
- 이 문서(servlet/exploits/csrf.html)는 "SameSite"라는 단어를 단 한 차례도 언급하지 않는다 (원문 전체 대상 대소문자 무시 검색 결과 0건, 2026-07-23 확인). 따라서 branch의 D4("Spring이 CSRF token과 SameSite를 어떻게 combine하는가")를 이 자료 단독으로 정당화할 수 없다. SameSite 쿠키 속성 가이드는 별도 출처(예: Spring Session reference의 쿠키 직렬화 옵션, server.servlet.session.cookie.same-site — Spring Boot 공식 문서, 또는 MDN Set-Cookie SameSite 사양)가 필요하다.
- BREACH 방어(C5)가 SameSite를 대체하거나 SameSite와 결합되어 동작한다는 명제.
- CookieCsrfTokenRepository가 생성하는 XSRF-TOKEN 쿠키의 SameSite 기본값 — 이 페이지의 코드 예제(CookieCsrfTokenRepository.withHttpOnlyFalse())는 SameSite 파라미터를 전혀 노출하지 않는다.
내 프로젝트(AP3 BFF)에 적용하려면 추가 확인이 필요한 것:
- 실제 세션 쿠키(JSESSIONID 등)와 XSRF-TOKEN 쿠키 각각에 SameSite 속성을 어떻게 지정할지는 Spring Session / CookieSerializer 또는 서블릿 컨테이너 설정 별도 확인 필요.
- Spring Boot server.servlet.session.cookie.same-site 프로퍼티(별도 Spring Boot 공식 문서)와 CookieCsrfTokenRepository의 관계 확인 필요 — 이 문서 범위 밖.

메모

검증되지 않은 내 해석. 사실 인용과 분리.

D3(CSRF 토큰 메커니즘)는 SPRINGSEC-CSRF-C3+C4 조합으로 충분히 뒷받침 가능해 보인다(미검증 — branch 작성 시 재확인).
D4(defense-in-depth: CSRF token + SameSite)는 이 자료만으로는 뒷받침 불가 — branch-spec 단계에서 SameSite 벤더 자료를 별도로 raw에 등록하거나, 근거 없이 작성 시 UNSUPPORTED_DECISION 라벨을 붙여야 한다(미검증 판단, 제안일 뿐).
추가로 봐야 할 동일 출처 페이지: docs.spring.io의 "CSRF Considerations"(서블릿 비특정 general 챕터), Spring Session reference의 쿠키 직렬화/SameSite 옵션 페이지, Spring Boot server.servlet.session.cookie.same-site 레퍼런스.

10 KiB Raw Blame History Unescape Escape