Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

["William J. Mills" <[e-mail]>]

While I agree in principal, I think there are real world use cases that make this more complicated.  If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction.  I don't know how we capture this in the right way in the spec.



________________________________
From: Niv Steingarten <[e-mail]>
To: William J. Mills <[e-mail]>
Cc: Eran Hammer-Lahav <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

I suppose you're talking about this:
http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is indeed more complete w.r.t. CSRF attacks on the client's
redirection URI, but it does not address CSRF attacks on the
authorization server.

I believe something along the lines of the text I proposed could be
combined in whichever text is eventually decided upon.

-- Niv


On Fri, Aug 19, 2011 at 02:46, William J. Mills <[e-mail]> wrote:
> I proposed text that I think is more complete in a previous message...
> ________________________________
> From: Niv Steingarten <[e-mail]>
> To: Eran Hammer-Lahav <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
>
> How about add something like this as the second paragraph in 10.12:
>
>   The authorization server SHOULD employ measures to prevent CSRF
>   attacks on the authorization endpoint. A non-guessable token SHOULD
>   be included in requests and form submissions within the authorization
>   server's internal authorization flow. This token MUST NOT be
>   accessible by the client. In addition, the authorization server may
>   make use of HTTP referrer headers in order to verify the origin of
>   requests made during the authorization flow.
>
> In addition, I think that:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks, ...
>
> should be changed to:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks against the client's redirection URI, ...
>
> so that the fact that the 'state' parameter protects against CSRF
> attacks on the *client*, as opposed to CSRF on the *authorization
> server*, is made explicit.
>
> -- Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav <[e-mail]>
> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Niv Steingarten [mailto:[e-mail]]
>>> Sent: Thursday, August 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
>>> Cc: Torsten Lodderstedt; [e-mail]
>>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> Impersonation)
>>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav <[e-mail]>
>>> wrote:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Niv Steingarten [mailto:[e-mail]]
>>> >> Sent: Thursday, August 18, 2011 12:12 PM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: Torsten Lodderstedt; [e-mail]
>>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> Impersonation)
>>> >>
>>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>>> >> <[e-mail]>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: Niv Steingarten [mailto:[e-mail]]
>>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>>> >> >> To: Eran Hammer-Lahav
>>> >> >> Cc: Torsten Lodderstedt; [e-mail]
>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> >> Impersonation)
>>> >> >>
>>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>> >> >> <[e-mail]>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >> -----Original Message-----
>>> >> >> >> From: Niv Steingarten [mailto:[e-mail]]
>>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>>> >> >> >> To: Eran Hammer-Lahav
>>> >> >> >> Cc: Torsten Lodderstedt; [e-mail]
>>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
>>> >> >> >> Owner
>>> >> >> >> Impersonation)
>>> >> >> >>
>>> >> >> > Can you provide another example with the same level of detail as
>>> >> >> > you
>>> >> >> provided below?
>>> >> >>
>>> >> >> The malicious client sends a request to the authorization endpoint
>>> >> >> with the appropriate parameters, and in return receives the markup
>>> >> >> of the web-page which should be displayed to the user in order to
>>> >> >> get consent. In addition, since the request is launched not via a
>>> >> >> sandboxed user-agent, the client also has access to any
>>> >> >> 'Set-Cookie'
>>> >> >> HTTP headers.
>>> >> >>
>>> >> >> Instead of displaying the page to the user, the client extracts
>>> >> >> the web-form data (including the hidden nonce/token) which would
>>> >> >> be submitted when 'Allow' is clicked. It then forges the
>>> >> >> appropriate POST request with the cookies, form data and referrer,
>>> >> >> and dispatches it,
>>> >> >
>>> >> > SCENE MISSING [1]
>>> >> >
>>> >> >> to finally receive an access token/authorization code in the
>>> >> >> redirection.
>>> >> >
>>> >> > You skipped the best part!
>>> >> >
>>> >> > What do you mean by "dispatches it"? How is the resource owner
>>> >> > tricked
>>> >> or abused to grant authorization unknowingly? I understand how your
>>> >> proposal "fixes" the first half, but not what kind of attack is
>>> >> happening in the second half.
>>> >> >
>>> >>
>>> >> I might have accidentally skipped the part where the user is already
>>> >> logged in at the authorization endpoint, so no log-in is required but
>>> >> rather just allowing/denying access (correction: the first request is
>>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once
>>> >> it extracts the data from the web-form, the client has all the
>>> >> information it needs in order to create an HTTP request
>>> >
>>> > No - the attacker does not have access to the session cookie. It still
>>> > needs
>>> to find a way to make a CSS call.
>>> >
>>>
>>> That's what I said -- "no access to cookies".
>>
>> You only said that about the first request.
>>
>>> But since both requests (the one
>>> requesting the auth endpoint and the one simulating the
>>> "allow") are sent from the same user-agent, the cookies are handled by
>>> the
>>> user-agent itself. The client just POSTs the request with the appropriate
>>> parameters to the action endpoint of the form.
>>
>> That's not exactly right.
>>
>> This entire attack is based on:
>>
>> 1. The presence of some session cookie or other user-agent state to bypass
>> active authentication, and
>> 2. The ability of the malicious client to make CSS calls using #1.
>>
>> Everything else is a red herring because the ability to automate this
>> attack and make it more powerful is completely beside the point. If you
>> deploy an effective CSRF protection, everything else is a non-issue.
>>
>> This is why the client type does not matter when it comes to not using
>> CORS. The authorization server MUST NOT allow CSS calls on the authorization
>> endpoint because that's the actual attack you described - using local state
>> (session cookie) to make a CSS call. If the client makes direct calls to the
>> authorization endpoint, it cannot impersonate the resource owner.
>>
>>> >> and launch it using the same HTTP framework/WebKit, simulating the
>>> >> "Allow" button.
>>> >
>>> > This is still just a CSRF attack.
>>> >
>>>
>>> I think you may be right. I still believe this particular style of attack
>>> on the
>>> authorization server is worth mentioning, be it in its own separate
>>> section or
>>> under the existing CSRF section (as you suggested).
>>
>> This is not a style of attack but techniques to enhance other exploits, in
>> this case, CSRF. If you lack CSRF protection, then yes, lack of resource
>> owner forced interaction will make it easier to execute. But that's just a
>> tiny speed bump considering the actual exploit.
>>
>> I don't see any reason to include this new text based on this threat
>> analysis.
>>
>> However, this doesn't mean this discussion wasn't useful. We did identify
>> the need to explicitly discuss CSRF attacks on the authorization endpoint.
>> We need to explicitly separate the two target of CSRF attacks (client,
>> server) because while the solution is the same, the implementation is very
>> different (due to the use of redirections in one).
>>
>> EHL
>>
>>
>>
>>
>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>