인증 보안 강화

개요

현재 `Access` 토큰은 `로컬 스토리지`에, `Refresh` 토큰은 `쿠키`에 저장하고 있습니다. 이 구조에서 발생할 수 있는 `XSS` 및 `CSRF` 공격에 의한 피해를 최소화하기 위한 방법을 고민하고, 적용해 보았습니다.

 

참고) XSS와 CSRF 공격

XSS (Cross-Site Scripting) 공격

• 악성 스크립트를 이용해 로컬 스토리지에서 토큰을 탈취하는 공격입니다.
• 이를 방어하기 위해 `Http-Only` 쿠키를 사용하는 것이 효과적입니다.
• Http-Only 쿠키는 스크립트의 접근을 차단합니다.

CSRF (Cross-Site Request Forgery) 공격

• 공격자가 인증된 사용자를 유도하여 사용자가 의도하지 않은 요청을 서버에 보내도록 만드는 공격입니다.
• 로컬 스토리지에 저장된 토큰은 클라이언트 측에서 명시적으로 스크립트를 통해 접근해야 하므로, 공격자가 이를 직접 사용할 수 없습니다.
• 반면, 쿠키는 브라우저에서 자동으로 포함되기 때문에, CSRF 공격은 주로 쿠키 기반 인증을 대상으로 합니다.

 

토큰 관리 방식

Access 토큰

• Access 토큰은 보통 중요한 로직을 처리하는 요청에 사용되므로 CSRF 공격에 상대적으로 취약합니다.
• 이를 방어하기 위해, Access 토큰은 로컬 스토리지에 저장하는 것이 상대적으로 안전합니다.
• 만약 XSS 공격으로 토큰이 탈취되더라도 생명 주기가 짧아 사용 가능 시간이 제한적이므로, 상대적으로 위험이 적습니다.

 

Refresh 토큰

• Refresh 토큰은 생명 주기가 길어 직접적인 탈취에 더욱 취약합니다.
• 따라서 Http-Only 쿠키에 저장하여 XSS 공격을 차단합니다.

public Cookie createRefreshTokenCookie(String refreshToken) {
    Cookie refreshTokenCookie = new Cookie(REFRESH_TOKEN_COOKIE_NAME, refreshToken);
    refreshTokenCookie.setHttpOnly(true);
    refreshTokenCookie.setSecure(true);
    refreshTokenCookie.setPath("/");
    refreshTokenCookie.setMaxAge(REFRESH_TOKEN_COOKIE_EXPIRATION_TIME);
    return refreshTokenCookie;
}

하지만 CSRF 공격에 대한 고려도 필요하기 때문에, 이에 대한 대응 방안도 고민해야 합니다.

 

Refresh 토큰 CSRF 공격 대응 방안

1. `Referer` 헤더 검증을 통한 도메인 일치 여부 확인 (❌)
   • Referer 헤더를 사용해 요청 출처를 확인하는 방법은 해당 헤더가 항상 존재한다는 보장이 없다는 점에서 검증 방법으로 적합하지 않습니다.
2. `CSRF Random UUID`를 활용한 헤더 검증 (⭕)
   • Refresh 토큰이 필요한 요청마다 클라이언트는 고유한 CSRF UUID를 헤더에 포함해 보냅니다.
   • 서버는 요청을 처리하기 전에 해당 CSRF UUID가 올바른지 검증하여 CSRF 공격 가능성을 줄입니다.
   • 이 방법은 간단하게 CSRF 공격의 피해를 최소화하면서도 추가적인 복잡성을 줄일 수 있습니다.

 

구현

• `yml` 파일에서 CSRF UUID 값을 관리

spring:
  csrf:
    protection:
      uuid: ${CSRF_PROTECTION_UUID}

 

• CSRF UUID 검증 로직

@Value("${spring.csrf.protection.uuid}")
private String csrfProtectionUuid;

public void verifyCsrfProtectionUuid(String csrfProtectionUuid) {
    if (!this.csrfProtectionUuid.equals(csrfProtectionUuid)) {
        throw new ApiException(INVALID_CSRF_PROTECTION_UUID);
    }
}

 

결과

Access 토큰은 로컬 스토리지에서 관리하여 CSRF 공격 위험을 줄였고, Refresh 토큰은 Http-Only 쿠키를 사용해 XSS 공격을 방어하도록 했습니다. 또한 Refresh 토큰이 필요한 요청에는 CSRF Random UUID를 사용하여 CSRF 공격의 피해를 최소화할 수 있도록 설정했습니다.