[Java Project] SpringSecurity - SecurityWebConfig 설정 잘 하기

Erin Lee·2024년 3월 13일

Project

목록 보기

5/7

SpringSecurity를 사용하면 SpringSecurity 설정을 해주는 SecurityWebConfig 파일을 만지게 될 것이다.
SecurityWebConfig 파일에서 기본적으로 제공하는 기능들이 있고 그 기능들은 프로젝트에 맞게 설정해야한다.
그래서 하나씩 살펴봤다.

Security Web Config

클라이언트로부터 오는 모든 요청 URL이 거치게 되는 클래스로써 스프링 시큐리티에 대한 설정을 담당하여 요청 URL이 설정된 셋팅을 거치게 하여 시큐리티 보안이 적용되게 한다.

Spring Security Filter 설정
요청 메세지 처리
세션 처리
필터 처리

→ 스프링 시큐리티를 사용하면 웹 컨테이너 필터에 스프링 시큐리티 필터가 끼워지면서 요청 메세지에 대한 보안 설정이 이루어지는 것인데 그 스프링 시큐리티 필터의 HTTP 요청에 대한 설정도 해당 클래스에서 이뤄진다.

해당 클래스를 통해 적용된 설정이 모든 요청 메세지에 적용될 수 있도록 다음 어노테이션을 추가해줘야한다.

@EnableWebSecurity

EnableWebSecurity 어노테이션은 스프링 시큐리티의 보안을 활성화 시킨다.
클라이언트로부터 서버로 URL 요청이 들어오면 EnableWebSecurity 클래스를 먼저 거쳐 설정된 스프링 시큐리티 보안 절차를 밟게 된다.

SecurityFilterChain

스프링 시큐리티를 사용하면 요청 메세지가 디스패처 서블릿으로 넘어오기 전에 스프링 시큐리티 필터를 거치게 된다.

해당 시큐리티 필터에서 Http 요청에 대한 보안 처리가 될 수 있도록 설정해줘야 한다.

WebSecurity

WebSecurity 클래스는 HttpSecurity의 상위 클래스로 WebSecurity로 들어온 요청 메세지는 스프링 시큐리티 필터를 거치지 않는다.
→ 스프링 시큐리티가 제공하는 인증, 인가 기능이 적용되지 않는다.
→ 인증, 인가 기능이 필요하지 않은 모든 접근자가 사용할 수 있는 URL 요청에 적용한다.

HttpSecurity

HTTP 요청에 대한 스프링 시큐리티 설정을 할 수 있게 하는 객체로 요청에 대한 보안 설정을 지원한다.
요청에 대한 보안 설정을 해줌으로써 접근에 제한을 둘 수 있다.
→ 보안 설정이 필요한 URL 요청인 경우 사용된다.

