Back-End/Spring Boot

로그인 처리

newny 2023. 8. 19. 06:15
반응형

쿠키와 보안문제

  • 쿠키값은 브라우저상에서 쉽게 바꿀수 있기 때문에 보안문제가 생길 수 있다. (클라이언트가 쿠키의 값을 강제로 변경하게되면 다른 사용자 로그인이 돼버린다)
  • 쿠키에 보관된 정보를 훔쳐갈 수 있다.
  • 해커가 쿠키를 한번 훔쳐가면 평생 사용할 수 있다.

 
로그인 유지를 하려면 쿠키가 사용되야하지만 보안이슈가 있다. 이 문제를 해결하기 위해 쿠키에 세션 저장소의 개념을 도입시켜 사용한다.
 

세션을 이용한 쿠키 보안문제 해결

  • 예상 불가능한 복잡한 세션 id를 사용한다.
  • 해커 입장에서 세션 id를 알게되어도 세션 id 자체만으로 알아낼 수 있는 중요한 정보가 없다.
  • 세션 만료 시간을 짧게 설정하여 해커가 토큰을 알아내도 시간이 지나면 사용할 수 없게 또는 해킹이 의심되는 경우 해당 세션을 강제로 제거하면 된다.

 

HttpServletRequest 이용하여 세션 얻기

request.getSession(true) : 기존 세션 반환, 기존 세션이 없다면 새로운 세션 생성하여 반환(기본)
request.getSession(false) : 기존 세션 반환 기존 세션이 없다면 null 반환
 

@SessionAttribute

세션을 찾아오되, 반환할 세션이 없다면 새로운 세션을 생성하지 않고 null로 반환한다.
 

TrackingModes

서버 입장에서 웹 브라우저의 쿠키 지원 여부를 알 수 없으므로 쿠키값도 전달하면서 URL에 'jsessionid'도 함께 전달한다.
URL 전달방식을 끄고 항상 쿠키를 통해서만 세션을 유지하고 싶다면 'application.properties' 파일에 아래의 코드를 넣어주면 된다.

server.servlet.session.tracking-modes=cookie

 

세션 타임아웃 설정

스프링 부트로 글로벌 설정
'application.properties' 파일에 설정 (글로벌 설정은 분단위로 해야함)

server.servlet.session.timeout=1800(기본 30분)

 
특정 세션 단위로 시간 설정

session.setMaxInactiveInterval(1800)

 

필터, 인터셉터

스프링의 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 필터 또는 인터셉터를 사용하는 것이 좋다. 웹과 관련된 공통 관심사를 처리할 때는 HTTP의 헤더나 URL의 정보들이 필요한데, 서블릿 필터나 스프링 인터셉터는 'HttpServletRequest'를 제공한다.

 

서블릿 필터

로그인 하지 않은 사용자가 url을 직접 호출했을 때 접근할 수 없게할 수 있다.
 
필터 흐름
HTTP 요청 → WAS → 필터 → 서블릿 → 컨트롤러 (로그인 사용자)
HTTP 요청 → WAS → 필터 (비 로그인 사용자, 서블릿 호출하지 않음)
 
필터 체인
HTTP 요청 → WAS → 필터1 → 필터2 → 필터3 → 서블릿 → 컨트롤러
 
필터 인터페이스의 메소드

  • init() : 필터 초기화 메소드
  • doFilter() : 고객의 요청이 올 때 마다 해당 메소드가 호출됨 (필터 로직 구현)
    • doFilter() 메소드의 FilterChain 파라미터 : 필터 로직 구현이 끝난 후 chain.doFilter(request, response) 를 호출해야한다. 다음 필터가 있다면 필터를 호출하고, 필터가 없다면 서블릿을 호출한다. 만약 이 로직을 호출하지 않으면 다음 단계로 진행되지 않으므로 서블릿 호출에 실패한다.
  • destroy() : 필터 종료 메소드

 

스프링 인터셉터

  • 로그인 하지 않은 사용자가 url을 직접 호출했을 때 접근할 수 없게할 수 있다.
  • 서블릿 필터보다 더 많은 기능을 가지고 있으며, 스프링 MVC에 최적화 되어있다.

 
스프링 인터셉터 흐름

  • HTTP 요청 → WAS →  서블릿 → 스프링 인터셉터 → 컨트롤러 (로그인 사용자)
  • HTTP 요청 → WAS → 서블릿 → 스프링 인터셉터 (비 로그인 사용자, 컨트롤러 호출하지 않음)

 
스프링 인터셉터 체인
HTTP 요청 → WAS  서블릿 → 인터셉터1 인터셉터2 인터셉터3 → 컨트롤러 (로그인 사용자)
 
스프링 인터셉터 인터페이스의 메소드

  • preHandle() : 컨트롤러 호출 전에 호출됨 (더 정확히는 핸들러 어댑터 호출 전)
  • postHandle() : 컨트롤러 요청 후 (예외 발생 시 호출되지 않음)
  • afterCompletion() : http 요청이 끝난 후 뷰가 렌더링 된 이후에 호출됨 (모든 상황에서 항상 호출됨)
반응형