[TIL] Spring Security

🙌🏻 Spring Security

 - Spring Framework 기반의 애플리케이션 인증과 인가 기능을 가진 프레임워크

 - 스프링 기반의 애플리케이션에서 보안을 위한 표준

 

 ① 모든 요청에 대해서 인증을 요구함

 ② 사용자 이름 및 암호를 가진 사용자가 양식 기반으로 인증할 수 있도록 허용

 ③ 사용자의 로그아웃을 허용

 ④ CSRF 공격을 방지

 ③ 세션 고정 공격 : Session Fixsation을 보호

  - Session Fixsation? 공격자가 자신의 세션 id를 다른 사용자에게 줌으로써 공격하는 방법

⑥ 보안 헤더 통합

  -  HSTS 강화

  - X-Content-TypeOptions

  -  캐시 컨트롤러 : 정적 리소스 캐싱

  - X-XSS-Protection XSS 보안 (스크랩트 공격 보안)

  - 클릭재킹을 방지하는 X-Frame 옵션 통합

   → 클릭 재킹?

       - 웹 사용자가 자신이 클릭하고 있다고 인지하는 것과 다른 어떤 것을 클릭하게 속이는 악의적인 기법

       - 공격자는 비밀 정보를 유출시키거나 그들의 컴퓨터에 대한 제어를 획득할 수 있게 됨

⑦ Servlet API 제공

---

💡주체 Principal

  - 유저, 기기, 시스템 등이 될 수 있지만 보통 유저, 사용자를 의미

💡인증 : Authentication

 - 특정 리소스에 접근하려고 하는 사용자가 누구인지 확인할 때 사용

 - 주체의 신원을 증명하는 과정

    - 주체는 자신을 인증해달라고 신원 증명 정보 제시

    - 주체가 유저일 경우 신원 증명 정보는 패스워드

💡인가  =  권한 부여 : Authorization 

  - 인증을 마친 유저에게 권한을 부여하여 애플리케이션의 특정 리소스에 접근할 수 있게 허가하는 과정

  - 인가는 반드시 인증 과정 이후 수행되어야 하며 권한은 롤 형태로 부여하는 것이 일반적

💡접근 통제 : Access Control

  - 어떤 유저가 애플리케이션 리소스에 접근하도록 허락할지 제어하는 행위

  - 리소스의 접근 속성과 유저에게 부여된권한 또는 다른 속성들을 결정

---

📍HttpSecurity 객체 

 - 몇 가지 HTTP 보안 관점을 설정하기 위해 사용

 ▸ authorizeRequests( ) 

  - 이 호출로 반환되는 객체로 호출되는 메소드들의 요청 보안 수준 세부적인 설정

 ▸ antMatchers("경로").authenticated( )

  - 지정된 경로로 호출된 요청은 인증이 되어야 함을 의미

  - antMatchers는 권한 관리 대상을 지정함

 ▸ antMatchers("경로").access(String)

  - 주어진 SpEL 표현식의 평가 결과가 true 이면 접근 허용

  - SpEL은 access( )를 사용할 때 접근 요구 사항을 선언하기 위한 수단으로 사용

  - hasRole()은 스프링 시큐리티에서 지원되는 보안 특성 표현

 ▸ anyRequest( ).permitAll( )

  - 지정한 요청들을 제외한 다른 요청들은 인증이나 권한 없이 허용

---

▪️ http.csrf( ).disable( )

- 서버에 인증정보를 저장하지 않기 때문에 굳이 불필요한 csrf 코드들을 작성하지 않음

---

▪️ http.headers( ).frameOptions( ).disable( )

- h2 Consle 화면을 사용하기 위해 Frame 옵션을 disable 함

---

📍 WebMvcConfigurer을 상속하는 이유

- @EnableWebMvc가 자동적으로 세팅해주는 설정에 개발자가 원하는 설정 추가 가능

 ▸ @EnableWebMvc

  - Spring MVC 를 구성할 때 필요한 Bean 설정들을 자동으로 해주는 어노테이션

---

📍 PasswordEncoder 인터페이스

- encode( )는 실제로 패스워드 암호화할 때 사용

- matchers( )는 사용자에게 입력받은 패스워드를 비교하고자 할 때 사용

---

▪️ BCryptPasswordEncoding

- 스프링 시큐리티 프레임워크에서 제공하는 클래스 중 하나로 비밀번호를 암호화하는데 사용할 수 있는 메서드를 가진 클래스

- BCrypt 해싱 함수를 사용해서 비밀번호를 인코딩해주는 메서드와

     사용자에 의해 제출된 비밀번호와 저장소에 저장된 비밀번호의 일치 여부를 확인해주는 메서드를 제공

- 단순히 해시를 하는 것 뿐만 아니라 Salt를 넣는 작업까지 하므로

  입력 값이 같음에도 불구하고 매번 다른 encoded 된 값을 return 해줌

- encode( ) 메서드 : 패스워드를 암호화해주는 메서드

---

▪️ DelegatingPasswordEncoding

- PassWordEncoder을 여러 개 선언한 뒤 상황에 맞게 골라쓸 수 있도록 지원하는 Encoder

String idForEncode = "bcrypt";
Map encoders = new HashMap<>();
encoders.put(idForEncode, new BCyptPasswordEncoder());
encoders.put("noop", NoOpPasswordEncoder.getInstance());
encoders.put("pbkdf2", new Pbkdf2PasswordEncoder());
encoders.put("scrypt", new SCyptPasswordEncoder());
encoders.put("sha256", new StandardPasswordEncoder());

