For consumers that don't support callbacks you can have the user type in the token manually.
Here is how we (Yammer) have changed our protocol to close this security hole and still allow our API clients to function until a new OAuth spec is completed. You can see a diagram of the new authorization flow at the bottom of the page. http://www.yammer.com/api_oauth_security_addendum.html On Apr 23, 2009, at 11:15 AM, Ryan Kennedy wrote: > A lot of these solutions require something to be passed back by the > provider in the callback, however callbacks aren't required in OAuth > because they don't work for non-browser devices. How are you going > to pass something back to the application when there's no mechanism > to do so? > > Ryan Kennedy > > From: Matt Sanford <[email protected]> > To: [email protected] > Sent: Thursday, April 23, 2009 10:31:23 AM > Subject: [oauth] Re: OAuth Security Advisory > > Hi Mike, > > I have a proof of concept I think might be similar to this. It > works like so: > > 1. When the consumer gets the request_token the provide the callback > URL. > » Note this is server-to-server communication, unavailable to the > user. > > 2. The user is redirected to the service provider to authorize the > application. > > 3. Once authorized the user is redirected the the callback URL with > an additional callback_token parameter. > > 4. When requesting the access_token the consumer provides the > callback_token. > » If the request_token has a callback but the access_token request > does not have the callback_token access is denied and the request > token is invalidated. > » If the request_token had no callback but the access_token > request does access is denied and the request token is invalidated. > » If the callback_token does not match the one on record access is > denied and the request token is invalidated. > > By sending the callback in the server-to-server communication it > is not available to the user/attacker. This is also a signed > request so man-in-the-middle changes to the oauth_callback will be > caught by the signature. The final step of checking the > callback_token prevents other man-in-the-middle style attacks after > the user has been returned to the consumer app. Does this sound like > what you're suggesting? > > Thanks; > – Matt Sanford / @mzsanford > Twitter API Developer > > > > On Apr 23, 2009, at 10:16 AM, Mike Malone wrote: > >> How bout this... >> >> Instead of the provider signing the callback URL, the consumer >> signs the redirect to the SP using its consumer and request tokens. >> This will prevent an attacker from changing the callback URL, but >> still allow the consumer to specify any redirect URL it wants >> (provided the SP accepts any callback URL). >> >> This reduces the threat to what Eran called a "timing attack" in >> his blog post. There's still a possibility that the attacker could >> beat the victim back to the callback after the request token is >> authorized. To mitigate this, the provider could generate a >> callback nonce that must be provided during the request/access >> token exchange. This nonce would be appended as a querystring param >> to the callback URL. >> >> I think these two changes eliminate the threat with the smallest >> change to the spec, and without requiring either side to maintain a >> lot of extra state across steps. The SP needs to maintain the >> callback nonce, but it can be stored and expired with the request >> token. >> >> The drawback is that the manual auth process would require the user >> to enter two numbers at the consumer after authorizing a token: the >> request token key and the callback nonce. >> >> Mike >> >> On Thu, Apr 23, 2009 at 9:25 AM, Shan <[email protected]> wrote: >> >> I have a simple idea to propose not as a solution, but hopefully to >> give someone an idea toward a true solution: >> >> What if the callback URL is signed on the provider's end using the >> consumer's secret key? The drawback is it puts the burden on the >> consumer to close the security hole by checking the signature, and as >> such the provider has no way of knowing if an application is secure >> or >> not. >> >> Shan >> >> >> >> >> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
