🇰🇷 한글 설명
TREK 협업 여행 플래너의 특정 서비스에서 URL 검증 시 초기 URL만 확인하고 리다이렉트를 재검증하지 않는 취약점이 발견되었습니다. 공격자는 이를 악용하여 서버가 내부 네트워크나 클라우드 메타데이터 주소로 요청을 보내도록 유도하는 SSRF 공격을 수행할 수 있습니다.
💡 쉬운 설명
여행 계획 앱이 외부 링크를 불러올 때, 링크가 중간에 다른 주소로 바뀌더라도 다시 확인하지 않는 허점이 있습니다. 이를 통해 해커가 앱 서버를 조종하여 내부의 중요한 정보에 접근하게 만들 수 있습니다.
🇺🇸 원문 (English)
TREK is a collaborative travel planner. Prior to 3.1.0, TREK validates only the initial URL before native redirect following in importGoogleList() and importNaverList() in server/src/services/placeService.ts and resolveGoogleMapsUrl() in server/src/services/mapsService.ts. The affected sinks call checkSsrf() from server/src/utils/ssrfGuard.ts and then use fetch() with redirect: 'follow' instead of the DNS-pinned safeFetch() path, so a public attacker-controlled URL can redirect the server to loopback, RFC 1918, or cloud metadata addresses without revalidation. An authenticated trip member can reach the list-import routes, and any authenticated user can reach /api/maps/resolve-url, allowing blind GET requests to internal services without response-body reflection. This issue is fixed in version 3.1.0.
📍 영향받는 시스템
TREK version < 3.1.0
⚔️ 공격 벡터
인증된 사용자가 조작된 리다이렉트 URL을 제공하여 서버가 내부망(Loopback, RFC 1918) 또는 클라우드 메타데이터에 요청을 보내도록 유도
🛡️ 대응 방법
TREK 버전을 3.1.0 이상으로 업데이트하십시오.
🔧 검증 코드
출력된 버전이 3.1.0 미만이면 취약한 상태이며, 3.1.0 이상이면 안전합니다.
npm list trek-app-package-name 2>/dev/null | grep -E 'trek-app-package-name@'