Spring 미드레벨 보안 면접
새 면접Q. Spring 애플리케이션에서 XSS(Cross-Site Scripting) 공격과 CSRF(Cross-Site Request Forgery) 공격의 차이점을 설명하고, 각각의 공격을 방어하기 위해 Spring Security에서 제공하는 기본 방어 메커니즘과 추가로 고려해야 할 보안 설정들을 실무 관점에서 설명해주세요.
XSS는 악성 스크립트 주입, CSRF는 사용자 권한 도용이라는 공격 방식의 차이를 먼저 생각해보세요.
XSS는 악성 스크립트를 웹 페이지에 삽입하여 사용자 브라우저에서 실행시키는 공격이고, CSRF는 인증된 사용자의 권한을 악용해 의도하지 않은 요청을 서버에 전송하는 공격입니다. XSS 방어를 위해서는 Spring에서 Thymeleaf의 자동 이스케이프 기능을 활용하고, Content-Security-Policy 헤더를 설정하며, 사용자 입력값에 대한 검증과 sanitization을 수행해야 합니다. CSRF 방어를 위해 Spring Security는 기본적으로 CsrfFilter를 활성화하여 CSRF 토큰을 검증하며, SameSite 쿠키 속성을 설정하고 RESTful API의 경우 stateless 세션과 함께 커스텀 헤더 검증 방식을 사용할 수 있습니다. 또한 XSS 방어를 위해 HttpOnly와 Secure 플래그를 쿠키에 설정하고, CSRF 방어를 위해 Referer 헤더 검증을 추가로 고려할 수 있습니다.
- • XSS는 스크립트 주입, CSRF는 권한 도용이라는 공격 방식 차이
- • XSS 방어: 자동 이스케이프, CSP 헤더, 입력값 검증
- • CSRF 방어: CSRF 토큰, SameSite 쿠키, stateless API 설계
- • 추가 보안 설정: HttpOnly/Secure 쿠키, Referer 검증
게시판이나 댓글 시스템에서 사용자 입력을 처리할 때 XSS 방어가 필수적이며, 금융 거래나 개인정보 변경 API에서 CSRF 방어가 중요합니다.
RESTful API에서 JWT 토큰 기반 인증을 사용할 때 CSRF 방어가 필요한지, 필요하지 않다면 그 이유는 무엇인지 설명해주세요.
Q. Spring Security에서 사용자 비밀번호를 저장할 때 BCrypt를 사용하는 이유를 단순 해시 함수(MD5, SHA-256)와 비교하여 설명하고, BCrypt의 내부 동작 원리(salt, work factor)를 설명해주세요. 또한 대규모 서비스에서 로그인 성능과 보안성의 트레이드오프를 고려할 때 work factor를 어떻게 설정해야 하는지 실무 관점에서 설명해주세요.
Rainbow Table 공격과 brute force 공격에 대한 방어 메커니즘의 차이를 중심으로 생각해보세요.
MD5나 SHA-256 같은 단순 해시 함수는 동일한 입력에 대해 항상 같은 출력을 생성하므로 Rainbow Table 공격에 취약하고, 계산 속도가 빠르기 때문에 brute force 공격에도 취약합니다. BCrypt는 각 비밀번호마다 랜덤한 salt를 자동으로 생성하여 같은 비밀번호라도 다른 해시값을 만들어 Rainbow Table 공격을 방어하고, work factor(cost factor)를 통해 의도적으로 해싱 연산을 느리게 만들어 brute force 공격을 어렵게 만듭니다. work factor는 2의 n승 만큼 반복 연산을 수행하며, 일반적으로 10~12를 사용하는데 이는 약 0.1~0.3초의 해싱 시간을 의미합니다. 대규모 서비스에서는 로그인 성능을 고려하여 work factor 10을 기본으로 사용하되, 하드웨어 성능 향상에 따라 주기적으로 증가시키고, 민감도가 높은 관리자 계정은 더 높은 값을 사용하며, 비밀번호 변경 시점에 점진적으로 업그레이드하는 전략을 사용합니다.
- • 단순 해시는 Rainbow Table과 빠른 brute force에 취약
- • BCrypt는 자동 salt 생성과 느린 해싱으로 방어
- • work factor는 2^n 반복 연산으로 계산 비용 증가
- • 실무에서는 성능과 보안의 균형을 위해 10~12 사용, 점진적 업그레이드
회원가입 및 로그인 시스템에서 비밀번호를 안전하게 저장하고 검증하는 것은 가장 기본적이면서도 중요한 보안 요구사항입니다.
기존 시스템에서 MD5로 저장된 수백만 개의 비밀번호를 BCrypt로 마이그레이션해야 한다면 어떤 전략을 사용하시겠습니까?
Q. Spring Security에서 메서드 레벨 보안을 구현할 때 @PreAuthorize와 @Secured의 차이점을 설명하고, SpEL(Spring Expression Language)을 활용한 동적 권한 검증의 장점을 설명해주세요. 또한 다중 테넌트 환경에서 사용자가 자신이 속한 조직의 데이터만 접근할 수 있도록 보장하는 인가 로직을 구현할 때 고려해야 할 사항과 구현 방법을 설명해주세요.
정적 권한 검증과 동적 권한 검증의 차이, 그리고 도메인 객체 기반 접근 제어를 생각해보세요.
@Secured는 단순히 역할 이름 문자열만 검증할 수 있는 정적 방식이고, @PreAuthorize는 SpEL을 사용하여 복잡한 조건식과 메서드 파라미터를 활용한 동적 권한 검증이 가능합니다. SpEL을 활용하면 메서드 파라미터의 속성값이나 반환값을 검증할 수 있고, 커스텀 빈의 메서드를 호출하여 비즈니스 로직 기반 권한 검증이 가능하며, AND/OR 같은 복잡한 조건을 표현할 수 있습니다. 다중 테넌트 환경에서는 SecurityContext에서 현재 사용자의 조직 정보를 추출하고, @PreAuthorize에서 파라미터로 전달된 리소스의 조직 ID와 비교하는 방식으로 구현할 수 있습니다. 또한 커스텀 PermissionEvaluator를 구현하여 hasPermission 표현식으로 도메인 객체 레벨의 접근 제어를 수행하고, AOP를 활용하여 JPA 쿼리에 자동으로 조직 필터를 추가하는 방식도 고려할 수 있습니다.
- • @Secured는 정적 역할 검증, @PreAuthorize는 SpEL 기반 동적 검증
- • SpEL로 파라미터 검증, 커스텀 빈 호출, 복잡한 조건 표현 가능
- • 다중 테넌트는 SecurityContext의 조직 정보와 리소스 조직 ID 비교
- • PermissionEvaluator 구현과 AOP 기반 쿼리 필터링 활용
SaaS 서비스에서 여러 조직이 같은 시스템을 사용할 때 각 조직의 데이터를 격리하고 권한을 관리하는 것이 핵심 보안 요구사항입니다.
@PostAuthorize를 사용하는 경우는 언제이며, 성능상 어떤 문제가 있을 수 있는지 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!