🇰🇷 한글 설명
OAuth 인증이 활성화된 상태에서 리버스 프록시가 HTTP를 통해 콜백을 전달할 경우, Temporal UI 서버가 인증 쿠키의 Secure 속성을 누락하여 발행하는 취약점입니다. 이로 인해 HTTPS로 로그인했음에도 불구하고 쿠키가 보안 속성 없이 생성되어 공격자가 자격 증명을 탈취할 수 있는 위험이 있습니다.
💡 쉬운 설명
로그인할 때 사용하는 중요한 보안 쿠키에 '보안 전용(Secure)' 표시가 빠져서 발생하는 문제입니다. 이 표시가 없으면 해커가 중간에서 정보를 가로채기 훨씬 쉬워집니다.
🇺🇸 원문 (English)
When OAuth authentication is enabled and browser-facing TLS terminates at a reverse proxy that forwards the callback to Temporal UI Server over HTTP, affected versions derive authentication-cookie Secure attributes from the proxy-to-server connection. Temporal UI Server can therefore issue access-token cookies, and refresh-token cookies when provided by the identity provider, without Secure even though the browser completed login over HTTPS.
A victim who visits attacker-controlled content while a credential remains live may expose that credential only if the attacker can also steer traffic for the UI hostname, prevent the browser's HTTPS connection from succeeding, serve the hostname over HTTP, and read a later same-site plaintext request. A malicious website alone cannot read the cookie, and passive observation of a successful TLS connection is insufficient. Effective HSTS, a blocking HTTPS-only warning, or TLS re-encryption between the proxy and Temporal UI Server prevents the demonstrated disclosure path.
A recovered credential may be replayed within the victim's assigned permissions. Refresh-token replay additionally depends on the identity provider's issuance, expiry, rotation, and reuse-detection behavior.
📍 영향받는 시스템
Temporal UI Server (OAuth 인증 사용 및 리버스 프록시 환경)
⚔️ 공격 벡터
프록시와 서버 간 HTTP 통신을 이용해 Secure 속성이 없는 쿠키를 탈취하는 방식
🛡️ 대응 방법
프록시와 서버 간 통신에 TLS 재암호화를 적용하거나 HSTS를 설정하여 보안 연결을 강제해야 합니다.
🔧 검증 코드
Set-Cookie 헤더에 'Secure' 속성이 포함되어 있지 않다면 취약한 상태입니다.
curl -I -s http://<temporal-ui-hostname>/path/to/callback | grep -i 'Set-Cookie' | grep -v 'Secure'
💻 영향받는 소프트웨어
IBM Verify Identity Access