Summary
Ruby OAuth clients from 0.5.5 to 1.1.5 mishandle HTTP redirects, parsing raw Location headers and recursively following them in a way that can leak signed OAuth request metadata.
Under certain redirect conditions, the library may mutate client configuration and send sensitive Authorization headers to cross-origin hosts, exposing tokens and request details.
Ruby OAuth clients from 0.5.5 to 1.1.5 mishandle HTTP redirects, parsing raw Location headers and recursively following them in a way that can leak signed OAuth request metadata.
Under certain redirect conditions, the library may mutate client configuration and send sensitive Authorization headers to cross-origin hosts, exposing tokens and request details.
Affected context
This vulnerability appears in applications that use the Ruby OAuth library's OAuth::Consumer#token_request to interact with OAuth 1.0/1.0a servers.
It is relevant when OAuth servers return 3xx responses with crafted or unexpected Location headers and the client blindly follows redirects.
In such cases, the client may both alter its internal configuration based on the redirect URL and send signed OAuth requests, including Authorization headers, to redirect targets that are not under the original provider's control.
This vulnerability appears in applications that use the Ruby OAuth library's OAuth::Consumer#token_request to interact with OAuth 1.0/1.0a servers.
It is relevant when OAuth servers return 3xx responses with crafted or unexpected Location headers and the client blindly follows redirects.
In such cases, the client may both alter its internal configuration based on the redirect URL and send signed OAuth requests, including Authorization headers, to redirect targets that are not under the original provider's control.
Exploit preconditions
- Attack surface: Outbound OAuth token and resource requests made by Ruby applications using
OAuth::Consumer#token_request. - Required access: Ability to influence the OAuth server's redirect responses, or operate a malicious or compromised OAuth endpoint that issues 300–399 responses with crafted Location headers.
- Trigger point: The client's recursive redirect following, which parses and uses the raw Location header to construct subsequent requests.
- Why exploitation is possible: The consumer assumes redirects are trustworthy and reuses signed OAuth metadata across origins, allowing cross-origin endpoints to receive Authorization headers and other sensitive request data.
- Attack surface: Outbound OAuth token and resource requests made by Ruby applications using
OAuth::Consumer#token_request. - Required access: Ability to influence the OAuth server's redirect responses, or operate a malicious or compromised OAuth endpoint that issues 300–399 responses with crafted Location headers.
- Trigger point: The client's recursive redirect following, which parses and uses the raw Location header to construct subsequent requests.
- Why exploitation is possible: The consumer assumes redirects are trustworthy and reuses signed OAuth metadata across origins, allowing cross-origin endpoints to receive Authorization headers and other sensitive request data.
Why this happens
The root cause lies in overly trusting HTTP redirect responses when performing OAuth token operations.
The OAuth::Consumer#token_request logic parses the raw Location header and recursively follows redirects without adequately validating the redirect target's origin or enforcing strict redirect policies.
As a result, signed OAuth requests, including Authorization headers and other sensitive metadata, may be sent to arbitrary hosts, mapping to:
- CWE-200 (Information Exposure): Sensitive authentication data is disclosed to unintended recipients.
- CWE-346 (Origin Validation Error): Insufficient checks on redirect destinations and cross-origin routing.
- CWE-918 (Server-Side Request Forgery): Server-side code is induced to make authenticated requests to attacker-controlled endpoints.
The root cause lies in overly trusting HTTP redirect responses when performing OAuth token operations.
The OAuth::Consumer#token_request logic parses the raw Location header and recursively follows redirects without adequately validating the redirect target's origin or enforcing strict redirect policies.
As a result, signed OAuth requests, including Authorization headers and other sensitive metadata, may be sent to arbitrary hosts, mapping to:
- CWE-200 (Information Exposure): Sensitive authentication data is disclosed to unintended recipients.
- CWE-346 (Origin Validation Error): Insufficient checks on redirect destinations and cross-origin routing.
- CWE-918 (Server-Side Request Forgery): Server-side code is induced to make authenticated requests to attacker-controlled endpoints.
Potential impact
- OAuth access tokens and secrets may be exposed to cross-origin or attacker-controlled hosts.
- Authorization headers and signed OAuth request parameters could be logged or intercepted by third-party services.
- Attackers can potentially impersonate users or clients by reusing leaked credentials.
- Application-level configuration may be mutated, affecting future OAuth flows or routing behavior.
- Downstream services integrated via OAuth can be accessed or abused using captured tokens.
- OAuth access tokens and secrets may be exposed to cross-origin or attacker-controlled hosts.
- Authorization headers and signed OAuth request parameters could be logged or intercepted by third-party services.
- Attackers can potentially impersonate users or clients by reusing leaked credentials.
- Application-level configuration may be mutated, affecting future OAuth flows or routing behavior.
- Downstream services integrated via OAuth can be accessed or abused using captured tokens.
General mitigation guidance
Effective mitigation focuses on reducing trust in redirect targets and constraining where authenticated OAuth traffic can be sent.
Common defensive patterns include:
- Validating redirect destinations against a strict allowlist of expected hosts and schemes before following them.
- Avoiding propagation of Authorization headers and signed metadata across origins; strip or re-scope credentials when redirects occur.
- Treating all redirect responses as untrusted input and enforcing origin and path checks at the client or framework layer.
- Designing OAuth flows so that sensitive token exchanges happen against fixed, well-known endpoints rather than arbitrary URLs derived from responses.
- Applying least-privilege principles to tokens (limited scopes, short lifetimes) to minimize impact if exposure occurs.
Effective mitigation focuses on reducing trust in redirect targets and constraining where authenticated OAuth traffic can be sent.
Common defensive patterns include:
- Validating redirect destinations against a strict allowlist of expected hosts and schemes before following them.
- Avoiding propagation of Authorization headers and signed metadata across origins; strip or re-scope credentials when redirects occur.
- Treating all redirect responses as untrusted input and enforcing origin and path checks at the client or framework layer.
- Designing OAuth flows so that sensitive token exchanges happen against fixed, well-known endpoints rather than arbitrary URLs derived from responses.
- Applying least-privilege principles to tokens (limited scopes, short lifetimes) to minimize impact if exposure occurs.
How teams detect issues like this
Detection typically involves a mix of code-level and operational checks:
- Static analysis rules that flag client code which follows redirects for authenticated requests without validating the redirect target's origin.
- Code review practices that focus on how Location headers are parsed and whether Authorization headers are reused across redirect chains.
- Runtime monitoring for unusual outbound requests carrying OAuth Authorization headers to non-approved domains or IP ranges.
- Policy-based controls at HTTP client or gateway layers that enforce redirect limits and block cross-origin redirects for authenticated traffic.
- Use of automated security testing tools that simulate malicious redirect responses and observe whether credentials are leaked.
Detection typically involves a mix of code-level and operational checks:
- Static analysis rules that flag client code which follows redirects for authenticated requests without validating the redirect target's origin.
- Code review practices that focus on how Location headers are parsed and whether Authorization headers are reused across redirect chains.
- Runtime monitoring for unusual outbound requests carrying OAuth Authorization headers to non-approved domains or IP ranges.
- Policy-based controls at HTTP client or gateway layers that enforce redirect limits and block cross-origin redirects for authenticated traffic.
- Use of automated security testing tools that simulate malicious redirect responses and observe whether credentials are leaked.
