[oauth] Re: An OAuth attack on Consumer implementations
According to the language in Rev A, the purpose of the verification code is to ensure the user performing the authorization at the SP is the same user who returns back to the Consumer. In order to ensure that the User granting access is the same User returning back to the Consumer to complete the process, the Service Provider MUST generate a verification code: a non-guessable value passed to the Consumer via the User and REQUIRED to complete the process. With Rev A, the verification code is introduced *after* the OAuth process has initiated and the user is already at the SP. In the case of the attack I've described, the user authorizing the action *is* the same user who's returning to the Consumer. The problem arises when the Consumer assigns the Access Token/Secret to the designated user after the negotiation is completed due to the fact the initiating user is not the user who completed the negotiation. I've read the spec several times now so if I've missed something glaringly obvious that mitigates this, please spell it out. I won't be offended. :) Darren On Thu, Apr 30, 2009 at 11:05 AM, Blaine Cook rom...@gmail.com wrote: That's the same attack as the one addressed in Rev. A; the verification token means that the consumer will always know which user with which to associate the access token (i.e., the user that brings the verification token to the consumer, not the user that initiated the flow). b. On Thu, Apr 30, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: Last week while pondering the vulnerability and the proposed solutions, I began thinking of the consumer assumptions being made and another possible avenue of attack that I personally think needs to be called out in an appendix. The attack is a derivative of the session fixation attack but is really much more reliant on an improper implementation on the Consumer end. To that end; the Rev A does not address this issue and likely shouldn't. It is made possible by a relatively specific, and what I feel is a quite probable, consumer configuration where the OAuth negotiation is permanently bound to the initiating user identity for the duration of its life cycle. It looks like this: Consumer App 1: A legitimate application that provides the ability to publish Twitter status updates via OAuth. 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. 7) Attacker now has access to Victims protected Twitter resources. While this attack scenario is dependent on a Consumer specific logic structure, without a fairly deep understanding of OAuth and general security principles (which unfortunately many do not have) this could be considered a very plausible implementation. I feel it is important to mention to Consumer application implementers that they cannot trust that the user who initiated the OAuth negotiation is the same as the one who completed it. Subsequently, the association of an OAuth Access Token and Access Token Secret with a user should only be based on material collected from the user who completed the transaction. Thoughts? Darren -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.com Date: Thu, Apr 30, 2009 at 3:25 AM Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 To: oauth@googlegroups.com oauth@googlegroups.com Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html I did my best to keep the changes to a bare minimum and to avoid any editorial changes to make comparison trivial: http://code.google.com/p/oauth/source/diff?spec=svn992old=991r=992format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml Some notes: 1. This is not ready for code! Please wait for a second draft before you start making changes to libraries or your implementations. Given the small scope of this change, I think it will be stable in the next draft. 2. Since this change is small, I would like to give it a short review period before another draft. Please submit all your comments by May 8th. 3. This draft is missing a few new Security Consideration sections. It will be added in the next draft but might be shared earlier on the list. 4. This revision does not change
[oauth] Re: An OAuth attack on Consumer implementations
On Thu, Apr 30, 2009 at 5:05 PM, Blaine Cook rom...@gmail.com wrote: That's the same attack as the one addressed in Rev. A; the verification token means that the consumer will always know which user with which to associate the access token (i.e., the user that brings the verification token to the consumer, not the user that initiated the flow). This is the first thought that i had reading this BUT it actually refers to a potential implementation pitfall that the consumers should avoid: On Thu, Apr 30, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 2.1) the consumer obtains the request token from the SP and links this token to the Attacker account 2.2) the consumer returns the reidrect to the Attacker that captures the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. What could happen is that he consumer might simply accept the callback and link the access token to the user that started the flow (i.e. the attacker) without authenticating who is sending back the callback. The critical point here is that the consumer should never do this and instead should always associate the access token to the user arriving via the callback (eventually authenticating him). 7) Attacker now has access to Victims protected Twitter resources. Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
I agree that it's the same attack, but it would be nice if in the security considerations, or Eran's editor's cut version the need for late binding is more clearly stated. Or maybe a best practice document? Thanks, George Blaine Cook wrote: That's the same attack as the one addressed in Rev. A; the verification token means that the consumer will always know which user with which to associate the access token (i.e., the user that brings the verification token to the consumer, not the user that initiated the flow). b. On Thu, Apr 30, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: Last week while pondering the vulnerability and the proposed solutions, I began thinking of the consumer assumptions being made and another possible avenue of attack that I personally think needs to be called out in an appendix. The attack is a derivative of the session fixation attack but is really much more reliant on an improper implementation on the Consumer end. To that end; the Rev A does not address this issue and likely shouldn't. It is made possible by a relatively specific, and what I feel is a quite probable, consumer configuration where the OAuth negotiation is permanently bound to the initiating user identity for the duration of its life cycle. It looks like this: Consumer App 1: A legitimate application that provides the ability to publish Twitter status updates via OAuth. 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. 7) Attacker now has access to Victims protected Twitter resources. While this attack scenario is dependent on a Consumer specific logic structure, without a fairly deep understanding of OAuth and general security principles (which unfortunately many do not have) this could be considered a very plausible implementation. I feel it is important to mention to Consumer application implementers that they cannot trust that the user who initiated the OAuth negotiation is the same as the one who completed it. Subsequently, the association of an OAuth Access Token and Access Token Secret with a user should only be based on material collected from the user who completed the transaction. Thoughts? Darren -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.com Date: Thu, Apr 30, 2009 at 3:25 AM Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 To: oauth@googlegroups.com oauth@googlegroups.com Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html I did my best to keep the changes to a bare minimum and to avoid any editorial changes to make comparison trivial: http://code.google.com/p/oauth/source/diff?spec=svn992old=991r=992format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml Some notes: 1. This is not ready for code! Please wait for a second draft before you start making changes to libraries or your implementations. Given the small scope of this change, I think it will be stable in the next draft. 2. Since this change is small, I would like to give it a short review period before another draft. Please submit all your comments by May 8th. 3. This draft is missing a few new Security Consideration sections. It will be added in the next draft but might be shared earlier on the list. 4. This revision does not change the value of the oauth_version parameter which remains '1.0'. The reason for that is that the version has nothing to do with the authorization workflow. It is specific to the signature methods and parameter delivery methods. Telling the difference between the two revisions is very simple: look for an oauth_callback parameter in the Request Token step. 5. The reason why the oauth_callback parameter is now required with a 'oob' value for manual entry is because the presence of the oauth_callback parameter in the first step is the only indication which flow is being used. Since some platforms have problem with empty parameters (they are dropped or not sent on the wire), I decided to try and define a non-URL value (also made the URL absolute). NOTE: Do no suggest ANY editorial changes that are not specific to the changed sections. This is NOT an opportunity to improve the specification. If you want to improve the specification in general, please provider feedback to
[oauth] Re: An OAuth attack on Consumer implementations
We call this ‘early binding’ and it will be directly addressed in a security consideration section. EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Darren Bounds Sent: Thursday, April 30, 2009 7:36 AM To: oauth@googlegroups.com Subject: [oauth] An OAuth attack on Consumer implementations Last week while pondering the vulnerability and the proposed solutions, I began thinking of the consumer assumptions being made and another possible avenue of attack that I personally think needs to be called out in an appendix. The attack is a derivative of the session fixation attack but is really much more reliant on an improper implementation on the Consumer end. To that end; the Rev A does not address this issue and likely shouldn't. It is made possible by a relatively specific, and what I feel is a quite probable, consumer configuration where the OAuth negotiation is permanently bound to the initiating user identity for the duration of its life cycle. It looks like this: Consumer App 1: A legitimate application that provides the ability to publish Twitter status updates via OAuth. 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. 7) Attacker now has access to Victims protected Twitter resources. While this attack scenario is dependent on a Consumer specific logic structure, without a fairly deep understanding of OAuth and general security principles (which unfortunately many do not have) this could be considered a very plausible implementation. I feel it is important to mention to Consumer application implementers that they cannot trust that the user who initiated the OAuth negotiation is the same as the one who completed it. Subsequently, the association of an OAuth Access Token and Access Token Secret with a user should only be based on material collected from the user who completed the transaction. Thoughts? Darren -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Date: Thu, Apr 30, 2009 at 3:25 AM Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 To: oauth@googlegroups.commailto:oauth@googlegroups.com oauth@googlegroups.commailto:oauth@googlegroups.com Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html I did my best to keep the changes to a bare minimum and to avoid any editorial changes to make comparison trivial: http://code.google.com/p/oauth/source/diff?spec=svn992old=991r=992format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml Some notes: 1. This is not ready for code! Please wait for a second draft before you start making changes to libraries or your implementations. Given the small scope of this change, I think it will be stable in the next draft. 2. Since this change is small, I would like to give it a short review period before another draft. Please submit all your comments by May 8th. 3. This draft is missing a few new Security Consideration sections. It will be added in the next draft but might be shared earlier on the list. 4. This revision does not change the value of the oauth_version parameter which remains '1.0'. The reason for that is that the version has nothing to do with the authorization workflow. It is specific to the signature methods and parameter delivery methods. Telling the difference between the two revisions is very simple: look for an oauth_callback parameter in the Request Token step. 5. The reason why the oauth_callback parameter is now required with a 'oob' value for manual entry is because the presence of the oauth_callback parameter in the first step is the only indication which flow is being used. Since some platforms have problem with empty parameters (they are dropped or not sent on the wire), I decided to try and define a non-URL value (also made the URL absolute). NOTE: Do no suggest ANY editorial changes that are not specific to the changed sections. This is NOT an opportunity to improve the specification. If you want to improve the specification in general, please provider feedback to the Editor's Cut version. Tomorrow, I will post an updated Editor's Cut version as well as an update to the IETF draft to include these changes. EHL -- darren bounds dar...@cliqset.commailto:dar...@cliqset.com
[oauth] Re: An OAuth attack on Consumer implementations
-Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of George Fletcher Sent: Thursday, April 30, 2009 8:39 AM To: oauth@googlegroups.com Subject: [oauth] Re: An OAuth attack on Consumer implementations Or maybe a best practice document? This make me chuckle... :-) EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
Eran, Good to hear. Darren, if you're concerned about early binding, a few people have suggested limiting the number of times a request token can be used within an authorization URL and limiting the amount of time that can elapse before it is used. Together, these restrictions make embedding an authorization URL in a blog, spam, etc. impractical. However, since some OAuth scenarios require authorization to be manual, I suspect these ideas will just be guidelines, not a part of the spec. Jesse On Thu, Apr 30, 2009 at 8:54 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: We call this ‘early binding’ and it will be directly addressed in a security consideration section. EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Darren Bounds Sent: Thursday, April 30, 2009 7:36 AM To: oauth@googlegroups.com Subject: [oauth] An OAuth attack on Consumer implementations Last week while pondering the vulnerability and the proposed solutions, I began thinking of the consumer assumptions being made and another possible avenue of attack that I personally think needs to be called out in an appendix. The attack is a derivative of the session fixation attack but is really much more reliant on an improper implementation on the Consumer end. To that end; the Rev A does not address this issue and likely shouldn't. It is made possible by a relatively specific, and what I feel is a quite probable, consumer configuration where the OAuth negotiation is permanently bound to the initiating user identity for the duration of its life cycle. It looks like this: Consumer App 1: A legitimate application that provides the ability to publish Twitter status updates via OAuth. 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. 7) Attacker now has access to Victims protected Twitter resources. While this attack scenario is dependent on a Consumer specific logic structure, without a fairly deep understanding of OAuth and general security principles (which unfortunately many do not have) this could be considered a very plausible implementation. I feel it is important to mention to Consumer application implementers that they cannot trust that the user who initiated the OAuth negotiation is the same as the one who completed it. Subsequently, the association of an OAuth Access Token and Access Token Secret with a user should only be based on material collected from the user who completed the transaction. Thoughts? Darren -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.com Date: Thu, Apr 30, 2009 at 3:25 AM Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 To: oauth@googlegroups.com oauth@googlegroups.com Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html I did my best to keep the changes to a bare minimum and to avoid any editorial changes to make comparison trivial: http://code.google.com/p/oauth/source/diff?spec=svn992old=991r=992format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml Some notes: 1. This is not ready for code! Please wait for a second draft before you start making changes to libraries or your implementations. Given the small scope of this change, I think it will be stable in the next draft. 2. Since this change is small, I would like to give it a short review period before another draft. Please submit all your comments by May 8th. 3. This draft is missing a few new Security Consideration sections. It will be added in the next draft but might be shared earlier on the list. 4. This revision does not change the value of the oauth_version parameter which remains '1.0'. The reason for that is that the version has nothing to do with the authorization workflow. It is specific to the signature methods and parameter delivery methods. Telling the difference between the two revisions is very simple: look for an oauth_callback parameter in the Request Token step. 5. The reason why the oauth_callback parameter is now required with a 'oob' value for manual entry is because the presence of the oauth_callback parameter in the first step is the only indication which flow is being used. Since some platforms have problem with empty parameters (they are dropped or not sent on the wire), I
[oauth] Re: An OAuth attack on Consumer implementations
I can't say that I agree. The fact of the matter is that a lot of developers are going to encounter OAuth for the first time when they first need to integrate with an SP. Most developers will immediately download an OAuth library from somewhere and start to work with it. They probably won't read the OAuth spec and internalize it. If they do read the spec, they may just gloss over whatever disclaimer warns them off of early binding or not have any idea what early binding is. Maybe this makes these developers bad, but it also makes them typical. I'm strongly in favor of anything that makes it easier for a typical developer to use my SP. One avenue for progress is on the OAuth library side. Most of the libraries I've looked at (not enough yet) provide procedural access to tokens and to make calls to OAuth entry points, but leave it up to the developer to sequence these calls and manage the token data within an application. As we've built out SDKs for our SP, we've found ourself increasingly building this logic on top of OAuth to make it easy to integrate within common web frameworks. Typically, this ends up with a bit of example code that shows how to incorporate content from our SP into a page in one of these frameworks with almost no work. Which is to say, bad developers are cured when good developers do the hard stuff for them. Jesse On Thu, Apr 30, 2009 at 9:28 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: The only way to prevent early binding is, well, not to do it. There is no cure for bad developers. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Jesse Myers Sent: Thursday, April 30, 2009 9:02 AM To: oauth@googlegroups.com Subject: [oauth] Re: An OAuth attack on Consumer implementations Eran, Good to hear. Darren, if you're concerned about early binding, a few people have suggested limiting the number of times a request token can be used within an authorization URL and limiting the amount of time that can elapse before it is used. Together, these restrictions make embedding an authorization URL in a blog, spam, etc. impractical. However, since some OAuth scenarios require authorization to be manual, I suspect these ideas will just be guidelines, not a part of the spec. Jesse On Thu, Apr 30, 2009 at 8:54 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: We call this 'early binding' and it will be directly addressed in a security consideration section. EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Darren Bounds Sent: Thursday, April 30, 2009 7:36 AM To: oauth@googlegroups.com Subject: [oauth] An OAuth attack on Consumer implementations Last week while pondering the vulnerability and the proposed solutions, I began thinking of the consumer assumptions being made and another possible avenue of attack that I personally think needs to be called out in an appendix. The attack is a derivative of the session fixation attack but is really much more reliant on an improper implementation on the Consumer end. To that end; the Rev A does not address this issue and likely shouldn't. It is made possible by a relatively specific, and what I feel is a quite probable, consumer configuration where the OAuth negotiation is permanently bound to the initiating user identity for the duration of its life cycle. It looks like this: Consumer App 1: A legitimate application that provides the ability to publish Twitter status updates via OAuth. 1) Attacker authenticates to Consumer App 1. 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth redirect URL. 3) Attacker embeds the URL in his blog and coerces the Victim user into clicking it (how is out of scope). 4) Victim user is brought to Twitter and prompted to authenticate and authorize his association with Consumer App 1. 5) Victim is then redirected to Consumer App 1 to complete the OAuth handshake. 6) Because Consumer App 1 does not take into account the possibility that the user who initiated the exchange isn't the same as the one who returned, the Consumer App 1 completes the OAuth negotiation and associates the Access Token and Access Token Secret with the Attacker. 7) Attacker now has access to Victims protected Twitter resources. While this attack scenario is dependent on a Consumer specific logic structure, without a fairly deep understanding of OAuth and general security principles (which unfortunately many do not have) this could be considered a very plausible implementation. I feel it is important to mention to Consumer application implementers that they cannot trust that the user who initiated the OAuth negotiation is the same as the one who completed it. Subsequently, the association of an OAuth Access Token and Access Token Secret with a user should only be based on material
[oauth] Re: An OAuth attack on Consumer implementations
A good library should hide the request token from the developer. They should simply call a function to generate the authorization URL (ex. get_auth_url()) and display that to the user. This way they never get the token and can't really bind it (library should also state this in its docs). I agree this is a consumer implementation problem. This should be fixed in the libraries and not the protocol its self. It's up to library implementers to properly document their libraries and educate its users. The process of implementing a consumer should be trivial to the developer. On Thu, Apr 30, 2009 at 12:29 PM, Mike Malone mjmal...@gmail.com wrote: On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers jesse.my...@gmail.comwrote: I can't say that I agree. What do you disagree with? Eran said early binding would be addressed in the security considerations section. The fact of the matter is that a lot of developers are going to encounter OAuth for the first time when they first need to integrate with an SP. Most developers will immediately download an OAuth library from somewhere and start to work with it. They probably won't read the OAuth spec and internalize it. If they do read the spec, they may just gloss over whatever disclaimer warns them off of early binding or not have any idea what early binding is. Early binding is also harder. Why would you try to maintain state (user/request token binding) between requests when you don't have to? The path of least resistance is the right one in this case, which should be enough to keep most bad developers from screwing things up. I can't think of any way you'd be able to enforce this constraint in the OAuth libraries short of not providing access to the request token. And that's not really an option since the consumer app needs to persist the request token somewhere, and the library has no way of knowing where that somewhere is. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
I hadn't thought of late binding as the path of least resistance, so perhaps I'm making a bigger deal of this than I need to, although it occurs to me that some developers will be tempted to store the request token in the current session, which is really easy in most environments, and doesn't require any extra token-user binding implementation. Storing the request token in the session is unlikely to cause any problems. The worst possible outcome is that in an attack scenario the victim would be redirected to the consumer and the consumer wouldn't be able to find the request token since it's not in the victim's session. In this case the request token isn't really bound (at least not in a bad way) to the attacker. It's just persisted in a place that is only visible to one user. I'm not saying this is a good idea (I can think of some minor security implications), but it's not a huge deal either. The bad sort of binding would occur if the consumer associated a request token with a user pre-authorization, and completely ignored the user who returns to the site post-authorization. This requires additional effort since, instead of simply persisting the request token, you have to persist the request token along with some relation to a specific user of your system. I actually think there's a lot that good library implementations can do to help, but the simplest thing is to define a clean callback/interface for request token storage that does not reference users or sessions. Developers would have to go out of their way to use early binding, which as you say is not the path of least resistance. A good library could also define a callback/interface for access token storage that does reference users or sessions, but that's certainly more complicated because it gets into application logic. I don't see how it would prevent the consumer from associating a user with the request token. In the end, the consumer application has to be responsible for persisting the request token somewhere, and retrieving it later. As long as that's true there's nothing stopping the consumer from associating the request token with a particular user of the system (aside from the fact that it's harder to do and wrong). Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
The consumer should not be persisting the request token anyways. With the new spec the request token will be returned in the callback along with the oauth_verifier. Now the client call call the library to fetch the access token (ex. get_access_token(oauth_token, oauth_verifier)) and it returns back the access token. On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone mjmal...@gmail.com wrote: I hadn't thought of late binding as the path of least resistance, so perhaps I'm making a bigger deal of this than I need to, although it occurs to me that some developers will be tempted to store the request token in the current session, which is really easy in most environments, and doesn't require any extra token-user binding implementation. Storing the request token in the session is unlikely to cause any problems. The worst possible outcome is that in an attack scenario the victim would be redirected to the consumer and the consumer wouldn't be able to find the request token since it's not in the victim's session. In this case the request token isn't really bound (at least not in a bad way) to the attacker. It's just persisted in a place that is only visible to one user. I'm not saying this is a good idea (I can think of some minor security implications), but it's not a huge deal either. The bad sort of binding would occur if the consumer associated a request token with a user pre-authorization, and completely ignored the user who returns to the site post-authorization. This requires additional effort since, instead of simply persisting the request token, you have to persist the request token along with some relation to a specific user of your system. I actually think there's a lot that good library implementations can do to help, but the simplest thing is to define a clean callback/interface for request token storage that does not reference users or sessions. Developers would have to go out of their way to use early binding, which as you say is not the path of least resistance. A good library could also define a callback/interface for access token storage that does reference users or sessions, but that's certainly more complicated because it gets into application logic. I don't see how it would prevent the consumer from associating a user with the request token. In the end, the consumer application has to be responsible for persisting the request token somewhere, and retrieving it later. As long as that's true there's nothing stopping the consumer from associating the request token with a particular user of the system (aside from the fact that it's harder to do and wrong). Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
Doesn't the consumer still need to store the secret for the request token to sign the access token exchange? I didn't think the request token secret was in the callback. On Thu, Apr 30, 2009 at 11:37 AM, Josh Roesslein jroessl...@gmail.com wrote: The consumer should not be persisting the request token anyways. With the new spec the request token will be returned in the callback along with the oauth_verifier. Now the client call call the library to fetch the access token (ex. get_access_token(oauth_token, oauth_verifier)) and it returns back the access token. On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone mjmal...@gmail.com wrote: I hadn't thought of late binding as the path of least resistance, so perhaps I'm making a bigger deal of this than I need to, although it occurs to me that some developers will be tempted to store the request token in the current session, which is really easy in most environments, and doesn't require any extra token-user binding implementation. Storing the request token in the session is unlikely to cause any problems. The worst possible outcome is that in an attack scenario the victim would be redirected to the consumer and the consumer wouldn't be able to find the request token since it's not in the victim's session. In this case the request token isn't really bound (at least not in a bad way) to the attacker. It's just persisted in a place that is only visible to one user. I'm not saying this is a good idea (I can think of some minor security implications), but it's not a huge deal either. The bad sort of binding would occur if the consumer associated a request token with a user pre-authorization, and completely ignored the user who returns to the site post-authorization. This requires additional effort since, instead of simply persisting the request token, you have to persist the request token along with some relation to a specific user of your system. I actually think there's a lot that good library implementations can do to help, but the simplest thing is to define a clean callback/interface for request token storage that does not reference users or sessions. Developers would have to go out of their way to use early binding, which as you say is not the path of least resistance. A good library could also define a callback/interface for access token storage that does reference users or sessions, but that's certainly more complicated because it gets into application logic. I don't see how it would prevent the consumer from associating a user with the request token. In the end, the consumer application has to be responsible for persisting the request token somewhere, and retrieving it later. As long as that's true there's nothing stopping the consumer from associating the request token with a particular user of the system (aside from the fact that it's harder to do and wrong). Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. On Thu, Apr 30, 2009 at 1:47 PM, Josh Roesslein jroessl...@gmail.comwrote: Sorry I forgot about the signing :). Maybe the library could provide a datastore interface which the consumer implements with their database. This way the library handles all the persisting of the tokens and secretes for the programmer. This makes it harder for the programmer to be tempted to prebind the token. We can either try to hide the request token from the developer the best we can or make sure they are properly educated on how they should persist it (and not prebind). On Thu, Apr 30, 2009 at 1:40 PM, Jesse Myers jesse.my...@gmail.comwrote: Doesn't the consumer still need to store the secret for the request token to sign the access token exchange? I didn't think the request token secret was in the callback. On Thu, Apr 30, 2009 at 11:37 AM, Josh Roesslein jroessl...@gmail.com wrote: The consumer should not be persisting the request token anyways. With the new spec the request token will be returned in the callback along with the oauth_verifier. Now the client call call the library to fetch the access token (ex. get_access_token(oauth_token, oauth_verifier)) and it returns back the access token. On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone mjmal...@gmail.com wrote: I hadn't thought of late binding as the path of least resistance, so perhaps I'm making a bigger deal of this than I need to, although it occurs to me that some developers will be tempted to store the request token in the current session, which is really easy in most environments, and doesn't require any extra token-user binding implementation. Storing the request token in the session is unlikely to cause any problems. The worst possible outcome is that in an attack scenario the victim would be redirected to the consumer and the consumer wouldn't be able to find the request token since it's not in the victim's session. In this case the request token isn't really bound (at least not in a bad way) to the attacker. It's just persisted in a place that is only visible to one user. I'm not saying this is a good idea (I can think of some minor security implications), but it's not a huge deal either. The bad sort of binding would occur if the consumer associated a request token with a user pre-authorization, and completely ignored the user who returns to the site post-authorization. This requires additional effort since, instead of simply persisting the request token, you have to persist the request token along with some relation to a specific user of your system. I actually think there's a lot that good library implementations can do to help, but the simplest thing is to define a clean callback/interface for request token storage that does not reference users or sessions. Developers would have to go out of their way to use early binding, which as you say is not the path of least resistance. A good library could also define a callback/interface for access token storage that does reference users or sessions, but that's certainly more complicated because it gets into application logic. I don't see how it would prevent the consumer from associating a user with the request token. In the end, the consumer application has to be responsible for persisting the request token somewhere, and retrieving it later. As long as that's true there's nothing stopping the consumer from associating the request token with a particular user of the system (aside from the fact that it's harder to do and wrong). Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.com wrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is similar to an API we put together for gadgets: http://code.google.com/apis/gadgets/docs/oauth.html http://wiki.opensocial.org/index.php?title=Introduction_to_makeRequest In particular the code is careful to hide the complexity of things like retrying after authorization failures, the Yahoo session extension, etc... The API is javascript, backed by Java and PHP server-side implementations. It's part of the Apache Shindig project. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
I don't see what's so hard about implementing this datastore. There is just two methods to implement. The library could probably even offer prebuilt datastores for the most common databases (mysql, postgre, etc) for the developer so they just need to plugin the connection and database information. Only reason to implement your own would be for an unsupported database. Example: oauth.client.set_datastore(oauth.client.MysqlDatastore(user='oauth_user', pass='password', database='oauth')) On Thu, Apr 30, 2009 at 3:25 PM, Mike Malone mjmal...@gmail.com wrote: On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
So can I ask, how do you not do early binding with desktop clients that don't receive the call-back? i.e. the only way of doing late binding is to identify via the call-back url which request token was authorised or denied so that that can be linked to the current user. If the application doesn't receive the call-back and relies on the user to tell the application that the step is complete there's no way of the application knowing which request token was authorised and must have a link between the user and request token prior to sending the user to the authorisation url? or am I missing something. Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
Agree this security issue does not apply to desktop clients. On Thu, Apr 30, 2009 at 4:05 PM, Mike Malone mjmal...@gmail.com wrote: For a desktop app you're typically binding the app to an account vs. binding a user of the app to an account. In this case you just need to make sure that the user who authorized the request token is the same user who is clicking continue. This is what the oauth_verification PIN accomplishes. The situation is slightly different for web apps because a typical web app has more than one user, and can bind the access token to a different user than the one who returns after the authorization step. Early binding means the app is binding the request token to a particular user account before redirecting to the SP, then disregarding the user who returns after the authorization step and simply exchanging the request token for an access token bound to the same user account. Mike On Thu, Apr 30, 2009 at 1:48 PM, Owen Evans owenmcev...@gmail.com wrote: So can I ask, how do you not do early binding with desktop clients that don't receive the call-back? i.e. the only way of doing late binding is to identify via the call-back url which request token was authorised or denied so that that can be linked to the current user. If the application doesn't receive the call-back and relies on the user to tell the application that the step is complete there's no way of the application knowing which request token was authorised and must have a link between the user and request token prior to sending the user to the authorisation url? or am I missing something. Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
Ok but can I just confirm that the only way to do late binding is to have some parameter in the callback that identifies which Request Token was authorised/denied? Just want to make my understanding clear as there's nothing in the spec that says how this should be passed around (i.e. should it be oauth_token parameter sent on the query string of the callback, should this kind of thing be standardised? because really you want the SP to generate the callback parameters and not just take the oauth_callback verbatum as this could lead to a process just as easily worked around) O 2009/5/1 Josh Roesslein jroessl...@gmail.com Agree this security issue does not apply to desktop clients. On Thu, Apr 30, 2009 at 4:05 PM, Mike Malone mjmal...@gmail.com wrote: For a desktop app you're typically binding the app to an account vs. binding a user of the app to an account. In this case you just need to make sure that the user who authorized the request token is the same user who is clicking continue. This is what the oauth_verification PIN accomplishes. The situation is slightly different for web apps because a typical web app has more than one user, and can bind the access token to a different user than the one who returns after the authorization step. Early binding means the app is binding the request token to a particular user account before redirecting to the SP, then disregarding the user who returns after the authorization step and simply exchanging the request token for an access token bound to the same user account. Mike On Thu, Apr 30, 2009 at 1:48 PM, Owen Evans owenmcev...@gmail.comwrote: So can I ask, how do you not do early binding with desktop clients that don't receive the call-back? i.e. the only way of doing late binding is to identify via the call-back url which request token was authorised or denied so that that can be linked to the current user. If the application doesn't receive the call-back and relies on the user to tell the application that the step is complete there's no way of the application knowing which request token was authorised and must have a link between the user and request token prior to sending the user to the authorisation url? or am I missing something. Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: An OAuth attack on Consumer implementations
ha. must be blind... thanks (feeling slightly stupid) Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 2:14 PM, Owen Evans owenmcev...@gmail.com wrote: Ok but can I just confirm that the only way to do late binding is to have some parameter in the callback that identifies which Request Token was authorised/denied? Just want to make my understanding clear as there's nothing in the spec that says how this should be passed around (i.e. should it be oauth_token parameter sent on the query string of the callback, should this kind of thing be standardised? because really you want the SP to generate the callback parameters and not just take the oauth_callback verbatum as this could lead to a process just as easily worked around) Section 6.2.3 of the spec: After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token. If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. If the Consumer provided a callback URL in oauth_callback (as described in Consumer Directs the User to the Service Provider (Consumer Directs the User to the Service Provider)http://oauth.net/core/1.0/#user_auth_redirected), the Service Provider constructs an HTTP GET request URL, and redirects the User’s web browser to that URL with the following parameters: oauth_token: The Request Token the User authorized or denied. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
