WRAP Client security considerations around callback parameter

[Andrew Arnott]

This is regarding the Web App profile, from the Client perspective.

I believe the reason for the callback parameter being sent from the Client to the Authorization Server twice is to mitigate social engineering attacks, but I'm not sure.  As I implement a Client, I want to make sure I don't neutralize any benefit from the two callback parameters by the way I implement my Client.  Formulating the callback for the initial redirect to the Authorization Server is simple enough.  But for the subsequent direct call to the Authorization Server, should the callback parameter come from:

1. The web site's current HTTP request, whatever that may be (which will usually be the callback URL since the auth server just redirected the user to it)
2. A Client-side cached copy of the callback URL that was used in the initial redirect, looked up via the wrap_client_state parameter
3. something else

Which should it be?

I also believe that the initial redirect for authorization should not be associated with a user -- but rather the user association should happen after the authorization response comes back.  At least that was a good practice in OAuth 1.0(a).  Is that the case for WRAP?

Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Allen Tom]

Hi Andrew – Are you referring to section 5.4.5? I’m not sure what you mean by having the callback url sent twice.

Conceptually, the WRAP access token request is very similar to OpenID’s stateless mode. In both cases, the client is making a direct call to the auth server to verify the response that was passed to the client by the browser.

With regards to tying the authorization request to the user – the client is expected to authenticate the user prior to initating the request. The client should set an authentication cookie to recognize the user when the browser returns. It’s also a really good idea for the client to save the state in the wrap_client_state parameter and tie the wrap_client_state to the authentication cookie.

The wrap_verification_code is needed to protect against the Session Fixation issue with OAuth 1.0.

Hope that helps,
Allen

[Andrew Arnott]

Hi Allen,

We may be looking at different versions of the spec.  I'm looking at draft-hardt-oauth-01.  Section 6.2.2 and 6.2.5 are the redirect user to Auth Server and request Access Token steps.  Both require the callback_url.  I'm trying to understand why that is, and what defines the "correct" callback_url to send the second time around.

It sounds from your explanation that perhaps it's not that important because of the other mitigations with verification code, etc.  But I suspect it's still important since the second callback_url is still there.

I'm also wondering what the wrap_client_state can be safely used for.  I can make some guesses, but I'm sure you all have thought about it more deeply already.  To give one (probably bad) example, if the callback URL must be the same for these two requests from the Client, I could (grin) store the callback URL that I used for the first request in the client_state of that same request, so that when I get the response back, I can look up that parameter, and just pass that value in as the callback_url of the second request.  That leaves both the callback_url and the client_state wide open to MITM attacks, so probably not so good.  I'm guessing anything very useful in client_state probably means it should be signed by the Client.  

Thoughts?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
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.

[Allen Tom]

Hi Andrew -

The value of wrap_callback in 6.2.2 (the browser redirect) and 6.2.5 (the access token request) must be the same. We should have explained this in more detail in the spec.

There are several reasons why we required the wrap_callback to be passed to the Access Token endpoint – but the main reason is because the initial browser redirect (section 6.2.2) is not signed, allowing an attacker to tamper with the wrap_callback. Among other things, the attacker could insert an intermediate redirector server in front of the wrap_callback to hijack the verification code. Having the client pass the wrap_callback URL in the Access Token request helps protect against this scenario. This is mostly intended to defend against the session fixation exploit with Oauth 1.0.

I’m not even going to attempt to explain the Oauth 1.0 session fixation vulnerability here, the best writeup is here:
http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/

If the Client did not pass the wrap_callback back to the SP, it’s possible that an attacker could have initiated the authorization flow, and tampered the callback to have the verification code passed to the attacker’s server after the victim approves the authorization request. The attacker can then trick the victim into approving the authorization request, and pass the verification code to the client.  The client will then submit the verification code back to the service provider and return the victim’s data to the attacker.

By having the client pass the callback url back to the SP, the SP is able to determine if the callback URL was tampered. In the above scenario, the SP would notice that the callback URL in the Access Token request (the legitimate callback url) didn’t match the callback url in the request (the tampered callback).

This exploit can be partially mitigated by requiring clients to pre-register their callback URLs – however this is not feasible for all applications.

Hope that helps – I still get a headache whenever I think about the Oauth session fixation issue.

Allen