(출처:https://catsbi.oopy.io/c0a4f395-24b2-44e5-8eeb-275d19e2a536)

CSRF(Cross Site Request Forgery)

CSRF란 사용자가 의도치 않게 악의적인 요청을 보내게 하는 공격 방식을 말한다.

어느 경우일까?
사용자가 은행과 같이 인증이 필요한 사이트에서 인증 후 로그아웃되지 않은 상태에서 화면이 완전히 동일한 악의적인 웹사이트를 접속하게 유도한다.
사용자는 악의적인 사이트인지 모르고 업무를 보기위해 요청을 보내고 해당 요청은 악의적인 사이트에서 심어진 내용이 들어간 상태에서 서버까지 전송이 되어버린다.
즉, 위조된 요청을 보내어 공격을 한다. 이때 악의적으로 보내는 요청은 기존 정상적인 요청과 동일하게 생겼기 때문에 구분하는 것이 매우 어렵다.

CSRF를 막는 방법

CSRF 토큰
HTTP 요청 메세지에 CSRF 토큰을 심어 서버로 들어온 요청 메세지가 정상적인 메세지인지 구분하는 방식이다.
HTTP 요청이 오면 서버는 예상 CSRF 토큰을 찾아 실제 CSRF 토큰과 비교를 하고 일치하지 않으면 요청을 거부한다.

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

위와 같이 요청 메세지에 csrf 토큰에 대한 정보가 들어가있다.

SameSite 쿠키 속성 정보 설정
SameSite 쿠키란 웹 브라우저에 의해 처리되는 HTTP 쿠키이다.
쿠키는 웹 브라우저간의 상태 정보를 유지하기 위해 사용되며 쿠키 안에 세션, 사용자 인증 등에 대한 정보가 저장되어있다.
이러한 쿠키가 어떻게 취급되어야하는지에 대한 속성을 SameSite 쿠키를 통해 설정할 수 있다.
None : 쿠키가 어떠한 설정 없이 모든 사이트에 전송될 수 있는 속성
Lax : 타사 사이트 요청에 대해선 쿠키를 전송할 수 없는 속성
Strict : 타사 사이트 요청에 대해 전송되지 않도록 하는 속성 → 본 사이트의 요청에만 쿠키가 전송되는 설정

SameSite 설정을 Strict로 해놓는다면 위조된 사이트로부터 요청이 들어올 때 쿠키가 담겨있지 않게 됨으로써 공격을 막을 수 있다.

스프링 시큐리티에서는 이러한 CSRF 공격을 막기위한 기능을 제공하는데 위에 방법 중 CSRF 토큰 인증 방식을 사용한다.

기본적으로 CSRF 설정은 활성화되어있다.

결론

⇒ Daily Project에서는 사용자의 정보를 JWT에 담아 보내기 때문에 CSRF 공격이 일어날 일도 없으며 요청 메세지에는 CSRF 토큰을 확인할 수 없다.
그렇기 때문에 보안 기능이 적용될 일이 없기 때문에 disable() 처리하였다.

CSRF 공격에 대해 고려해야할 작업

로그인, 로그아웃 작업
요청 메세지를 통해 사용자에 대한 인증, 인가 처리가 필수적으로 필요한 작업이다.
공격자가 사용자의 권한을 취득해 위조 로그인을 하여 CSRF 공격함으로써 정보가 누출되어버린다.
파일 업로드
CSRF 공격을 막기 위해선 HTTP 요청 본문을 읽어 CSRF 토큰을 얻어야하는데 본문을 읽기 위해선 파일을 업로드해야한다.
→ 악의적인 사이트에서 보낸 잘못된 파일이 업로드가 될 수 있다.
이러한 경우에는 파일 업로드 요청 전 CSRF 토큰을 검증하는 다른 요청을 먼저 보냄으로써 처리하거나 임시적으로 파일을 업로드하거나 CSRF 토큰이 확인되면 실제 서버에 파일 업로드를 시키는 방법 등이 있다.

HTTP Basic Authentication

http basic 보안 방식은 클라이언트와 서버의 요청과 응답 메세지의 헤더를 사용하여 인증 정보를 전송하는 방식이다.

Http Basic 인증 방식

클라이언트가 서버에 요청을 보낸다.
서버는 해당 요청에 인증이 필요한지 확인한다.
인증이 필요한 경우 서버는 "WWW-Authenticate" 헤더를 응답으로 클라이언트에게 보낸다.
이 헤더에는 인증 방법이 "Basic"임을 알려주고, 클라이언트에게 사용자 이름과 비밀번호를 요구한다.
클라이언트는 사용자 이름과 비밀번호를 Base64로 인코딩하여 "Authorization" 헤더에 담아 다시 서버에 요청을 보낸다.
서버는 "Authorization" 헤더에서 사용자 이름과 비밀번호를 추출하여 사용자를 인증한다.
만약 인증에 성공하면, 서버는 해당 요청에 대한 응답을 클라이언트에게 반환.
인증에 실패하면, 서버는 401 Unauthorized 응답을 반환.

Http Basic 인증 방식은 Base64 인코딩 방식만 사용할 뿐 암호화 작업은 따로 처리하지 않는다.

그렇기 때문에 중요한 정보를 암호화하여 전송하는 경우에는 사용되지 않는다.

결론

=> 또한 스프링 시큐리티에서는 Http Basic이 기본적으로 활성화되어있어 Http basic 인증 처리를 받아야하는 인층 페이지가 뜨도록 되어있다.
그렇기 때문에 disable() 처리를 하였다.

Erin Lee

내가 설명할 수 있어야 비로소 내가 아는 것이다

이전 포스트

[Java Project] @Transactional 잘 사용하기

다음 포스트