donghyeon.kang/llm-wiki

Fork 0

Files

T

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

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

10 KiB

Raw Permalink 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 / OWASP Cross-Site Request Forgery Prevention Cheat Sheet — SameSite Defense-in-Depth

Layer: raw/official-docs/ — OWASP Cheat Sheet Series "Cross-Site Request Forgery Prevention Cheat Sheet" 페이지의 원문 발췌. feature-keycloak-bff-csrf-samesite-defense branch 의 D3(SameSite 를 CSRF token 의 대체가 아닌 defense-in-depth 보완으로 결합) 결정 근거로 보관. OWASP Cheat Sheet Series 는 특정 벤더 제품 문서가 아니라 산업 전반의 벤더 중립 공식 보안 레퍼런스이므로 source_type: official-doc (company-tech-blog 아님).

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-bff-csrf-samesite-defense	D3 — SameSite 쿠키 속성을 CSRF token(D2, `csrf-protection-spring-official` 근거)의 대체가 아닌 defense-in-depth 보완으로 결합하는 프레이밍의 공식 근거. 세션 쿠키에 SameSite 적용 권고, Lax/Strict trade-off, synchronizer token 이 1차 방어라는 근거 포함 — 기존 `D3 UNSUPPORTED_DECISION` 라벨 해소용

출처

원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
아카이브 URL: (미수집)
저자 / 조직: OWASP (Open Worldwide Application Security Project) Cheat Sheet Series — 벤더 중립 커뮤니티 보안 레퍼런스 (GitHub 기반 협업 편집, 다수 리뷰어)
발행일: 고정 발행일 없음 (rolling living document)
마지막 확인일: 2026-07-25

왜 저장했는지

branch 의 D3(SameSite 를 CSRF token 의 defense-in-depth 보완으로 결합)이 UNSUPPORTED_DECISION 상태였다 — 기존 유일한 근거(csrf-protection-spring-official)는 SameSite 를 전혀 언급하지 않기 때문. 이 문서는 SameSite 를 "does not replace a proper CSRF defense" 로 명시적으로 프레이밍하고, 세션 쿠키 적용 시 주의사항·Lax/Strict trade-off·synchronizer token 이 1차 방어라는 근거를 제공해 D3 를 뒷받침한다.

핵심 인용

[§Limitations of SameSite] "SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments."

[§Introduction] "SameSite Cookie Attribute can be used for session cookies but be careful to NOT set a cookie specifically for a domain."

[§SameSite (Cookie Attribute)] "If a website wants to maintain a user's logged-in session after the user arrives from an external link, SameSite's default Lax value provides a reasonable balance between security and usability."

[§Limitations of SameSite] "Top-level navigation and window-opening tricks. [...] SameSite=Strict blocks most of these at the cost of breaking legitimate cross-site links into the app."

[§Token-Based Mitigation] "The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF."

Claims Extracted (추출된 주장)

Claim ID prefix: OWASP-CSRF-SAMESITE.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
OWASP-CSRF-SAMESITE-C1	SameSite 는 defense-in-depth 통제이며 대부분의 배포 환경에서 적절한 CSRF 방어를 대체하지 않는다	[§Limitations of SameSite] "SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments."	`official-reference`	SameSite 단독 배포가 CSRF 방어로 충분한지 판단하는 일반 아키텍처 가이드	어떤 특정 프레임워크(Spring 등)의 실제 SameSite 기본값/런타임 동작을 증명하지 않음 — 이 branch 의 AP3 세션 쿠키가 실제로 어떤 SameSite 값을 갖는지는 별도 확인 필요
OWASP-CSRF-SAMESITE-C2	SameSite 쿠키 속성은 세션 쿠키에 적용 가능하나, 특정 도메인에 한정해서 설정하지 않도록 주의해야 한다(서브도메인 쿠키 공유 위험)	[§Introduction] "SameSite Cookie Attribute can be used for session cookies but be careful to NOT set a cookie specifically for a domain."	`official-reference`	SameSite 를 세션 쿠키(D3 가 적용 대상으로 고려하는 쿠키)에 적용하는 일반 권고	이 branch 의 실제 세션 쿠키 도메인 설정이 이 위험에 해당하는지는 이 문장만으로 증명되지 않음 — 프로젝트별 도메인 구성 확인 필요
OWASP-CSRF-SAMESITE-C3	외부 링크를 통한 로그인 세션 유지가 필요한 경우, SameSite 의 기본값인 Lax 가 보안과 사용성 사이의 합리적 균형을 제공한다	[§SameSite (Cookie Attribute)] "If a website wants to maintain a user's logged-in session after the user arrives from an external link, SameSite's default Lax value provides a reasonable balance between security and usability."	`official-reference`	Lax vs Strict 선택 기준 — 외부 링크 진입이 필요한 애플리케이션의 경우 Lax 선택 근거	Lax 가 모든 CSRF 벡터를 차단한다는 것은 증명하지 않음(GET 기반 state-changing 우회 가능성은 이 문서의 별도 문단이 다룸, 이 claim 의 범위 밖)
OWASP-CSRF-SAMESITE-C4	SameSite=Strict 는 top-level navigation/새 창 열기를 통한 공격 대부분을 차단하지만, 정상적인 cross-site 링크 진입을 깨뜨리는 비용(UX trade-off)이 있다	[§Limitations of SameSite] "SameSite=Strict blocks most of these at the cost of breaking legitimate cross-site links into the app."	`official-reference`	Strict 채택 시 예상되는 UX 트레이드오프 근거 — 외부 링크 진입이 불필요한 애플리케이션에서 Strict 채택 근거	이 branch(AP3, keycloak IdP 리다이렉트 흐름 포함)가 외부 링크 진입에 의존하는지 여부는 이 문장이 판단하지 않음 — OIDC redirect flow 와 Strict 의 상호작용은 별도 검증 필요
OWASP-CSRF-SAMESITE-C5	synchronizer token pattern 은 CSRF 를 완화하는 가장 널리 쓰이고 권장되는 방법 중 하나다	[§Token-Based Mitigation] "The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF."	`official-reference`	CSRF token(D2, 이미 `csrf-protection-spring-official` 로 별도 근거 확보)이 1차 방어이고 SameSite 는 그 보완이라는 D3 의 "combine, don't replace" 프레이밍 근거	Spring Security 의 특정 구현(synchronizer token + `CookieCsrfTokenRepository`)이 이 일반 권고를 만족하는지는 이 문장 자체가 증명하지 않음 — 그 부분은 `csrf-protection-spring-official`(`SPRINGSEC-CSRF-C3`)이 별도로 증명

