Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration

Hi Niv,

thank you for posting this to the list. I think you are right with your 
threat description. One question: shouldn't the browser already prevent 
the request to the authorization endpoint because of the same origin 
policy (or CORS restrictions)?

Apart from that, a similar attack can be performed by a native 
applicication (using an embedded browser). This kind of attack could not 
be prevented using HTTP features but by enforcing a real user 
interaction (password input, CAPTCHA).

regards,
Torsten.

Am 25.07.2011 18:27, schrieb Niv Steingarten:
> Forwarded as per Eran's request.
>
> A couple of corrections to my original email:
>
> 1. By AJAX, I mean, AJAX like techniques (if the user agent does not 
> enforce same origin policy).
> 2. When saying POST to '/authorize_callback' -- it may well be GET, if 
> the authorization server mishandles the request.
>
> Thank you,
>
> Niv
>
>
>
> ---------- Forwarded message ----------
> From: *Eran Hammer-Lahav* <eran@hueniverse.com 
> <mailto:eran@hueniverse.com>>
> Date: Tue, Jul 26, 2011 at 01:21
> Subject: RE: Several typos in -20 and a possible security consideration
> To: Niv Steingarten <nivstein@gmail.com <mailto:nivstein@gmail.com>>
>
>
> Please forward this message to the oauth list at oauth@ieft.org 
> <mailto:oauth@ieft.org>.
>
> Thanks,
>
> EHL
>
> *From:*Niv Steingarten [mailto:nivstein@gmail.com 
> <mailto:nivstein@gmail.com>]
> *Sent:* Monday, July 25, 2011 2:52 PM
> *To:* draft-ietf-oauth-v2@tools.ietf.org 
> <mailto:draft-ietf-oauth-v2@tools.ietf.org>
> *Subject:* Several typos in -20 and a possible security consideration
>
> Hello,
>
> I've noticed a couple of typos in -20:
>
> Section 6 (page 41): Under 'The authorization server MUST', the second 
> bullet should end with the word "and", and the third bullet should end 
> with a full-stop.
>
> Section 10.2 (first paragraph): "...keep is client credentials 
> confidential" should be "...keep *its* client credentials confidential".
>
> Regarding the security consideration --
>
> I might be missing something, but I saw there are references to 
> clickjacking and to client impersonation, but I haven't seen any 
> reference to possible resource owner impersonation.
>
> For example, in the implicit grant flow, a malicious client could send 
> a request to the authorization endpoint via, say, AJAX, and receive 
> the markup of the page asking the resource owner to authorize the 
> client (assuming the resource owner is signed in and no resource owner 
> authentication is required). Then, in a poorly designed authorization 
> endpoint, the 'Allow' button might be the submission button of a form 
> whose target is '/authorize_callback' on the authz server. Then, it 
> may possible for the malicious client to simply POST to 
> '/authorize_callback' and authorize itself without any resource owner 
> intervention or knowledge that the process has even taken place. This, 
> of course, can be mitigated in most modern browsers if the 
> authorization server verifies the source of the request using the HTTP 
> referrer header.
>
> Thanks for your time and for the fantastic work on OAuth,
>
>
> -- 
>
> *Niv Steingarten*
>
> T:
>
> E: nivstein@gmail.com <mailto:nivstein@gmail.com>
>
> W:http://nivstein.com
>
>
>
>
> -- 
> *Niv Steingarten*
> *
> *
> T:
> E: nivstein@gmail.com <mailto:nivstein@gmail.com>
> W:http://nivstein.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth