GHSA-c6rp-p8xm-4q9f: Infoleak
Summary
mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#requestheaders= followed a refresh that pointed at another origin.
Details
Mechanize::HTTP::Agent#responsefollowmetarefresh fetched the refresh target with no notion of a crossed origin, so @requestheaders were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.
The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#requestheaders= were exposed.
This requires Mechanize#followmetarefresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.
Impact
An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through requestheaders=. Disclosure only; no integrity or availability impact.
Patches
Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.
Workarounds
Leave Mechanize#followmetarefresh at its default of false, or avoid requestheaders= for credentials when it is enabled.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/mechanizeto a version that resolves this vulnerability.Fixed in 2.14.1 - Upgrade
Upgrade
mechanizeto a version that resolves this vulnerability.Fixed in 2.14.1 - Configuration
Leave Mechanize#follow_meta_refresh set to false; if it is enabled, avoid using request_headers= for credentials.
Mechanize follow_meta_refresh = false
Event History
Frequently Asked Questions
Which Mechanize uses are exposed to credential disclosure?
Exposure requires Mechanize#follow_meta_refresh to be enabled and sensitive headers, such as bearer tokens or session cookies, to be set through Mechanize#request_headers=. Headers supplied only on an individual request are not exposed through this path.
What must an attacker be able to do to exploit this?
An attacker must be able to cause the agent to fetch a page containing a meta refresh that points to another origin. This can occur through stored content, an open redirect, or control of any page included in the crawl.
Are agents using the default configuration affected?
No. Mechanize#follow_meta_refresh is false by default, so an agent that has not enabled meta-refresh following is not affected.
What can be done before upgrading?
Disable meta-refresh following and avoid placing sensitive credentials in Mechanize#request_headers=. The issue is fixed in mechanize v2.14.1.