Usage Boundaries (적용 경계)

이 자료가 직접 증명하는 것:
- OWASP-CSRF-SAMESITE-C1: SameSite 는 defense-in-depth 이며 CSRF 방어의 대체가 아니라는 일반 원칙
- OWASP-CSRF-SAMESITE-C2: 세션 쿠키에 SameSite 적용 시 서브도메인 공유 주의사항
- OWASP-CSRF-SAMESITE-C3: Lax 가 외부 링크 진입 시나리오에서 보안·사용성 균형을 제공한다는 일반 권고
- OWASP-CSRF-SAMESITE-C4: Strict 채택 시 예상되는 UX 트레이드오프
- OWASP-CSRF-SAMESITE-C5: synchronizer token pattern 이 CSRF 완화의 대중적·권장 방법이라는 일반 진술
이 자료가 증명하지 않는 것:
- Spring Security(D2) 의 실제 CookieCsrfTokenRepository/XSRF-TOKEN 쿠키가 어떤 SameSite 값을 기본으로 갖는지 — 이 문서는 벤더 중립 일반 가이드이며 Spring 구현 세부는 다루지 않음(csrf-protection-spring-official 범위)
- AP3(BFF) 의 실제 세션 쿠키가 어떤 도메인/SameSite 조합으로 배포될지 — 코드 미구현(NO_GROUND_TRUTH)이라 이 문서만으로 확정 불가
- Lax 냐 Strict 냐의 최종 선택 — 이 문서는 트레이드오프만 제시하며 이 branch 의 OIDC redirect 흐름(keycloak IdP 경유)과의 상호작용까지 판단하지 않음
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- AP3 세션 쿠키(server.servlet.session.cookie.same-site)와 XSRF-TOKEN 쿠키(CookieCsrfTokenRepository) 중 어느 쪽에 SameSite 를 적용할지 — branch §구현 가이드의 UNSUPPORTED_IMPL_DECISION(a) 로 남아 있으며 이 문서만으로 결정 불가(Applies to 범위 밖)
- keycloak OIDC 로그인 리다이렉트가 top-level navigation 인지, 그 경로가 Strict 채택 시 깨지는지 실제 흐름으로 검증 필요

메모

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

D3 는 OWASP-CSRF-SAMESITE-C1+C5 조합("SameSite 는 보완이고 synchronizer token 이 1차 방어")으로 "combine, don't replace" 프레이밍이 뒷받침 가능해 보인다(미검증 — branch 갱신 시 재확인).
SameSite 적용 대상(세션 쿠키 vs XSRF-TOKEN 쿠키)과 Lax vs Strict 값 선택은 이 문서가 원칙만 제공하고 detail 은 권고하지 않으므로, branch §구현 가이드의 UNSUPPORTED_IMPL_DECISION 라벨이 계속 유효하다(이 문서로 해소되는 것은 D3 의 "왜 결합하는가" 부분이지 "어디에 어떤 값으로" 부분이 아님).
추가로 봐야 할 동일 출처 페이지: 같은 페이지의 "Using Standard Headers to Verify Origin" 섹션(Origin/Referer 검증), Spring Session reference 의 쿠키 직렬화 옵션 페이지(SameSite 적용 대상 detail 확정 시 필요).

10 KiB Raw Permalink Blame History