oauth.net/advisories/2009-1/
oauth.net/advisories/2009-1/
23-April-2009
All standards-compliant implementations of the OAuth Core 1.0 protocol that use the OAuth authorization flow (also known as ‘3-legged OAuth’) are affected.
The attack starts with the attacker visiting the (honest) Consumer site, optionally logging into an account he owns at that site. The attacker initiates the OAuth authorization process but rather than follow the redirect from the Consumer to obtain authorization, the attacker instead saves the authorization request URI (which includes the Request Token). Later, the attacker convinces a victim to click on a link consisting of the authorization request URI to approve access to the victim’s Protected Resources to the (honest) Consumer.
By clicking on the link, the victim continues the request that the attacker initiated, including the Request Token that the (honest) Consumer issued to the attacker. Note that the victim is redirected to the legitimate approval page at the Service Provider and prompted by the Service Provider to approve the (honest) Consumer. It is not possible for the victim to detect that there is an ongoing attack.
After the victim grants approval, the attacker can use the saved Request Token to complete the authorization flow, and access whatever Protected Resources are exposed by the (honest) Consumer site as part of its service. If the attacker has an account with the (honest) Consumer site, the access may persist in future visits.
XSRF protections at the Consumer site do not mitigate against this attack.
It is recommended that Service Providers immediately implement appropriate monitoring to detect exploit attempts.
The OAuth Core 1.0 Revision A specification has been published to address this issue. It is strongly recommended that all implementations are updated to the new revision.
It is recommended that Service Providers offer adequate messaging to their users about the risks of starting an authorization flow from an untrusted location (see below for suggested wording). This warning should be displayed in the authorization interface for Consumer sites that have not upgraded to a version of the spec that fixes this issue. This warning can be suppressed if the Service Provider and the Consumer have agreed on other mitigation procedures.
Suggested wording on authorization pages:
“This website is registered with SERVICE_PROVIDER_DOMAIN_NAME to make authorization requests, but has not been configured to send requests securely. If you grant access but you did not initiate this request at CONSUMER_DOMAIN_NAME, it may be possible for other users of CONSUMER_DOMAIN_NAME to access your data. We recommend you deny access unless you are certain that you initiated this request directly with CONSUMER_DOMAIN_NAME.”
There are no reported exploits of this attack.