인프런 커뮤니티 질문&답변

이점이라기 보다는 상황에 따라 필요하면 사용해라는 의미로 받아들이시면 됩니다.

보안상 취약한 부분이 있더라도 불가피하게 쿠키를 사용해야 하는 상황이 발생할 수 있고 해당 리스크에 대한 대처를 별도로 한다면 사용할 수 있습니다.

시큐리티에서 여러 방식들을 제공하고 있다고 보시면 됩니다.

안녕하세요, 인프런 AI 인턴입니다. kyb1208tg님.

CSRF(Cross-Site Request Forgery) 공격을 방지하기 위해 스프링 시큐리티에서 제공하는 CookieCsrfTokenRepository 방식에 대한 질문을 주셨군요.

CSRF의 기초 개념:
CSRF 공격은 사용자의 브라우저가 자동으로 포함하는 쿠키 덕분에 발생할 수 있는 특정 유형의 공격입니다. 공격자는 사용자의 인증 정보와 관련된 요청을 자신이 만든 악의적인 사이트에서 유발하려고 합니다.

CookieCsrfTokenRepository 사용의 이유:
스프링 시큐리티는 CSRF 보호를 위해 다양한 전략을 제공합니다. CookieCsrfTokenRepository는 CSRF 토큰을 브라우저의 쿠키에 저장하여, 클라이언트가 이를 읽고 요청 헤더나 매개변수로 전달하게 합니다.

HttpOnly 속성과 보안:
HttpOnly 속성을 갖춘 쿠키는 자바스크립트를 통해 접근할 수 없으므로 XSS(Cross-Site Scripting) 공격에 대한 방어를 강화합니다. 하지만, 이 속성을 설정하지 않으면 해당 쿠키를 자바스크립트에서 접근할 수 있습니다. 이는 보안 측면에서 중요한 결정을 요구합니다.

CookieCsrfTokenRepository의 장점:
1. 간편한 설정: 많은 경우 이미 쿠키를 사용하고 있는 환경일 때, 손쉽게 CSRF 토큰을 추가할 수 있습니다.
2. 보안 강화 처리: 쿠키의 보안 속성(예: Secure, SameSite, HttpOnly 등)을 적절히 설정하고 관리할 수 있습니다.
3. 구현의 단순성: 세션을 다루는 것보다 쿠키를 통한 관리가 더 단순하게 적용될 수 있습니다.

하지만, 보안 취약점:
쿠키를 자바스크립트로 읽을 수 있도록 HttpOnly를 해제하면 XSS 공격에 노출될 위험이 높아집니다. 따라서, 이러한 설정은 매우 신중하게 다루어야 하며, XSS 공격에 대한 철저한 방어가 필요합니다.

대안:
1. HttpSessionCsrfTokenRepository: 세션을 통해 토큰을 관리함으로써 자바스크립트 접근을 완전히 차단하고 CSRF를 관리할 수 있습니다.
2. 헤더 기반 관리: 클라이언트가 세션을 통해 CSRF 토큰을 헤더에 포함시켜 전송하는 방식도 고려할 수 있습니다.

관련 질문과 답변을 확인할 수 있는 링크를 안내드립니다:
- CSRF token 질문
- REST 방식과 폼 인증 방식의 차이점과 언제 적용하는 질문입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.