2024.06.27.보안 day58

DemoProjV 

어제 한 것 : 취약점 체크리스트 작성

오늘 할 것 : 체크리스트 기반 모의해킹 및 보안점검

 

http://192.168.30.254:8083/DemoProjV2/

 

 

1.토큰사용목적 

단일토큰 :  
1. 로그인성공 JWT 발급 서버측 -> 클라이언트로 JWT 발급
2. 권한이 필요한 모든 요청 : 클라이언트 -> 서버측 JWT 전송
권한이 필요한 요청은 서비스에서 많이 발생 
클라이언트측 xxs나 http통신을 가로채서 토큰을 훔침
이를 대비하기 위한 로직이 필요.


다중토큰 : refresh 토큰  
access/Refresh 토큰 

생명주기를 짧게 발급 (약10분)  , 토큰이 만료 되었을때 함께 받은 Refresh 토큰 (24시간) 토큰 재발급 

1. 로그인 성공시 2개 토큰

Access 토큰 : 권한이 필요한 모든 헤더에 사용될 JWT 생명주기를 짧게 함
Refresh 토큰 : 재발급을 위한 토큰으로 24시간 생명주기 

2. 권한이 필요한 모든요청은 Access 토큰을 사용 

3. Access 토큰이 만료될경우 Refresh 토큰을 검증 후 Access 토큰을 재발급 

==========================================================
포인트

1. 로그인이 완료되면 successHandler에서 Access/Refresh 토큰 2개 발급해 응답 
2. Access 토큰을 요청을 검증하는 JWTFilter에서 Access 토큰이 만료된경우 상태 코드와 메시지를 응답
3. 프론트측 API 요청시 Access 토큰 만료 요청이 오면 예외문을 통해 Refresh 토큰을 서버측으로 전송
Acccess 토큰을 새로 받는 로직 수행 
4. 서버측에서는 토큰을 받을 엔드포인트 구성 Refresh 검증후 Access 를 응답 


단일 -> 다중   으로 전환되면 Access 토큰이 탈취되더라도 생명주기가 짧아 피해가 줄어듬
그래서 Refresh 토큰에 대한 보호 방법이 필요

Access/Refresh 토큰의 저장위치 고려
Refresh 토큰 Rotate 에 대한 부분 ( Access 토큰 갱신시  Refresh 토큰도 재발급 )

Access/Refrsh 토큰 저장위치

기존 저장 로직 
로컬스토리지   : xss 공격에 취약 : Access 토큰저장
httpOnly 쿠키  : CSRF 공격에 취약 : Refresh 토큰저장

고려사항

JWT의 탈취는 XSS 공격으로 로컬스토리지에 저장된 JWT를 가져감 
쿠키방식은 CSRF공격에 취약하기 대문에 저장소가 중요 


Access 토큰 
보통 로컬 스토리지에 저장되고 짧은 생명주기
Refresh 토큰 
주로 쿠키에 저장  httpOnly를 설정하면 방어 가능 


Refresh 토큰은 Rotate를 통해서
Access 토큰 발급시 Refresh토큰도 갱신하여 방어 조치를 함

가장강력한보안 
로그아웃을할떄 Access/Refresh 토큰을 초기화하고 제거함  
Refresh 토큰 블랙리스팅 

====================================================================


라이브러리추가 


maven 

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.12.5</version> <!-- 최신 버전 확인하여 업데이트 가능 -->
</dependency>

** Libraries에서 확인할것 **
=============================================