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

[Niv Steingarten <[e-mail]>]

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 <[e-mail]>
Date: Tue, Jul 26, 2011 at 01:21
Subject: RE: Several typos in -20 and a possible security consideration
To: Niv Steingarten <[e-mail]>


Please forward this message to the oauth list at [e-mail].****

** **

Thanks,****

** **

EHL****

** **

*From:* Niv Steingarten [mailto:[e-mail]]
*Sent:* Monday, July 25, 2011 2:52 PM
*To:* [e-mail]
*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:  [e-mail]****

W: http://nivstein.com****

** **



-- 
*Niv Steingarten*
***
*
T: 
E:  [e-mail]
W: http://nivstein.com