Security of the verification code in web profile (6.2)

[Sarah Faulkner]

We’re run into a security issue implementing the web profile section 6.2.4:

 

6.2.4.  Authorization Server Directs User back to the Client

If the User approved the request, the Authorization Server MUST redirect the User back to the Callback URL, with the following parameters added:

wrap_verification_code

REQUIRED. The Verification Code.

wrap_client_state

REQUIRED if the Client sent the value in the authorization request in Section 6.2.2 (Client Directs the User to the Authorization Server)

Additional parameters:

Any additional parameters, as defined by the Authorization Server.

 

 

It looks like the following man-in-the-middle attack is exposed if the callback is over HTTP:

“

Jack is giving permission to goodRP.com to access his Windows Live contacts. Jack first signs into goodRP.com with ja...@goodRP.com. He clicks to import his WL contacts and goes through the verification step, giving WL his credentials on an SSL site. The verification code is sent to goodRP.com over HTTP.

 

Bruce intercepts the callback from Windows Live to goodRP.com with Jack’s verification code. He goes to goodRP.com and signs in as br...@goodRP.com. He clicks to import his WL contacts. Instead of going through the verification step, he posts to the callback url with Jack’s verification code. GoodRP.com then uses its client secret in server-to-server SSL to access Jack’s contacts and display them to Bruce.

“

 

Obviously requiring the callback url to be SSL is a solution, but I’m hearing mixed feedback about whether or not that is too difficult a requirement to place on integrating websites. Alternatively, the verification code can be bound with a context (such as a numeric user ID) and signed with the app secret to allow goodRP.com to verify they have the correct user. This deviates pretty significantly from the spec, and from my experience, is more difficult that putting up an SSl endpoint.

 

Thoughts?

 

---------------------------------------

Sarah Faulkner

Program Manager, Windows Live ID

[Allen Tom]

Hi Sarah -

Whether or not HTTPS is required end-to-end is up to the Service Provider. I do think it’s a great idea for Service Providers to  require sites to support HTTPS callbacks, however, based on our experience at Yahoo, this is a fairly high barrier for many sites, especially smaller ones.

Although this might not be explicitly stated in the WRAP spec, the client website is expected to authenticate the user before sending the user to the Service Provider, and to make sure that the same user comes back on the callback. This can be done by setting a authentication cookie on the user’s browser and setting a user-specific (and signed) value as query parameter in the wrap_callback URL.

In the scenario that you described, the attacker (Bruce) had intercepted the victim’s (Jack’s) verification code because the callback was sent via an insecure channel back to the consumer (goodRP.com). In this case, the attacker would not be able to replay the the victim’s verification code because the attacker would need to be authenticated on the consumer’s site using the victim’s account. (The user-specific value on the callback url would match Jack’s account, not Bruce’s account).

Does that help?

Allen

On 2/15/10 2:02 PM, "Sarah Faulkner" <sarahfa...@gmail.com> wrote:

We’re run into a security issue implementing the web profile section 6.2.4:
 
6.2.4.  Authorization Server Directs User back to the Client
If the User approved the request, the Authorization Server MUST redirect the User back to the Callback URL, with the following parameters added:

wrap_verification_code
REQUIRED. The Verification Code.
wrap_client_state

REQUIRED if the Client sent the value in the authorization request in Section 6.2.2 (Client Directs the User to the Authorization Server) <file:///C:/Users/SarahFa/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/O57ED6NB/draft-hardt-oauth-wrap-01%20(2).html#p4.authorization>

Additional parameters:
Any additional parameters, as defined by the Authorization Server.
 
 
It looks like the following man-in-the-middle attack is exposed if the callback is over HTTP:
“

Jack is giving permission to goodRP.com to access his Windows Live contacts. Jack first signs into goodRP.com with ja...@goodRP.com <mailto:ja...@goodRP.com> . He clicks to import his WL contacts and goes through the verification step, giving WL his credentials on an SSL site. The verification code is sent to goodRP.com over HTTP.
 
Bruce intercepts the callback from Windows Live to goodRP.com with Jack’s verification code. He goes to goodRP.com and signs in as br...@goodRP.com <mailto:br...@goodRP.com> . He clicks to import his WL contacts. Instead of going through the verification step, he posts to the callback url with Jack’s verification code. GoodRP.com then uses its client secret in server-to-server SSL to access Jack’s contacts and display them to Bruce.

“
 
Obviously requiring the callback url to be SSL is a solution, but I’m hearing mixed feedback about whether or not that is too difficult a requirement to place on integrating websites. Alternatively, the verification code can be bound with a context (such as a numeric user ID) and signed with the app secret to allow goodRP.com to verify they have the correct user. This deviates pretty significantly from the spec, and from my experience, is more difficult that putting up an SSl endpoint.
 
Thoughts?

[Allen Tom]

I thought about this a little bit more – if the client website doesn’t support HTTPS, and a man in the middle is able to capture the callback request – then attacker would be able to steal the victim’s cookies, as well as any other data passed on the callback. This means that the attacker would be able to hijack the victim’s session at the client site. There’s really nothing that WRAP or any other delegated authorization protocol can do to protect against this.

Allen

On 2/15/10 2:02 PM, "Sarah Faulkner" <sarahfa...@gmail.com> wrote:

We’re run into a security issue implementing the web profile section 6.2.4:
 
 

[Sarah Faulkner]

Hi Allen –

 

Yes, we had already considered the solution with a user context ID (or user-specific value), but had not thought of putting it on the callback url. This design works well as the callback url sent in 6.2.6 to get the access/refresh tokens must match the url from the verification code callback.

 

Thanks!

Sarah

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.