PasswordEncoder passwordEncoder = new DelegatingPasswordEncoder(idForEncode, encoders);

  - 위와 같이 선언하면 bcrypt, noop, pbkdf2, scrypt, sha256이 encoders 안에 들어가게 됨

  - 마지막에 선언했을 때 idForEncode를 bcypt로 주었으니 최종으로 encoding 되는 값은

     bcypt로 해싱 된 패스워드가 리턴 되며 맨 앞에 prefix로 암호화한 방법이 붙음

  * 장점 *

   - 비밀번호를 현재 권장하는 저장방식으로 인코딩함을 보장함

   - 비밀번호 검증은 최신 형식과 레거시 형식을 모두 지원

   - 나중에 인코딩 변경 가능

---

▪️ SCryptPasswordEncoder

- Scrypt 해시 함수를 사용하고 추가적으로 cpu와 memory의 cost 파라미터를 넘길 수 있음

  - Scrypt는 실제로 Salsa20이라는 해싱 방식 사용

---

🙌🏻 Filter와 FilterChain

 📍 Filter Interface

  - FIlter ? HTTP 요청과 응답을 변경할 수 있는 재사용 가능한 코드

  - 필터를 설정하는 FilterConfig 객체, FilterChain 객체, Filter 객체 필요

  - FilterConfig와 FilterChain을 상속받은 클래스들은 웹컨테이너가 구현해줌

  - Filter 인터페이스는 init(), doFilter(), destory() 메소드 필요

public class FirstFilter implements Filter {
	public void init(FilterConfig filterConfig) throws ServletException {
    	//필터의 초기화 작업
    }
    
    public void doFilter(ServletRequest request,
    					 ServletResponse response,
                         FilterChain chain)
                         throws IOException, ServletException {
         //request 파라미터를 이용하여 요청의 필터 작업 수행
         //체인의 다음 필터 처리                         
       chain.doFilter(request, response);
         //response를 이용하여 응답의 필터링 작업 수행       	
    }
    
   public void destory() {
     //주로 필터가 사용한 자원을 반납
   }
 }

  ① init(FilterConfig config)

   - 서블릿 컨테이너가 필터 인스턴스를 초기화하기 위해서 호출하는 메서드

  ② doFilter(ServletRequest resquest ServletResponse response, FilterChain chain)

   - 필터에서 구현해야 하는 로직을 작성하는 메소드

  ③ destory() : void

  - 필터 인스턴스를 종료시키기 전에 호출하는 메소드

---

 📍 FilterChain

   - 여러 개의 필터들이 사슬처럼 연결되어 있고 서로 연결되어 동작

   - 클라이언트가 앱에 요청을 보내고 컨테이너는 요청 URI의 경로를 기반으로 어떤 필터와 서블릿을 적용할지 결정

   - 하나의 서블릿은 단일 요청 처리

   - 필터는 체인을 형성하여 순서를 지정하며 실제로 요청 자체를 처리하는 경우 필터가 나머지 체인 거부 가능

   - 필터는 필터체인을 통해 여러 필터가 연쇄적으로 동작하게 할 수 있음

   - 1개의 서블릿이 HttpServletRequest와 HttpServletResponse 처리 담당

---

  ▪️ Filter Chain 순서

   ① @Order or Ordered 구현

    - Filter 타입의 @Beans에 @Order를 붙이거나 Orderd룰 구현함

   ② FilterRegistrationBean

   - API의 일부로 순서를 가지는 FilterRegistrationBean의 일부가 됨

---

💡 서블릿 : Servlet

 - 동적 웹 페이지를 만들 때 사용되는 자바 프로그래밍 기술

   = 웹 서버로 웹 페이지를 제공할 때 동적인 데이터를 제공하는 것을 도와줌

 - 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해줌

 - 서버가 클라이언트에서 입력되는 아이디와 비번을 확인하고 결과를 응답해주는 역할 수행

💡 서블릿 필터 : Servlet Filter

 - 서블릿이 호출되기 전, 후로 공통 로직을 수행하는 역할

 - 공통적인 기능들을 서블릿이 호출되기 전에 수행하거나 호출된 후 수행하게 하고 싶을 때 서블릿 필터로 구현

 

---

 📍 DelegatingFilterProxy

  - 스프링 시큐리티가 모든 애플리케이션 요청을 감싸게 해서 모든 요청에 보안이 적용되게 하는 서블릿 필터

  - DelegatingFilterProxy라는 필터구현체로 서블릿 컨테이너와 스프링 컨테이너 연결

    → 서블릿 컨테이너는 Filter 등록이 가능하지만 스프링이 정의하는 Bean을 인식하지는못함

  - 모든 처리를 Filter를 구현한 스프링 빈으로 위임해줌

  - 서블릿 필터로 Spring IOC 컨테이너가 관리하는 Filter Bean을 가지고 있음

---

 📍 FilterChainProxy

  - SecurityFilterChain을 통해 여러 Filter 인스턴스로 위임 가능

  - FilterChainProxys는 빈이기 때문에 보통 DelegatingFilterProxy로 감싸져 있음

---

① FilterChain에서 여러 Filter를 적용할 수 있음

② Filter 실행 중 Delegating FilterProxy가 존재할 수 있음

  - DelegatingFilterProxy 내부에 있는 Bean Filter는 FilterChainProxy가 됨

③ SecurityFilterChain은 FilterChainProxy로 등록됨

④ 여러 개의 SecurityFilterChain이 있을 때 어떤 것을사용할지는 FilterChainProxy가 결정

  - 가장 먼저 매칭한 SecurityFilterChain을 실행