Compliance Impact

This vulnerability causes refresh tokens to be exposed in URLs, which are then logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs. Such exposure of sensitive authentication tokens can lead to unauthorized access and session hijacking.

Because sensitive tokens are transported via URL query parameters, this practice violates best practices and standards such as OWASP Session Management guidelines and RFC 6749 Section 10.3, which explicitly prohibit including access and refresh tokens in redirect URIs.

From a compliance perspective, this exposure of sensitive information could lead to violations of data protection regulations like GDPR and HIPAA, which require the protection of personal and authentication data against unauthorized access and leakage.

The vulnerability was fixed by implementing PKCE in the OAuth flow, which prevents token misuse even if URLs are logged, thereby improving compliance with security standards.

Useful 0 Not Useful 0

Executive Summary

The vulnerability in Nhost's auth service prior to version 0.48.0 involves the OAuth provider callback flow where the refresh token is placed directly into the redirect URL as a query parameter.

Because the refresh token is included in the URL, it can be exposed through multiple leak vectors such as browser history, HTTP Referer headers, server access logs, and proxy/CDN logs.

This exposure happens because the token is transported via a GET redirect URL query string, which violates best practices and standards for handling sensitive tokens.

If an attacker obtains the refresh token before it is consumed by the legitimate client, they can exchange it for new access tokens and impersonate the user.

The issue was fixed in version 0.48.0 by implementing PKCE (Proof Key for Code Exchange) in the OAuth flow, which prevents token misuse even if URLs are logged.

Useful 0 Not Useful 0

Impact Analysis

The main impact of this vulnerability is session hijacking.

An attacker who obtains the exposed refresh token can generate new access tokens by making requests to the auth service's token endpoint, thereby impersonating the user.

Since the refresh token is one-time use, the attacker must act before the legitimate client consumes it.

Exposure of the refresh token through browser history, logs, or HTTP Referer headers increases the risk of unauthorized access to user sessions.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by inspecting network traffic and logs for URLs containing refresh tokens as query parameters in OAuth callback redirects.

• Check server access logs, proxy/CDN/WAF logs, and reverse proxy logs for URLs with the parameter "refreshToken".
• Use network traffic capture tools (e.g., tcpdump, Wireshark) to monitor HTTP 302 redirect responses for URLs containing refresh tokens.
• Example command to search logs for refresh tokens: `grep -i 'refreshToken=' /var/log/nginx/access.log`
• Example curl command to test token exchange (to verify if a captured token is valid): ```curl -X POST https://auth.nhost.run/v1/token -H 'Content-Type: application/json' -d '{"refreshToken": "<captured_token>"}'```

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade the Nhost auth service to version 0.48.0 or later, where the vulnerability is fixed by implementing PKCE in the OAuth flow.

Until the upgrade is applied, avoid logging full URLs containing refresh tokens and restrict access to logs that may contain sensitive tokens.

Additionally, review and rotate any potentially exposed refresh tokens to prevent session hijacking.

Implement monitoring to detect any unauthorized use of refresh tokens.

Useful 0 Not Useful 0