There you go again:
Assumptions:
1. The provider requires a callback_url with get_request_token, signed
per the 1.0a.
2. The provider returns an oauth_verifier along the blessed request
token on the callback (if not oob) to the consumer upon user consent.
3. The consumer has a database table (or any other mechanism) to store
a user identifier (user's identity at the consumer), request token and
access token
4. The provider has a database table (or any other mechanism) to store
the user identifier (user's identity at the provider), request token
and access token
5. The endpoints are one time use only - so authorize_token and
get_access_token can be called once and only once for a given token.
6. The victim consents to providing access to the consumer for his
protected data.
7. The access token lives long enough for these steps (usually a few
hours)
8. The request token lives long enough for steps 3 though 11.
Flow:
1. Evil user (identity = eviluser) logs in to the consumer webapp.
2. Clicks a link to access protected resources on the provider
3. Consumer gets a request token per 1.0a (token1), and redirects the
eviluser to provider's login page.
4. Consumer record says {userId=evilUser, requestToken=token1,
accessToken=null}
5. Provider record says {userId = null, requestToken=token1,
accessToken = null}
6. eviluser copy-pastes this link and sends it to the soon-to-be
victim via IM to get everything done in the request token TTL which
can be few minutes. Evil user does not even need to be online after
this step.
7. The soon-to-be victim get the IM, clicks on the link.
8. Everything checks out, the victim logs in to the provider with his
credentials (gooduser). The provider updates the record at their end.
9. Provider record now says {userId=gooduser, requestToken=token1,
accessToken=null}
10. Provider now generates an oauth_verifier (abcd). Appends it to
oauth_token=token1 and calls back the consumer on the callback
provider in step 3
11. The consumer gets the callback with the token and verifier. The
record still says {userId=eviluser, requestToken=token1,
accessToken=null}
12. The consumer tries to convert this token to access token, now that
it has received the callback with a verifier. It may or may not store
the oauth_verifier. (In my provider implementation, I am not storing
the verifier and relying completely on the signature verification)
13. The consumer per 12 creates a signed request (including the
verifier) to request access token against the blessed request token.
14. The provider gets the request, and converts the requestToken to
access token as everything seems to be alright. The provider record
now says {userId=gooduser, requestToken=token1, accessToken=token2)
15. The provider returns the accesstoken to the consumer. Consumer
record now says {userId=evilUser, requestToken=token1,
accessToken=token2).
16. Now eviluser logs in to consumer, accesses a protected endpoint
(getAddressBook.do). Since the consumer already has an access token
for evilUser (see the db record above), it sends the request to access
protected resources.
17. The provider looks up the user who has that access token
(gooduser, see db record above) and returns gooduser's addressbook to
the consumer.
18. The consumer passes along the gooduser's addressbook to the
eviluser.
There you have it - I really really hope I am missing something here.
Since the spec does not have any guidelines for the consumer (it
should never do anyway), we cannot assume that the consumer is or is
not linking identities and tokens in a particular fashion. Besides I
think the whole scenario can be replicated without the record at the
consumer too, but Friday 6:45P I am too fried to think further :(
-cheers,
Manish
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
