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.
As I understand the attack, when complete, the attacker will be able to sign-in as normal to his (honest) Consumer account and, in so doing, be able to (indirectly) access the Protected Resources that the honest (Service Provider) exposes (through OAuth). In other words, it's not the User's Consumer site resources that are compromised (as the above text suggests), but rather their SP resources.
Separately, I think the recommended warning text would have users running for the hills if they understood it. Why not piggy-back on whatever accumulated wisdom users have for detecting a phish?
4 comments:
Yes, the attacker's "honest" account at the Consumer is linked to the attacked user's "honest" account at the Service Provider.
The issue is that there is no way (currently) for the Consumer to ensure that the user (identity) that causes the Consumer to issue the request_token request, is the same user who invokes the callback at the Consumer after authorization takes place.
there is if the Consumer doesn't piggy back on the OAuth protocol for Authenticating the user. If the Consumer authenticates the user first before putting him through the OAuth dance, the request token can always be bound to the correct user's account at the Consumer. And when a request token is replayed out of context, it can be blocked at the Consumer level. Another reason to not use OAuth for "Authentication".
Praveen, I'm missing something, when during the attack (or subsequent) would the Consumer try to authenticate the user?
sorry I keep forgetting that the callback is optional in authorization step.
If it is mandatory then this could have been prevented by binding the request token to a browser session (authenticated or not) on the consumer side. So if a request token appears at the consumer and if that token is not bound to the consumer's session with the attacked user (in most cases there wouldn't be a session), the consumer could mark the token as invalid, and when the attacker appears with the same request token from a different (or original) session it knows that it's misused. But anyway this wouldn't work for non-browser based clients that cannot handle the call backs directly (unless they all run a web gateway to guide their users for authorization).
Post a Comment