> Isn’t all this just different flavors of a session fixation attacks? > The client should use cookies and the state parameter to ensure the > same user-agent it redirected to the authorization server is the one > coming back.
It's not a session fixation attack. It's just an interception of a credential. The authorization code is a credential that provides access to the protected resources. If the attacker can get it, the attacker can get the protected resources (using the client as an agent, so to speak). A cookie won't help, since it would be sent from the browser to the client along with the authorization code. If the attacker can observe or intercept the authorization code, the attacker and observe or intercept the cookie. Francisco --- On Tue, 3/29/11, Eran Hammer-Lahav <e...@hueniverse.com> wrote: From: Eran Hammer-Lahav <e...@hueniverse.com> Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "fcore...@pomcor.com" <fcore...@pomcor.com>, "Phil Hunt" <phil.h...@oracle.com>, "Justin Richer" <jric...@mitre.org> Cc: "OAuth WG" <oauth@ietf.org>, "Karen P. Lewison" <kplewi...@pomcor.com>, "Paul Tarjan (p...@fb.com)" <p...@fb.com> Date: Tuesday, March 29, 2011, 7:50 PM Isn’t all this just different flavors of a session fixation attacks? The client should use cookies and the state parameter to ensure the same user-agent it redirected to the authorization server is the one coming back. EHL From: Francisco Corella [mailto:fcore...@pomcor.com] Sent: Tuesday, March 29, 2011 11:46 AM To: Phil Hunt; Justin Richer; Eran Hammer-Lahav Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (p...@fb.com) Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > Can you explain how intercepting the authorization code > without having access to the client credentials is a > problem? For the sake of discussion, assume that the client > has valid and secure credentials that an attacker cannot > access. Also assume that the client has implemented some > form of cross-site protection. One way: man-in-the-middle attack. The traffic between the legitimate user's browser and the client goes through the attacker's machine (easy to set up with a rogue WiFi access point). The user's browser sends an http request to the client, targeting the redirect URI. The attacker's machine doesn't let that request go through. The attacker then sends the same identical request from the attacker's own browser. When the client receives the request, it has no way to tell that it is coming from the attacker's browser rather than from the user's browser. The client exchanges the authorization code for an access token, uses the access token to obtain protected resources belonging to the user, and delivers those resources to the attacker's browser. (Or manipulates those resources as directed by the attacker's browser.) In the Facebook use case, the client logs the user in upon verifying that the authorization code is valid by exchanging it successfully for an access token. Another way (passive attack): The attacker observes the request from the user's browser to the client. The attacker does not stop the request. The client receives the request with the authorization code and exchanges the authorization code for the access token. Now the attacker sends the same request from the attacker's own browser. The client receives the second request and exchanges the authorization code for another access token. Upon receiving the second request for the same authorization code, the authorization server revokes the first access token, as suggested in section 4.1.2 of the specification: "If an authorization code is used more than once, the auhorization server MAY revoke all tokens previously issued based on that authorization code". The client then uses the second access token to access protected resources for the benefit of the attacker. In the Facebook use case, the attacker is logged in as the legitimate user. > I don‚Äôt know much about FB‚Äôs implementation but if they > allow the authorization code to be used for anything other > than exchanged for an access token using secure client > credentials, then they are not implementing the protocol as > specified. Facebook uses the protocol correctly, but the examples in the Facebook documentation use http rather than https for redirect URIs, so implementations that follow the examples use http rather than https. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
