@acastellon/auth: verifyToken()의 스푸핑 가능한 헤더를 통한 인증 우회
@acastellon/auth v2.2.0은 스푸핑 가능한 auth-user 및 Host 요청 헤더를 통해 verifyToken()에서 인증되지 않은 인증 우회를 허용하는 것으로 보입니다.
verifyToken 미들웨어에는 req.get('host').startsWith(getHostName()) 시 auth-user: service-brother에 대한 서비스 간 우회가 포함되어 있습니다. 검사에 관련된 두 값 모두 인증되지 않은 HTTP 클라이언트의 영향을 받을 수 있습니다. auth-user는 요청 헤더이고 Host도 클라이언트가 제어합니다. 결과적으로 인증되지 않은 원격 공격자는 일반 레거시/JWT/OIDC 유효성 검사 논리가 실행되기 전에 조작된 헤더가 포함된 요청을 보내고 토큰 유효성 검사를 우회할 수 있습니다.
영향: 공격자는 유효한 토큰 없이 verifyToken()으로 보호되는 경로에 액세스할 수 있습니다. 다운스트림 서비스가 auth-user 또는 is-* 헤더를 신뢰하는 배포에서는 이로 인해 권한 에스컬레이션이 발생할 수도 있습니다.
영향을 받는 패키지: @acastellon/auth v2.2.0
영향을 받는 코드: auth.js,validateToken() 이 문제는 service-brother 우회 및 getHostName() 확인과 관련이 있습니다.
요청 예시:
GET /보호된 HTTP/1.1
호스트: <구성된 CNAME 또는 호스트 이름>
인증 사용자: 서비스 형제
is-admin: 사실
예상되는 동작: 요청에는 유효한 인증 토큰이 필요합니다.
실제 동작: 미들웨어는 토큰 유효성 검사 전에 next()를 호출합니다.
v2.3.0+에서 구현된 수정 사항:
스푸핑 가능한 우회를 제거했습니다. 들어오는 auth-user 및 is-* 헤더를 항상 삭제하세요. mTLS 클라이언트 인증서 기반 서비스 인증이 추가되었습니다(선택적 TRUSTED_MTLS_SERVICES 허용 목록 포함). mTLS 지원을 위해 소비자(rest, graphql, dns-client)가 업데이트되었습니다. 정리 + mTLS 경로에 대한 단위 테스트가 추가되었습니다.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도(심각도 등급 추정치) | 95.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 95.00 |
VPI 공식 vpi-v1 기준