서론
스터디를 개설하였고 이번 발표 주제로 GPT에게 추천 받아 아래 열개의
-
Spring Framework 시작하기: Spring Framework의 기본적인 구조와 그것을 사용하는 이유에 대한 설명.
-
Maven과 Gradle: 자바 프로젝트 관리 도구로서 Maven과 Gradle의 기본 개념 및 사용법.
-
기본적인 REST API 만들기: 자바와 Spring Boot를 사용하여 간단한 REST API를 만드는 방법 소개.
-
JDBC (Java Database Connectivity) 기초: 데이터베이스 연결과 CRUD 작업을 위한 JDBC의 기본 사용법.
-
자바에서의 예외 처리: try-catch, throw 및 사용자 정의 예외를 포함한 자바 예외 처리의 기본.
-
Spring Boot와 Thymeleaf를 활용한 웹 페이지 렌더링: 백엔드 데이터를 프론트엔드에 표시하는 간단한 예제 소개.
-
자바에서의 로깅의 기초: log4j, SLF4J와 같은 로깅 프레임워크의 기본 사용법 및 로그의 중요성에 대한 설명.
-
자바와 JSON: JSON 데이터를 처리하기 위한 자바 라이브러리 (예: Jackson)의 사용법.
-
Spring Security의 기본: 사용자 인증 및 인가를 위한 Spring Security의 간단한 설정 및 기본 원칙.
-
자바 백엔드 개발의 소개: 백엔드의 역할, 자바를 사용하는 이유와 장점 등 기본적인 개념 소개.
중에 하나씩 각자 하기로 했다
나는 그중에서도 Security를 하였다
자료가 방대하기 때문에 간단하게 자료구조만 조금 설명하도록함
스프링 시큐리티란?
자바/스프링 기반의 애플리케이션에 보안 기능을 추가하는 프레임워크
주로 인증과 권한 부여에 관련된 기능등을 제공한다.
주요 기능과 특징
1. 인증(Authentication)
사용자가 누구인지 확인하는 과정 일반적으로 아이디 또는 이멜과 비밀번호를 통해 이루어지며, LDAP,OAuth,JWT 등 당양한 인증 방식을 지원합니다.
2. 권한 부여(Authorization)
인증된 사용자가 어떤 리소스에 접근하거나 어떤 작업을 수행할 수 있는지를 결정함
예를 들어 관리자만이 특정 페이지에 접글할 수 있도록 할 수 있음
3. 세션 관리
사용자가 시스템에 로그인한 상태를 유지하고 관리하는 기능을 제공함
4. 암호화
패스워드나 중요 정보를 안전하게 저장하고 전송하기 위한 암호화 기능을 지원함.
5. CSRF 방지
잠깐 CSRF란
Cross-Site Request Forgery의 약자로
사이트 간 요청 위조의 줄임말.
웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 해서 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법이다. 2008년에 발생한 옥션의 개인정보 유출 사건에서도 관리자 계정을 탈취하는 데 이 방법이 사용되었다. 공격의 난이도가 높지 않아 흔히 사용된다.
스프링 시큐리티는 이러한 CSRF를 방지해준다
자료구조
A Review of Filters
Spring Security의 서블릿 지원은 서블릿 필터를 기반으로 한다
필터의 역할을 일반적으로 먼저 살펴보자
다음 이미지는 단일 HTTP 요청에 대한 핸들러의 일반적인 계층화를 보여줌
클라이언트가 애플리케이션에 요청을 보내면 컨테이너는 요청 URI의 경로를 기반으로 HttpServletRequest를 처리해야 하는 필터 인스턴스와 서블릿을 포함하는 FilterChain을 생성함
Spring MVC 애플리케이션에서 서블릿은 DispatcherServlet의 인스턴스
하나의 서블릿은 최대 하나의 HttpServletRequest 및 HttpServletResponse를 처리할 수 있습니다. 그러나 둘 이상의 필터를 사용할 수 있음
- 다운스트림 필터 인스턴스 또는 서블릿이 호출되지 않도록 합니다. 이 경우 필터는 일반적으로 HttpServletResponse를 작성함
- 다운스트림 필터 인스턴스 및 서블릿에서 사용하는 HttpServletRequest 또는 HttpServletResponse를 수정함
DelegatingFilterProxy
Spring은 서블릿 컨테이너의 라이프사이클과 Spring의 ApplicationContext 사이를 연결 할 수 있는 DelegatingFilterProxy라는 필터의 구현을 제공함
서블릿 컨테이너는 자체 표준을 사용하여 필터 인스턴스를 등록할 수 있지만 Spring이 정의한 Bean은 인식하지 못함
표준 서블릿 컨테이너 메커니즘을 통해 DelegatingFilterProxy를 등록 할 수 있지만 모든 작업은 Filter를 구현하는 Spring Bean에 위임됨
다음은 DelegatingFilterProxy가 필터 인스턴스와 필터 체인에 어떻게 적용되는지 보여주는 그림
DelegatingFilterProxy는 ApplicationContext에서 Bean Filter0을 조회한 다음 Bean Filter0을 호출함 다음 목록은 DelegatingFilterProxy의 의사 코드를 보여줌
DelegatingFilterProxy 예제 코드
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
Filter delegate = getFilterBean(someBeanName); // 1
delegate.doFilter(request, response); // 2
}- Spring Bean으로 등록된 필터를 Lazily 하게 가져옴 DelegatingFilterProxy의 예제에서 델리게이트는 Bean Filter0의 인스턴스
- Spring Bean에게 작업을 위임함
DelegatingFilterProxy의 또 다른 장점은
Filter Bean 인스턴스 조회를 지연시킬 수 있다는 점
이는 컨테이너가 시작되기 전에 필터 인스턴스를 등록해야하 하기 때문에 중요함
그러나 Spring은 일반적으로 ContextLoaderListener를 사용하여 Spring Bean을
로드하는데 이 작업은 Filter 인스턴스를 등록한 후에 수행되어야함
FilterChainProxy
Spring Security의 서블릿 지원은 FilterChainProxy에 포함되어 있음
FilterChainProxy는 SpringSecurity에서 제공하는 특수 필터로
SecurityFilterChain을 통해 많은 Filter 인스턴스에 위임할 수 있음
FilterChainProxy는 Bean이기 때문에 일반적으로 DelegatingFilterProxy로 래핑됨
SecurityFilterChain
SpringFilterChain은 현재 요청에 대해 호출해야 하는 SPring보안 필터 인스턴스를 결정하기 위해 FilterChainProxy에서 사용됨
SecurityFilterChain의 보안 필터는 일반적으로 Bean이지만
DelegatingFilterProxy가 아닌 FilterChainProxy에 등록됨
FilterChainProxy는 서블릿 컨테이너나 DelegatingFilterProxy에 직접 등록하는 것보다 여러가지 이점을 제공함
-
Spring Security의 모든 서블릿 지원을 위한 시작점을 제공함 따라서 Spring Security의 서블릿 지원 문제를 ㅐ결하려는 경우 FilterChainProxy에 디버그 지점을 추가하는 것이 좋음
-
FilterChainProxy는 Spring Security 사용의 핵심이므로 선택 사항으로 간주 되지 않은 작업을 수행할 수 있음 예를 들어 메모리 누수를 방지하기 위해 SecurityContext를 지움 또한 특정 유형의 공격으로부터 애플리케이션을 보호하기 위해 SPring Security의 HttpFirewall을 적용함
또한 SecurityIlterChain을 호출해야 하는 시기를 보다 유연하게 결정 할 수 있음 서블릿 컨테이너에서 필터 인스턴스는 URL만을 기반으로 호출됨 그러나 FilterChainProxy는 RequestMatcher인터페이스를 사용하여 HttpServletRequest의 모든 것을 기반으로 호출을 결정할 수 있음
Multiple SecurityFilterChain 그림에서 FilterChainProxy는 어떤 보안 필터 체인을 사용할지 결정함 칠히나는 첫번째 SecurityFilterChain만 호출 됩니다.
만약 /api/messages/의 URL이 요청되면 /api/의 SecurityFilterChain 0 패턴에서 가장 먼저 일치함 그러므로 SecurityFilterChain n에서 일치하더라도
SecurityFilterChain 0만 호출됨
messages/의 url이 요청되면 /api/의 SecurityFilterChain0 패턴에서 일치하지 않으므로 FilterChainProxy는 각 SecurityFilterChain을 계속 시도합니다. 일치하는 다른 SecurityFilterChain인스턴스가 없다고 가정하면 SecurityFilterChain n이 호출됨
SecurityFilterChain 0 에는 세 개의 보안 필터 인스턴스만 구성되어 있음
그러나 SecurityFilterChain n 에는 4개의 보안 필터 인스턴스가 구성되어 있음
각 SeucrityFilterChain은 고유할 수 있으며 개별적으로 구성할 수 있다는 점에서 유의해야함 실제로 애플리케이션에서 Spring Seucrity가 특정 요청을 무시하기를 원하는 경우 SecurityFilterChain에는 보안 필터 인스턴스가 0개일 수 있음
우선은 여기까지만
